[External] Re: How can I launch a private Internet DNS server?

Timothe Litt litt at acm.org
Sun Nov 8 13:44:11 UTC 2020


On 07-Nov-20 14:06, Tom J. Marcoen wrote:
> Having at least two name servers is not a requirement by the RFC
> standards but which TLD allows for only one NS server to be given when
> hou register a domain?
>
> On Sat, 7 Nov 2020 at 16:53, Kevin A. McGrail <kmcgrail at pccc.com
> <mailto:kmcgrail at pccc.com>> wrote:
>
>     On 11/7/2020 10:15 AM, Reindl Harald wrote:
>>
>>     https://tools.ietf.org/html/rfc1537
>>     Common DNS Data File Configuration Errors
>>
>>     6. Missing secondary servers
>>
>>     > It is required that there be a least 2 nameservers
>>     > for a domain.
>>
>>     -----------------------------
>>
>>     that above is common knowledge virtually forever and the
>>     difference of "must" and "should" in IETF wordings is also very
>>     clear 
>
>     While I agree this is common knowledge as a best practice, this
>     rfc is a memo NOT a standard from my reading:
>
>       This memo provides information for the Internet community.  It does
>        not specify an Internet standard.  Distribution of this memo is
>        unlimited.
>
>     Regards,
>     KAM
>
>

I'm amazed that this thread has persisted for so long on this list of
knowledgeable people.

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.

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.

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?

Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20201108/70ab5e4e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20201108/70ab5e4e/attachment.bin>


More information about the bind-users mailing list