Re: How long can an NS chain be?

["Donald E. Eastlake 3rd" <dee3@torque.pothole.com>]

There are probably others who could answer this better but I feel in
the mood so...

(1) Isn't the general philosophy of the DNS is to allocate a certain
amount of effort to a particular resolution and give up if you don't
have an answer after expending that amount of effort?  Thus people can
create what ever sort of junk they want without causing any resolvers
to go into infinite loops or the like.  The amount of effort or how to
measure effort isn't specified in the standards.

(2) I always thought the requirements for glue records should be
stronger, requiring them in many more cases.  But that does not
eliminate potential operational problems since the glue can be wrong,
out of date, etc.

(3) Resolvers can adopt whatever server priority strategy they want.
Certainly I think giving preference to NS's with associated glue would
be reasonable under many circumstances.  However, as long as the
resolver is willing to put in more effort, sooner or later it should
try all branches of the tree.

(4) There are well known loop detection techniques, including those
with storage requiements on the order of the log of the loop length.
But plausible DNS NS loops seem to me they would be short enough that
implementing a simple chain length limit, remembering all the hops,
with a simple loop test would be fine, if you wanted to go to that
length.  The general effort limit mentioned in 1 above is adequate to
avoid serious problems even with no other mechanisms.

(5) I'm not sure I would call this an interoperability problem.  More
of an operability problem.  Ideally, I would say, the standards should
specify that resolvers must be able to handle some minimum level of
complexity/effort/loop-length/whatever.  Then those who go beyond that
would be on notice that some may have problems resolving their data.

Thanks,
Donald

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

>Suppose you're trying to find the address of www.come.to. You send out
>some queries and receive a referral:
>
>   come.to IN NS ns.greenlight.net
>   come.to IN NS black.plant.nl
>
>Neither name is in your cache, and there's no glue.
>
>So you put the original request on hold and try to find the address of
>ns.greenlight.net. You send out some queries and receive a referral:
>
>   greenlight.net IN NS ns.visualtouch.com
>   greenlight.net IN NS black.plant.nl
>
>Neither name is in your cache, and there's no glue.
>
>So you put ns.greenlight.net on hold too and try to find the address of
>ns.visualtouch.com. And so on.
>
>There's no guarantee in the DNS architecture that this chain will ever
>terminate. In fact, there could be a cycle; length-1 cycles are required
>to have glue, but longer cycles are not.
>
>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?
>How far does a resolver have to go? How much memory do implementors have
>to dedicate to a single request? Is it okay for a resolver to give up
>after several steps? How many? Can a resolver ignore NS records without
>glue if there are three NS records with glue? Two? What if those two
>servers are unreachable?
>
>The chance of finding glue is going to drop precipitously as new TLDs
>are introduced. Chains are going to get longer and longer and longer,
>even if nobody falls into the trap of setting up a cycle. 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.
>
>---Dan