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 <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 <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

Reply via email to