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

Reindl Harald h.reindl at thelounge.net
Sun Nov 8 14:32:48 UTC 2020


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20201108/ddb93d34/attachment.htm>


More information about the bind-users mailing list