Re: RFC 2182 considered harmful

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

Brian Wellington writes:
> No, but it's an inconveience, especially if an interactive process is
> doing the lookup and the name server doesn't respond for a transient
> reason.

I'm sorry, but you're still not making yourself clear.

Exactly what situation are you thinking of? What difference do you think
a third-party DNS server would make in that situation? Why do you think
that the current situation would be less convenient?

If the NYU network is inaccessible, for example, and users try to
interactively access www.nyu.edu, then the accesses will fail. In this
situation, a third-party DNS server would waste time for the users,
because a TCP connection failure is less likely to be cached than a DNS
lookup failure is. So this can't be what you're thinking of.

Later you talk about ``increased reliability.'' But you have failed to
coherently articulate any benefit of reliable nyu.edu DNS lookups when
the nyu.edu servers are down. Your argument so far, like the argument in
RFC 2182 itself, consists of rhetoric not justified by the facts.

> I'd imagine that the two NYU servers on different networks 

You're reading far too much into the difference in IP addresses. There's
a single machine listening on both 192.76.177.18 and 128.122.253.92. A
single power outage, or a failure of one router, could take out the
entire nyu.edu network, including all the DNS servers. This is clearly
contrary to the letter and spirit of RFC 2182.

> > > How about MX records pointing to an off-site backup mail server?
> > There don't seem to be any of those in the nyu.edu network.
> That was just an example.  There are in many other networks.

There are a few, yes, and we can look at them next. But first let's
settle the question of whether RFC 2182 is wrong for nyu.edu.

  [ third-party DNS service increasing security risks ]
> Is this the message that includes 'the attacker gains control of
> ns.netsol.com'.  That's a pretty strong assumption.

No, it isn't. That was an example to illustrate the subtle but crucial
mistake that you're making. Read my message more carefully.

  [ third-party DNS service increasing data-integrity risks ]
> Zone files being truncated isn't too common,

I said that adding third-party servers increases the chance of this type
of disaster. I didn't say that the resulting chance is huge---although
granitecanyon, which you mentioned later in your message, has had
several serious failures. Different sites will assign different weights
to this risk.

  [ third-party DNS service increasing efficiency risks ]
> I don't understand where the annoying delays are coming from.

If NYU were to add a third-party DNS server, users trying to access
www.nyu.edu would experience an annoying delay in the following
combination of circumstances:

   (1) the third-party server is inaccessible,
   (2) the NYU servers are accessible,
   (3) the user's local DNS cache doesn't have the information, and
   (4) the cache contacts the third-party server first.

The same delay does not exist now.

  [ third-party DNS service slowing down emergency changes ]
> Not if the SOA refresh is set to a reasonable value.

Most secondaries refuse to refresh more often than every 15 minutes. I'm
not saying that immediate refresh wipes out the bad data immediately,
but it does reduce the overall harm.

---Dan