Subject: RFC 2182 considered harmful

From: "D. J. Bernstein" <[email-masked]>
Date: 4 Feb 2000 05:18:04 -0000

Consider a typical department network or small company network with two
independent DNS servers, no offsite machines, and no child domains.

RFC 2182 strongly recommends replacing one of the DNS servers with a
third-party DNS server. This recommendation is, to put it simply, wrong.
The costs outweigh the benefits.

RFC 2182 points to the extra DNS packets required to try and retry
inaccessible servers. But it

   * ignores the useless TCP SYN packets that would have been generated
     if the DNS lookup had succeeded;

   * ignores the effect of DNS failure caching, which it incorrectly
     claims does not exist; and

   * ignores the extra traffic required by third-party zone transfers.

The total effect of RFC 2182's recommendation is to _increase_ Internet
traffic. Anyway, the numbers in both directions are extremely small.

RFC 2182 also claims, without giving specifics, that some clients do not
produce ``desirable'' results when DNS lookups fail. But any such client
is clearly buggy, and won't survive in the marketplace---what do you
think happens when the _client's_ network is inaccessible? The idea of
100% DNS lookup success doesn't stand up to a moment's scrutiny.

Finally, RFC 2182 says that some hosts may be on a different network.
This is true for large sites and high-level servers, but in those cases
the sysadmin can set up one server on each network without wasting time
on third-party service. For department networks it's rarely true.

RFC 2182 has frightened many administrators into obtaining unnecessary
third-party DNS service. It says that this ``must'' be done and that it
is ``important'' and that the alternative---which it admits is easier
for administrators---is ``not a good policy''; but these bold claims are
not justified by the facts.

RFC 2182 should be revised to give an accurate statement of the costs
and benefits of third-party DNS service.

---Dan

---

From: Edward Lewis <[email-masked]>
Date: Fri, 4 Feb 2000 09:17:18 -0500

>and benefits of third-party DNS service.

Go ahead, write a document, and submit it.  Whether or not this is picked
up as a work item by any WG, it could still wind up as an informational RFC
through the RFC editor process.

I can't say I'd agree with the problem though, much less the severity you
assign it.  There are folks whose set of name servers each have the same IP
address.  I myself have a few domains whose servers are all on the same
segment.  No one is shutting these folks (and I) down.

I do see a benefit of having a DNS server pointing to my machines even if
my machines are behind a downed link.  I may have keying information or a
certificate stored that allows someone to read my encrypted mail message
warning of an upcoming outage.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"Trying is the first step to failure." - Homer Simpson
"No! Try not. Do... or do not. There is no try." - Yoda
"It takes years of training to know when to do nothing" - Dogbert 1/21/00

Opinions expressed are property of my evil twin, not my employer.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 09 Feb 2000 15:26:06 +0100

>100% DNS lookup success doesn't stand up to a moment's scrutiny.

It is good to know that Internet Explorer 5.0 won't survive in the marketplace.

                   Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Wed, 9 Feb 2000 21:31:24 -0500

>not justified by the facts.

Since I am not sure what is prompting this thread, I went back to the
original message and the RFC.

The RFC is a BCP, not a standard (STD).  The document does not claim
conformance with RFC 2119, which gives meaning to "MUST," etc., as terms of
requrements.  Given the BCP status and no claim that RFC 2119 applies, I
think you are interepreting the document in the wrong way.  This is a
recommendation, not a protocol requirement.

Just to over explain my point, here is one use of the word "must" that
addresses the paragraph I repeated from your message.

#3.1. Selecting Secondary Servers
...
#   Secondary servers must be placed at both topologically and
#   geographically dispersed locations on the Internet, to minimise the
#   likelihood of a single failure disabling all of them.

"Must" means that to achieve the ability to withstand a single failure, the
servers have to be dispersed.  This makes sense to me.

The word "must" appears just 5 more times in the document.  In section 4.
must is used to define a sequence of steps needed to arrive at a decision.
In 4.3, the word must is used to describe actions needed "to avoid these
problems."  In section 5, the use of the word must is a bit questionable
because a phrase like "to achieve reliability" is missing.  This is a
quibble, the sentance is shown below.  Finally, in section 7, the word must
is used to illustrate the operation of the protocol.

# 5. How many secondaries?
#
#   It is recommended that three servers be provided for most
#   organisation level zones, with at least one which must be well
#   removed from the others.  For zones where even higher reliability is
#   required, four, or even five, servers may be desirable.  Two, or ...

"Well removed" could be interpreted as being "on another machine" though.

After going through this, I wouldn't agree that the document is "harmful."