<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 12/05/2014 12:30 PM, Casey Deccio
wrote:<br>
</div>
<blockquote
cite="mid:CAEKtLiQRbCFBDCSdNVxBjXTjvi_NX5XzzFY1D8f4Lwhg8M3UGg@mail.gmail.com"
type="cite">
<div dir="ltr">On Fri, Dec 5, 2014 at 11:47 AM, Robert Moskowitz <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:rgm@htt-consult.com" target="_blank">rgm@htt-consult.com</a>></span>
wrote:<br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">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).<br>
</blockquote>
<div><br>
</div>
<div>Short answer: you don't need, nor should you configure
glue, for the servers run by the other domains.<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
thanks<br>
<br>
<blockquote
cite="mid:CAEKtLiQRbCFBDCSdNVxBjXTjvi_NX5XzzFY1D8f4Lwhg8M3UGg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
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]:<br>
<br>
</div>
"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."<br>
<br>
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]:<br>
<br>
"These NS RRs list the names of hosts for a zone at or above
SNAME. Copy<br>
the names into SLIST. Set up their addresses using local
data. It may<br>
be the case that the addresses are not available. The
resolver has many<br>
choices here; the best is to start parallel resolver
processes looking<br>
for the addresses while continuing onward with the addresses
which are<br>
available."<br>
<br>
</div>
<div class="gmail_quote">Cheers,<br>
Casey<br>
<br>
[1] <a moz-do-not-send="true"
href="http://tools.ietf.org/html/rfc1034">http://tools.ietf.org/html/rfc1034</a><br>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>