Re: Bogus nic.fr behavior

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

My DNS cache handles 127.0.0.1 automatically. My DNS server, by default,
does not.

Robert Elz writes:
> Since 0.0.127.in-addr.arpa isn't delegated anywhere, the only way a
> server can support a name to address translation of 127.0.0.1 (which
> is a well known addres) is by being configured with that particular
> PTR record.

So you claim that the delegation of .com to j.gtld-servers.net is broken
because j.gtld-servers.net doesn't know about 127.0.0.1? You've already
sent a letter to the .com server administrators demanding that they fix
this horrible misconfiguration?

> Hosts Requirements says that supporting address to name translation
> is a MUST for servers.

You mean the part that says ``a host MUST provide a DNS interface to
facilitate translation between host addresses and host names''? Please
explain how j.gtld-servers.net is violating this requirement.

> We now have quite a few years of operational experience as to what works,

Yeah. That delegation of .com to the .com servers obviously doesn't
work. I bow down to your superior knowledge, Lord of All Things DNS.
Let's put you in charge of the root servers so that you can break .com.

> To get "smooth transfer" the new servers should be set up, and then
> the old servers made secondary for that (so they start giving out the
> new data).   Then the parent should be updated.

Unfortunately, your procedure triggers a serious BIND bug, as explained
in http://cr.yp.to/djbdns/bugtraq/20000112082807-15140-qmail@cr-yp-to.

To avoid the bug, you have to make sure that there's always an overlap
between the NS names listed in the parent and the NS names that caches
might have (old names from the parent, old names from the child, new
names from the child).

This problem goes away if NS names are unchanging names in the server's
bailiwick: e.g., tmcs.net has servers a.ns.tmcs.net, b.ns.tmcs.net, etc.
But this doesn't work with the .com one-name-one-address policy when
someone switches ISPs.

> the parent data is just glue, and should always
> be identical to that in the zone itself.

The unfortunate reality is that some parents have limitations like ``at
most two NS records.'' But this is a side issue; obviously the same
parents don't complain about these limitations in their delegations.

---Dan