Re: How long can an NS chain be?

["D. J. Bernstein" <djb@cr.yp.to>]

Robert Elz writes:
> 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.

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

Sure, the implementor can test millions of existing domains, but what
happens when people start setting up longer NS chains next year?

The DNS specifications are inadequate. Domains that comply with BIND's
undocumented limits aren't guaranteed to work with new implementations.
Anyone who writes a resolver is threatened with the possibility of
interoperability disasters. Do you want everyone to copy the BIND code?

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

RFC 1122 specifies a timeout of 3 minutes by default. This is extremely
conservative. There's no threat for new implementors.

> rules which would be operationally obscene (such as
  [ ... ]
> requiring that servers be always named inside the doamin they serve,
> mandating glue always)

Why would it be ``operationally obscene'' to require the form

   domain IN NS inside.domain

for every NS record?

InterNIC already forces its domains to have glue for secondary servers.
If you have to keep track of an off-site IP address anyway, why not give
it a name within your domain?

---Dan