Thank you for your valuable feedback. It is much appreciated. On Fri, 20 Nov 2020 at 19:37, Reindl Harald <h.rei...@thelounge.net> wrote:
> > Am 08.11.20 um 14:44 schrieb Timothe Litt: > > > I'm amazed that this thread has persisted for so long on this list of > knowledgeable people > > > me too, i would understand that on the spamassassin list but not here and > what i *really* don't understand is jumping into the thread with "I just > wanted to comment that there is no requirement to run a secondary DNS > server" > > even if it would not be a requirement (but it is) it's common sense not to > contradict best practices everyone running critical services is following > > there are enough beginners which don't follow best practices anyways, no > need to encourage them > > RFC1034 <https://tools.ietf.org/html/rfc1034>, one of the two > foundational RFCs for the DNS: > > P.18 in section 4.1 (NAME SERVERS => Introduction): > > A given zone will be available from several name servers to insure its > availability in spite of host or communication link failure. By > administrative fiat, we require every zone to be available on at least > two servers, and many zones have more redundancy than that. > > In case the font is too small, the key phrase is: > > "we require every zone to be available on at least two servers" > > That's "REQUIRE" at least TWO SERVERS > > i heard of registries whcih require even 3 and when they say they require > it means you have them or you can't register a domain, no RFC needed to > begin with > > https://tools.ietf.org/html/rfc1537 documents common misconfigurations - > that is, cases of non-conformance to the RFCs that the author encountered > circa 1993. It was superseded in 1993 by RFC 1912 > <https://tools.ietf.org/html/rfc1912>, where section 2.8 starts with "You > are required to have at least two nameservers for every domain". Neither > document supersedes RFC1034; rather they attempt to help with interpreting > it. > > https://www.iana.org/help/nameserver-requirements consolidates > information from several RFCs, since the DNS has evolved over time. It is > not an RFC, but a convenient summary. It primarily documents the tests > performed by IANA when it processes a delegation change to the root, .INT, > and .ARPA zones. These tests validate conformance to the RFCs. As the > introduction says, "These tests do not measure against best practices or > comprehensively measure protocol conformance. They are a practical set of > baseline requirements that catch common misconfiguration errors that impact > stable operations of the DNS." > > Bottom line: two servers per zone are required by the DNS architecture. > It's not folklore. It's not optional. > > yes > > It is true that the DNS is robust enough to function with a number of > misconfigurations (including just one server for a zone, since in practice > this is almost indistinguishable from transient conditions.) > > Nonetheless, the goal of the DNS architecture (and most of its operators) > is to have a stable and robust name service. Misconfigurations, such as > those documented in rfc1527, make the DNS unstable and fragile. The > architecture tends to contain the effects of many misconfigurations, but > that doesn't make them wise. > > As I noted earlier: "DNS appears deceptively simple at first blush. > Setting up a serviceable infrastructure requires an investment of thought > and on-going maintenance. You will not be happy if you skimp on that > investment, since broken DNS is externally visible - and frequently > catastrophic." > > I'll finish with a 1987 quote from Leslie Lamport on distributed systems, > which the DNS most certainly is: > > "A distributed system is one in which the failure of a computer you didn't > even know existed can render your own computer unusable." > > Can the quibbling stop now? > > > thank you > _______________________________________________ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscribe from this list > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://www.isc.org/contact/ for more > information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users >
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users