In message <caektliqrbcfbdcsdnvxbjxtjvi_nx5xzzfy1d8f4lwhg8m3...@mail.gmail.com> , Casey Deccio writes: > > On Fri, Dec 5, 2014 at 11:47 AM, Robert Moskowitz <r...@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: ma...@isc.org _______________________________________________ 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