Re: Bogus nic.fr behavior

[Robert Elz <kre@munnari.OZ.AU>]

    Date:        6 Feb 2001 00:09:12 -0000
    From:        "D. J. Bernstein" <djb@cr.yp.to>
    Message-ID:  <20010206000912.28897.qmail@cr.yp.to>

  | Servers (as opposed to caches) should not have root information unless
  | they are root servers.

From where did this startling variation on accepted practice arrive?

All servers, when queried, should either return an answer (doing the
recursive thing if they want to, and that was requested in the query)
or should return a referral to a better server to ask.   When no other
information is available, the root servers are the better server to
ask.   This has been a part of DNS operations since day 1.

It doesn't matter whether you think the server in question should ever
have been sent the query or not.

  | Caches will never ask for the information;

You mean a cache which is operating and configured properly won't.

  | and there's a cost to copying the information and worrying about keeping it
  | up to date. These are not new observations.

There is, and no, they're not.   Fortunately most rational servers do
the trivial amount of work of finding the root servers and maintaining
that info.   Considering what was supposed to be asked of servers in the
previous little debate (mostly on the ipng list) this amount of work is
in the positively trivial and absolutely easy category.

  | Unfortunately, the .fr administrators won't delegate to servers that
  | don't have the current root NS records and corresponding A records.

Sounds like an entirely reasonable policy to me, and perhaps one I should
consider adopting in AU as well.  In general anything the DNS registrars can
do to help educate people as to what is sanely & properly configured, and
what is bogus (ie: to force them to learn, rather than just provide
information and hope) has to be a long term benefit for the net.

  | This is not an isolated example. They also insist on TCP service even if
  | you don't have any big records,

That's probably technically slightly too much (TCP support is just
a SHOULD I think), but in practice it is a good thing to check - your
average DNS administrator is never going to be able to work out when
they need TCP and when they don't (and a server implementation is very
unlikely to do so reliably either) - simply telling people to make sure
their servers support TCP and then verifying that is probably no bad thing.

Aside from anything else, I have seen cases where UDP DNS servers are
doing PMTU discovery, and then sending pre-fragmented responses, and then
brain-dead firewalls along the path are dropping the non-initial fragments.
Sometimes the only wat to get an answer from such a server is to use TCP
(then you just get smaller segments instead of fragments).

  | and 1.0.0.127.in-addr.arpa PTR records,

Hosts Requirements says that supporting address to name translation
is a MUST for servers.   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.

  | and various other server behaviors that are not relevant to DNS service.

The DNS service is more than just the protocols as strictly defined.
We now have quite a few years of operational experience as to what works,
and what does not = and what is needed to be configured and what is not.

  | Where does this disease come from? Even if the .fr administrators are
  | confused about how DNS works, why do they care what other servers do?

Part of the process of ensuring that the overall DNS (which affects all
of is) is healthy is to diagnose the problems early, and try and get them
fixed.   One of the best ways to achieve that is to simply refuse to
delegate to servers that don't function correctly.

kre