Re: How long can an NS chain be?

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

    Date:        5 Jan 1999 17:45:17 -0000
    From:        "D. J. Bernstein" <djb@cr.yp.to>
    Message-ID:  <19990105174517.15318.qmail@cr.yp.to>

  | How exactly is a new implementor supposed to prevent these failures?

Do you mean the practical failures, or the imaginary theoretical ones?

No reasonable implementation is going to have a problem with any
NS setup that is actually used in practice, and works.   Similarly,
none are going to cope with the worst scenarios that can be dreamed
up as technically possible.

  | The DNS specifications are inadequate.

That may be (in this way and others).   However, right now, no-one is
setting out to rewrite them.

  | Why would it be ``operationally obscene'' to require the form
  |    domain IN NS inside.domain
  | for every NS record?

Because for a large nameserver that means thousands of names with A
records aimed at the address in question, and a similar number of
glue A records in the various parent domains.   An address change
under those circumstances is an enormous task.   Even with the
Internic's unnecessary glue (which is a server operator's private
policy, not a DNS requirement, and which other servers do not require)
there is, in practice, just one A record, and one glue A record, for
all of the domains at a server.  Updating that is a reasonable task
(ie: I, as owner of a name that is in the Internic's zone files as
a glue record can, and have in the past, have them update the associated
A records, which causes the update to apply to all of the domains they have
me listed as a server for).

Further, all of that additional data means that caches everywhere
are storing that (compatively useless) information, perhaps in
preference to more useful data that could otherwise be retained.

It could also almost double the size of all zone files (especially the
big ones with lots of domains delegated to comparatively few servers)
That makes zone transfers more work, and the zone itself require more
resources to manage.

I don't know if you've ever run a large nameserver, but believe me, there
are far more operational problems caused by people who use the above kind
of delegation setup, and then forget to get the glue updated (most often,
never imagine that they're supposed to), than there have ever been from
excessively long NS chains.

kre