Re: RFC 2182 considered harmful

[Brian Wellington <bwelling@tislabs.com>]

On 9 Feb 2000, D. J. Bernstein wrote:

> 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?

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.

> Surely you admit, as RFC 2182 does, that this would increase
> administrative costs. What precisely would the benefit be?

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

> 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%?

Has anyone clearly established that the advice is incorrect?

> > 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.

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. 

> 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.

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

> 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.

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