Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!ucsd!ucbvax!VENERA.ISI.EDU!pvm
From: pvm@VENERA.ISI.EDU (Paul Mockapetris)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: DNS glue records and BIND 4.8
Message-ID: <9009251622.AA13093@venera.isi.edu>
Date: 25 Sep 90 16:22:54 GMT
References: <1918@ccadfa.adfa.oz.au>
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: pvm@venera.isi.edu
Distribution: inet
Organization: The Internet
Lines: 28

The right way to think about this is that you want to define a zone as
a data structure that "works", without regard to primary, secondary,
and other zones, subzones, etc.  While an incorrectly defined zone may
not fail if its subzones are on the same server, or if the right data
is in the cache, why take chances?  Someday, someone will move the
subzone, or the cache won't have the right data, ...

When do you need glue data?

You need glue data when the NS RRs marking a delegation refer to name
servers which are within that delegation (or its descendants).  For
example, when the EDU zone delegates the zone ISI.EDU, it refers to
servers Venera.ISI.EDU VAXA.ISI.EDU, and VAX.DARPA.MIL.  Since
Venera.ISI.EDU and VAXA.ISI.EDU (the servers) have names which are in
the ISI.EDU zone, glue A RRs are required.  Glue is not required for
VAX.DARPA.MIL, since it isn't descended from ISI.EDU.

Note that one upshot of all this is that you never need glue in the
reverse mapping domains under IN-ADDR.ARPA part of the tree, unless
you create a name server on a machine <something>.in-addr.arpa.
Please don't do this anyway.

There are some special cases, for example the root zone, and NS RRs
that are using aliases (which you shouldn't do anyway.)

As a last piece of advice, if you aren't sure, put in the glue.

paul