Subject: How long can an NS chain be?

From: "D. J. Bernstein" <[email-masked]>
Date: 24 Dec 1998 03:12:02 -0000

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

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Thu, 24 Dec 1998 10:00:39 -0500

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" <[email-masked]>
Date:  24 Dec 1998 03:12:02 -0000
Message-ID:  <[email-masked]>
Mail-Followup-To:  [email-masked]
To:  [email-masked]

---

From: [email-masked]
Date: Thu, 24 Dec 1998 09:58:29 -0600 (CST)

I see what you are asking but I don't believe that it should happen.

ns.greenlight.net should be a glue record in with the .net info.  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. 

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 (I've
not confirmed this, but perhaps someone else can), which basically insures
that all name servers for InterNIC names will have glue. (No, this doesn't
mean that folx without existing InterNIC domains can't register InterNIC
names.) 

There's no doubt that server admins, especially TLD server admins, can
really screw things up by not doing basic sanity checks.  Does this mean
that other TLDs must insist on having name servers within their authority? 
It may be the easiest answer.  If TLD admins don't provide a means to
register the the InterNIC equivalent of a host record, that is really not
a flaw in DNS, it is an administrative issue.  If non-TLD name server
admins don't see the need to make sure that their name servers are
reachable by providing proper glue in the proper parent zones, that is a
problem in education/understanding, but is not the fault of DNS. 

So... all of that was just to say:  it seems to me that every NS record
should have corresponding glue in its own parent zone.  If it doesn't,
this is an error.  Should grace be built into the system?  I don't know. 
How much do you want to encourage bad administrative practice?  As
browsers became more and more forgiving of HTML errors and nonstandard
tags, HTML became sloppier and sloppier, because the fact that it worked
reasonably well removed most of the motivation to do it correctly in the
first place. Would be a shame (and probably a bit of a disaster) for that
to happen to DNS. 

Just a few thoughts,

Happy Holidays & New Year!

---

From: [email-masked]
Date: Thu, 24 Dec 1998 09:58:29 -0600 (CST)

Just a few thoughts,

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Thu, 24 Dec 1998 10:00:39 -0500

Thanks,
Donald

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 25 Dec 98 22:39:39 JST

Dan;

> terminate. In fact, there could be a cycle;

Yes. This is a known problem people want to ignore.

> glue if there are three NS records with glue? Two? What if those two

RFC 1034 says:

:   1. Bound the amount of work (packets sent, parallel processes
:      started) so that a request can't get into an infinite loop or
:      start off a chain reaction of requests or queries with other
:      implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED
:      SOME DATA.

How many? It depends.

							Masataka Ohta

---

From: Robert Elz <[email-masked]>
Date: Sat, 26 Dec 1998 17:36:11 +1100

| 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.

[email-masked] 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.