On Sat, Jun 18, 2011 at 4:22 PM, Michael Sinatra <mich...@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 _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
