Re: RFC 2182 considered harmful

[Brian Wellington <bwelling@tislabs.com>]

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

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

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.

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

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

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.

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

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.

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

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.

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

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.


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

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

>    * It takes more time and effort to track changes in the name or IP
>      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
>      of an urgent change.

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
> outweigh these costs.

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

Brian