• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

Glue records clarification

Started by helporg, October 12, 2012, 07:01:53 PM

Previous topic - Next topic

helporg

I have always been confused about the definition of "glue records."   Looking at ipv4 first.

I have domain example.com.  I go to my registrar and register an IP for "ns.example.com" of "1.2.3.4".  Now the registry for .com publishes in the zone file:

ns.example.com  1.2.3.4

I thought this was the "glue records"

However, many people say to get the "glue records" use

dig NS example.com @a.gtld-servers.net | grep A

Doesn't that just gets the nameserver host name from the zone file and then the rest of the information from what is in the authoritative nameserver?  Suppose I maintain a different IP in my authoritative nameserver for ns.example.com:

ns.example.com  5.6.7.8

Doesn't
dig NS example.com @a.gtld-servers.net | grep A
return "5.6.7.8" which is not really the correct "glue record" published in the zone file?

Maybe I am missing something but if this is the way it works it seems to me it doesn't matter what IP addresses the registry publishes for the nameservers, just the host names matter.  It would also not matter if the registrar publishes an IPv6 address because wouldn't dig NS example.com @a.gtld-servers.net | grep AAAA still work even if they did not publish an IPv6 address in the zone file?


snarked

#1
It is not proper to have the label resolve to different values from different sources.  That is an inconsistency resulting in a broken construct, and therefore an error.

A glue record is a little more than a host registered via the domain registrar.

It is a name server address record which falls within (or under) the zone it serves, and therefore must be posted to the name server serving the parent's zone.  It is a record that without such a posting to the parent's zone would leave the child zone unresolvable due to a circular dependency.

One can't query the name servers "ns*.example.com" for "example.com" by simple resolution to the zone itself - because one simply can't get there from the root.  The glue address record for the name server of the child zone posted into the parent zone is how one gets around the circular dependency.

An out-of-child-zone name server will NOT normally require a glue record.  However, a circular dependency across multiple domains/zones can be created - and in that situation, one zone having an out-of-zone glue record would be necessary to break that dependency.  Example:
Quoteexample.com -> ns.example.edu
example.edu -> ns.example.org
example.org -> ns.example.com
Such a name server relationship would require a single glue record somewhere to break the cyclic relationship.  The interesting thing here is that the necessary glue record would be out-of-zone and thus normally not thought of as glue, but is just as required as the in-zone type.

helporg

Yes, that is what I always thought.

However, the registries also register an IP address along with the host name for nameservers.  In the past I have forgotten to change that IP address registration with the registry after I changed networks and it seemed to have no effect.  So it seems the IP address portion of the nameserver registration with the registry is not used in any practical manner.

This would mean that it doesn't matter if the registry published an IPv6 glue record in the zone files because all that matters is the host name.  It that is true why do the registries publish these IP's at all and why is there a concern about registries supporting IPv6 address glue records?

snarked

QuoteSo it seems the IP address portion of the nameserver registration with the registry is not used in any practical manner.
I must disagree. What has probably happened is that at least one of your name servers (even if not glue) was still reachable by having its IP address(es) the same in both parent and child zones (if present in both), and that one was used to reach the zone data.  You should find that if ALL of the name servers had different addresses as glue than what is in your zones and that the servers at the "old" addresses didn't have current copies of the zone, your zone data would be unreachable (and you'd get either servfail or lame delegation error messages in your logs).

As far as IPv6 goes, remember that most hosts that support it also have an IPv4 stack, so they may be resolving the problem via IPv4.  An IPv6-only host would fail.