Re: How long can an NS chain be?

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

    Date:        24 Dec 1998 03:12:02 -0000
    From:        "D. J. Bernstein" <djb@cr.yp.to>
    Message-ID:  <19981224031202.29678.qmail@cr.yp.to>

  | There's no guarantee in the DNS architecture that this chain will ever
  | terminate.

In the architecture, no.  In fact, leaving aside rules which would be 
operationally obscene (such as requiring NS records to have no more labels
than the domain they describe, or requiring that servers be always named
inside the doamin they serve, mandating glue always) I doubt that there
is anything the architecture can do about this.

Operationally on the other hand, setting up a chain of delegations the way
you described would be foolish, at best.   A good operational rule of thumb
is that if you delegate NS responsibility to some nameservers not under
your own domain, then the nameservers to which you delegate should also be 
nameservers for their own domain.   Aside from the NS chain chasing problems,
there's also the question of the wisdom of having your domain managed by
someone who isn't willing to run their own domain.  The chances are there's
a reason they have someone else running their domain...

  | In fact, there could be a cycle; length-1 cycles are required
  | to have glue, but longer cycles are not.

1034/1035 are undeniably week where glue is discussed.   Strictly glue is
required whenever it is needed, and no other time.   Which isn't much of a
definition, but it is about the best we can do.   It all gets worse when it
is realised that a random, seemingly unrelated, change somewhere else in
the DNS can cause glue to become required, where it wasn't before.   Of
course only an operationally poor setup initially is likely to actually
experience that.

It used to be that common operational practice was to stick glue (using its
broader definition, of anything in a zone file that doesn't belong there)
all over the place - anywhere it could conceivably be useful.   But the
maintenance nightmare of keeping all of that up to date, coupled with a
common implementation (very common) which at the time treated glue as about
the equal of authoritative data, coupled with that not actually being much,
as authoritative data would be overridden by anythig received in a reply
(including something which originated as bad glue somewhere else) led to
glue being treated as a pariah (the implementation would have been better
blamed) so that today the tendancy is to minimise it, even to the point where
necessary glue can be ignored.

  | Suppose, however, that the NS chain does terminate. It could have any
  | length. Is it okay for people to set up an NS chain of length 5? 10? 30?

Technically, yes.  Operationally it would be foolish.

  | How far does a resolver have to go?

However far it wants to get a suitable quality of service.  It will
always be a trade off - keep hunting and perhaps eventually find an answer,
against causing a name lookup to take an interminable period of time.

There are no requirements, you do what you like, if that means that you
fail to find names that others find, then the resolver is likely to be
replaced.   On the other hand, if you spend forever chasing circular reference
chains, the same fate is likely to await.

  | Can a resolver ignore NS records without
  | glue if there are three NS records with glue?

Resolvers have always been free to use NS records as they see fit.  "Ignore"
would not be good, but certainly preferring the NS records for which A
records are available (leaving aside whether the A comes from glue or not)
would be a reasonable strategy.   While continuing the lookup via that
path however, a good resolver will probably also be attempting to locate the
missing A records, just in case nothing comes of the path selected.

  | The chance of finding glue is going to drop precipitously as new TLDs
  | are introduced.

I don't know.   Follow the rule of thumb above, and there should be few
problems, regardless of the domain name.   Do recall that we already have
a couple of hundred TLDs, those don't seem to be leading to large amounts of
hopelessly poor delegation chains.

  | Users of a
  | resolver with an excessively low NS chain limit will find themselves
  | completely unable to locate certain domains unless the cache is primed.
  | This is an interoperability problem.

Yes - but one easy to fix.  If the resolver is too restricted to handle
chains that occur commonly in practice (ones which other resolvers handle)
then that resolver will be fixed or replaced.   On the other hand, if it is
just a few "certain domains" which can't be handled, and they can't be handled
by many resolvers, then the owners of those domains are likely to notice that
lots of sites can't contact them, and pick some more suitable servers.

This is really similar to the problem of TCP connection establishment.
All TCPs have a timeout after which they give up and report an error to
the user (necessary in case the destination host is just down).   If that
timeout is set too short, there will be parts of the internet which can't
be reached from that TCP implementation.   On the other hand, if someone
stuck themselves at the end of a path that required large numbers of
satellite hops (with their 1/2 second RTTs) to be traversed, or at the end
of several heavily congested 9600 bps links, then it would be expected that
many others will not be able to contact them - if they care, they improve
connectivity.

All that Don Eastlake said in reply seemed pretty right to me.

dns@pneuma.freshwind.com said:
  || ns.greenlight.net should be a glue record in with the .net info.

Only if it was a server for greenlight.net (which was Dan's point)

  || And it will have glue in the InterNIC TLD servers if it was used to
  || register any additional InterNIC names.

  || Additionally, ns.visualtouch.com would not be an InterNIC listed name
  || server unless it had a host (glue) record.

The Internic have been prone to insert lots of unnecessary glue, that is
true.   That probably has saved some sites where the seemingly unnecessary
glue is actually required.

On the other hand, how they're getting round recent BIND innovations which
simply ignore glue that doesn't seem to be essential I have no idea.

  || Recently, I heard that a .nl (or any non-InterNIC TLD) host would no
  || longer be accepted by InterNIC as a name server for an InterNIC name

The InterNIC people can, of course, implement whatever rules they like
(perhaps requiring IANA consent, let's ignore that can of worms here).

It would seem unlikely to me that they'd go that far however.

kre

ps: An informational, or perhaps even BCP, RFC on the topic of DNS glue
is something which would probably do the community service, if anyone would
care to write one.