Glue records for secondary NS

[Robert Moskowitz]

On 12/05/2014 12:30 PM, Casey Deccio wrote:
> On Fri, Dec 5, 2014 at 11:47 AM, Robert Moskowitz <rgm at htt-consult.com 
> <mailto:rgm at htt-consult.com>> wrote:
>
>     I have 3 secondaries run by other domains.  This was to give me
>     some geo-diversity.  How do I create glue records for them?  My
>     registrar only lets me create glue records within my domain (the
>     web form pre-provides the domain part of the fqdn).
>
>
> Short answer: you don't need, nor should you configure glue, for the 
> servers run by the other domains.

It would be nice, then, if all these DNS tool sites would know this and 
not report missing glue records over NS servers in other domains.

thanks

>
> Glue is only necessary if the server names (i.e., the NS targets) are 
> subdomains of the child zone.  The reason why they are necessary is to 
> prevent a resolution loop.  Here is the relevant text from RFC 1034 
> (section 4.2.1) [1]:
>
> "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."
>
> If the server names are not subdomains of the delegated child zone 
> (e.g., your case), then the resolver learns the addresses of the names 
> using the normal resolution process. Here is the relevant text from 
> RFC 1034 (section 5.3.3) [1]:
>
> "These NS RRs list the names of hosts for a zone at or above SNAME.  Copy
> the names into SLIST.  Set up their addresses using local data.  It may
> be the case that the addresses are not available.  The resolver has many
> choices here; the best is to start parallel resolver processes looking
> for the addresses while continuing onward with the addresses which are
> available."
>
> Cheers,
> Casey
>
> [1] http://tools.ietf.org/html/rfc1034

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20141205/d45eb8a9/attachment-0001.html>