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

Tom J. Marcoen tom.marcoen+isc at gmail.com
Fri Nov 20 19:08:42 UTC 2020


Thank you for your valuable feedback. It is much appreciated.

On Fri, 20 Nov 2020 at 19:37, Reindl Harald <h.reindl at 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20201120/a1f65e96/attachment-0001.htm>


More information about the bind-users mailing list