Subject: Re: RFC 2182 considered harmful

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

Let's see if we can come to agreement on the nyu.edu example.

Brian Wellington writes:
> Sure looks like different networks.

It's not. All the addresses are on the NYU network. They all go through
the same gateway, namely nyugwa-fa1-0-0.nyu.net.

RFC 2182 says that secondary servers ``must be placed at both
topologically and geographically dispersed locations on the Internet.''
The NYU servers are neither topologically nor geographically dispersed.

Can we agree that RFC 2182 strongly and clearly recommends against what
NYU is doing?

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

> Recovery from transient failures?

What are you talking about? Have you fallen for the myth that mail will
bounce when all DNS servers are unreachable? It's simply not true.

Are there any other alleged benefits of third-party nyu.edu DNS servers?

> An unnecessary point of failure?  How?

Security viewpoint: See my recent bugtraq message on the 200 computers
that are currently authorized to take over *.com.

Reliability viewpoint: Is the third-party server running reliable
software? The Linux filesystem can corrupt the zone file if the power
goes out at the wrong moment. I'm also told that old versions of BIND
could truncate zone files.

Efficiency viewpoint: Users would see annoying delays more often than
they do now---unless all the third-party outages align perfectly with
NYU outages.

Other, more predictable, costs of adding a third-party server:

   * It takes time and effort to locate a suitable third party and set
     up zone transfers.

   * It takes more time and effort to track changes in the name or IP
     address of the third-party server.

   * It takes even more time and effort to arrange for fast propagation
     of an urgent change.

So far there's no evidence of any benefits, let alone benefits that
outweigh these costs.

---Dan

---

From: Brian Wellington <[email-masked]>
Date: Tue, 8 Feb 2000 22:49:28 -0500 (EST)

> Can we agree that RFC 2182 strongly and clearly recommends against what

Depends on which part of RFC 2182.  3.2 says "servers for a zone should
certainly not all be placed on the same LAN segment in the same room of
the same building - or any of those."  I'd imagine that the two NYU
servers on different networks are at least not in the same room as each
other.  It does seem to contradict the "must" in 3.1.

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

> bounce when all DNS servers are unreachable? It's simply not true.

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.

> that are currently authorized to take over *.com.

Is this the message that includes 'the attacker gains control of
ns.netsol.com'.  That's a pretty strong assumption.  If they can do that,
there's a good chance that they can take over your computer also.

> could truncate zone files.

Again, is the local server that reliable?  If so, then even if the
secondary fails, queries will still be answered by the primary.  Zone
files being truncated isn't too common, and a reasonable server should
notice an invalid file (since trucation would likely be mid-record) and
refuse to load bad data.

> they do now---unless all the third-party outages align perfectly with

I don't agree here.  In the highly unlikely event that NYU is down, it's
pretty unlikely that the secondary would be down also.  I don't understand
where the annoying delays are coming from.

>    * It takes time and effort to locate a suitable third party and set

Minimal.  There's always granitecanyon or one of the other free domain
hosting services if you can't find anything better.

>      address of the third-party server.

It shouldn't change that often.  If it does, it probably wasn't a good
choice.

>    * It takes even more time and effort to arrange for fast propagation

Not if the SOA refresh is set to a reasonable value.  The biggest obstacle
in quickly changing data is caching, not secondaries.

> So far there's no evidence of any benefits, let alone benefits that

The benefit is increased reliability in some cases.  The cost is
negligible.  In my opinion, at least.

Brian

---

From: "D. J. Bernstein" <[email-masked]>
Date: 10 Feb 2000 00:31:37 -0000

> doing the lookup and the name server doesn't respond for a transient

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.

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