Glue records for secondary NS

[Mark Andrews]

In message <CAEKtLiQRbCFBDCSdNVxBjXTjvi_NX5XzzFY1D8f4Lwhg8M3UGg at mail.gmail.com>
, Casey Deccio writes:
> 
> On Fri, Dec 5, 2014 at 11:47 AM, Robert Moskowitz <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.
> 
> 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]:

There are other cases where glue is necessary.  RFC 1034 unfortunately
does not list them.  It only lists the most obvious case.

All the nameservers for zone A are in zone B and all the nameservers
for zone B are in zone A.  

You can avoid getting into that state by requiring a server to serve
the zone it lives in.  If you have that rule then you only need to
add glue when a nameserver is beneath a zone cut, otherwise you need
wider applicability.

Note this is not all the nameservers for a zone need to live in the
zone.

Named accepts glue beneath the parent zone and also checks for
missing glue beneath the parent zone.  This avoids some but not all
of the cases above.  Unfortunately some registrars believe RFC 1034
rather than reality.  The assumption behind the paragraph below is
that nameservers would serve the zone they live in.

Instead we go through several sets of servers today before we find
servers with glue from the parent.

e.g. Amazon uses 2, client -> glueless -> glue.

bunnings.com.au.	14400	IN	NS	ns-619.awsdns-13.net.
bunnings.com.au.	14400	IN	NS	ns-1414.awsdns-48.org.
bunnings.com.au.	14400	IN	NS	ns-210.awsdns-26.com.
bunnings.com.au.	14400	IN	NS	ns-1836.awsdns-37.co.uk.
awsdns-13.net.		172729	IN	NS	g-ns-783.awsdns-13.net.
awsdns-13.net.		172729	IN	NS	g-ns-462.awsdns-13.net.
awsdns-13.net.		172729	IN	NS	g-ns-1933.awsdns-13.net.
awsdns-13.net.		172729	IN	NS	g-ns-1357.awsdns-13.net.

> "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
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org