Subject: Re: RFC 2182 considered harmful

From: "D. J. Bernstein" <[email-masked]>
Date: 9 Feb 2000 00:59:34 -0000

Olafur Gudmundsson writes:
> there is nothing wrong with the RFC and it's requirement. 

Are you claiming that nyu.edu should use third-party name servers?
Surely you admit, as RFC 2182 does, that this would increase
administrative costs. What precisely would the benefit be?

Or are you agreeing that RFC 2182 is wrong in the nyu.edu case, but
claiming that these exceptions are rare? Do you think it's okay to give
incorrect advice to 1% of DNS administrators? 5%? 25%? 90%?

> Different sites have different fault tolerance requirements,

That's certainly true. But the vast majority of system administrators do
not define ``fault tolerance'' as merely ``keeping DNS up.''

I realize that TLD administrators are an exception. But they're a tiny
fraction of the RFC 2182 audience.

> yours are not typical,

That's blatantly incorrect. There are a huge number of small-business
domains and personal domains whose entire function is to advertise

   * one web server,
   * one mail server, and
   * one or two DNS servers,

all on the same network---sometimes the same machine. In this extremely
common situation, RFC 2182's recommendations are wrong.

There are, furthermore, a huge number of domains whose entire function
is to advertise

   * several web servers,
   * several mail servers,
   * some other servers and workstations, and
   * two or three carefully monitored DNS servers,

all on one network. Here, too, RFC 2182's recommendations are wrong.

Are we happy when the network is inaccessible? Of course not. Users
can't see the web pages. Mail delivery is deferred. These are serious
problems---which third-party DNS service does _nothing_ to fix.

Of course, a large corporation with multiple independent networks will
replicate its DNS service, its HTTP service, its mail service, etc.,
across these networks. But RFC 2182 is misleading even in this case: it
overstates the importance of one service, and foolishly recommends
relying on third-party servers, adding an unnecessary point of failure.

---Dan

---

From: Brian Wellington <[email-masked]>
Date: Tue, 8 Feb 2000 20:29:36 -0500 (EST)

> Are you claiming that nyu.edu should use third-party name servers?

Well...

anomaly:~: dig nyu.edu ns

; <<>> DiG 8.2 <<>> nyu.edu ns 
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 4
;; QUERY SECTION:
;;      nyu.edu, type = NS, class = IN

;; ANSWER SECTION:
nyu.edu.                3d19h4m17s IN NS  nyu.edu.
nyu.edu.                3d19h4m17s IN NS  EGRESS.nyu.edu.
nyu.edu.                3d19h4m17s IN NS  NYUNSB.nyu.edu.

;; ADDITIONAL SECTION:
nyu.edu.                29S IN A        192.76.177.18
nyu.edu.                29S IN A        128.122.253.92
EGRESS.nyu.edu.         29S IN A        128.122.128.24
NYUNSB.nyu.edu.         3d19h4m18s IN A  128.122.253.37

;; Total query time: 1 msec
;; FROM: anomaly.xbill.org to SERVER: default -- 127.0.0.1
;; WHEN: Tue Feb  8 20:15:56 2000
;; MSG SIZE  sent: 25  rcvd: 145

Sure looks like different networks.  The networks aren't too topologically
diverse, but it's better than all servers pointing to the same machine.

> administrative costs. What precisely would the benefit be?

How about MX records pointing to an off-site backup mail server?  Recovery
from transient failures?

> incorrect advice to 1% of DNS administrators? 5%? 25%? 90%?

Has anyone clearly established that the advice is incorrect?

> all on one network. Here, too, RFC 2182's recommendations are wrong.

Maybe.  But having a backup name server isn't wrong.  If someone doesn't
want to do it, they can, but it should be stated that it's a bad idea. 

> problems---which third-party DNS service does _nothing_ to fix.

In some cases, this is true.  But again, third party DNS doesn't hurt
either. 

> relying on third-party servers, adding an unnecessary point of failure.

An unnecessary point of failure?  How?  If the third party DNS server goes
down, the other server (presumably local to the corporation) is still up,
and there's no loss of service.

Brian

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Tue, 08 Feb 2000 22:31:22 -0500

Dear Mr. Bernstein,

RFC 2182 is correct.  There are many uses for DNS data, including
those related to network management such as name <-> address
translations in viewing log files or studying "received:" header
lines, MX'ing to alternate servers, and even domain name surveys.
Reasonable efforts should be made to have DNS data available at all
times.

Furthermore, in most cases of a small-business with one domain, one
web server, etc., the business contracts for all of this to be
remotely hosted or even if it is local, the domain registration and
DNS service are bundled into the service package by the ISP which is
derelict in its duty if it does not arrange reasonable backup for DNS
service for all the domains it contracts to support.

Additional servers aren't a point of failure, they are a point of
robustness.

Please stop advocating poor DNS management.

Donald

From:  "D. J. Bernstein" <[email-masked]>
Date:  9 Feb 2000 00:59:34 -0000
Message-ID:  <[email-masked]>
To:  [email-masked]

---

From: Bruce Campbell <[email-masked]>
Date: Mon, 14 Feb 2000 16:23:46 +1000 (EST)

djb> Olafur Gudmundsson writes:
djb> > there is nothing wrong with the RFC and it's requirement. 
[on small networks with everything on one host]
djb> Are we happy when the network is inaccessible? Of course not. Users
djb> can't see the web pages. Mail delivery is deferred. These are serious
djb> problems---which third-party DNS service does _nothing_ to fix.

urm.  I question the 'Mail delivery is deferred' section, particularly
when a small operation has an extended outage (ie, the owner has gone off
on holidays for a fortnight).

Having mail bounce back with some obscure message about unable to resolve
the hostname after trying continually for the past 7 or so days because
some admin thinks RFC2182 is 'not the best practice' merely reinforces the
'fly-by-night' impression such small sites tend to give out.

If they're running an e-business... oh dear, have they just lost
customers?  Now if only they'd taken some precautions... such as a
third-party DNS server..

I think the point here is that you get what you pay for.

Regards,

-- 
  Bruce Campbell <[email-masked]>        My opinions are my own.
                      Systems Administrator
    Asia Pacific Network Information Centre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 15 Feb 2000 01:08:20 -0000

Illustration of the security point: www.rsa.com was recently corrupted,
apparently through a breakin at one of the not-very-secure secondaries.
Breaking the DNS protocol or the primaries would have taken more work.

Donald E. Eastlake 3rd writes:
> There are many uses for DNS data,

There are many uses for web-page data, but anyone who demanded that all
web pages be online all the time, without regard to the costs, would be
correctly branded a fool.

> name <-> address translations in viewing log files

Record the name at the time of making the log entry, in parallel with
whatever else you're doing. Unlike your approach, this protects against
subsequent failures of the local network.

> MX'ing to alternate servers,

Irrelevant to the sites under discussion.

> and even domain name surveys.

Silly argument. The surveyor can easily retry failing domains over a
reasonable period to see which failures are persistent. Unlike your
approach, this protects against failures of the surveyor's network.

> Please stop advocating poor DNS management.

Please stop making recommendations not justified by the facts.

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 15 Feb 2000 01:11:52 -0000

> 'fly-by-night' impression such small sites tend to give out.

So you think that having mail bounce back with, say, ``Unable to find
cafax.se during the past week'' gives a fly-by-night impression that
will lose customers, while ``Unable to connect to cafax.se during the
past week'' gives the impression of a solid, well-managed site that
really wants your business?

---Dan