Re: RFC 2182 considered harmful

["D. J. Bernstein" <djb@cr.yp.to>]

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