nameserver registration

[Casey Deccio]

On Sat, Jun 18, 2011 at 4:22 PM, Michael Sinatra
<michael at rancid.berkeley.edu> wrote:
>  Consider:
>
> baz.org.  NS ns1.dns.podunk.edu.
> baz.org.  NS ns2.dns.podunk.edu.
>
> and
>
> dns.podunk.edu. NS ns1.dns.podunk.edu.
> dns.podunk.edu. NS ns2.dns.podunk.edu.
>
> In theory, you "should" only need glue in podunk.edu, but podunk.edu isn't
> under the control of any registry (or registrar for that matter).  If the
> registrar for baz.org wants to be sure that things are going to work--and
> that they will stay working--then you need appropriate glue at a higher
> level.
>

Unfortunately, that won't work.  It violates the principle of "glue".
>From RFC 1034 (emphasis on the last sentence):

In particular, if the
name of the name server is itself in the subzone, we could be faced with
the situation where the NS RRs tell us that in order to learn a name
server's address, we should contact the server using the address we wish
to learn.  To fix this problem, a zone contains "glue" RRs which are not
part of the authoritative data, and are address RRs for the servers.
These RRs are only necessary if the name server's name is "below" the
cut, and are only used as part of a referral response.

Even if referring servers return such RRs, they are considered
out-of-bailiwick, and resolvers should resolve the names, rather than
trust the additional RRs.  i.e., .org servers should not be handing
out RRs under .edu.  Hence the dependencies, which can get long and
complicated, but they're part of the DNS.

Casey