I think you might be a bit confused by the definition of glue records. As a very brief summary of the process: When you register a domain (example.com) with a domain registrar you need to provide hostnames for the nameservers which will be authoritative for that domain.
If the nameservers exist on the same domain as that which you are registering (ns0.example.com) then you will also need to provide IP addresses for them. These will form your glue records. Without these glue records, DNS lookups will become stuck in a catch-22 situation whereby they don't know how to resolve a domain's address because they can't first resolve the nameservers.
However if the nameservers exist on a different domain then no glue records are required. You simply provide hostnames (no IP addresses) for the nameservers and DNS lookups will resolve these first before then resolving the requested domain.
With this in mind there are two possible scenarios for what you are trying to do. From what you have described I suspect that the first one applies to you:
If all of the client domains have a nameserver of ns1.ourcompany.com
in the zonefile and WHOIS records then you will only need to change the IP address stored in zonefile and glue records for the domain ourcompany.com
. Because this is the only self-referential hostname that needs bootstrapping during the lookup process.
If each client domain uses ns1.customersdomainname.com
and has a glue record pointing at your IP address then you have a bit more work to do. You will need to update each and every one of the domains. Some registrars provide APIs which you can use to automate the changes. While you are at it though, I'd advise consolidating to the setup that I described above, to prevent a repeat of such work in the future.
To add to Mit's answer. The best practice is to only use Glue Records to resolve those circular dependencies. See section 2.3 of RFC1912: http://www.faqs.org/rfcs/rfc1912.html
To quote:
Some people get in the bad habit of
putting in a glue record whenever
they add an NS record "just to make
sure". Having duplicate glue
records in your zone files just makes
it harder when a nameserver moves
to a new IP address, or is removed.
You'll spend hours trying to figure
out why random people still see the
old IP address for some host,
because someone forgot to change or
remove a glue record in some other
file. Newer BIND versions will ignore
these extra glue records in local
zone files.
Note that last bit if you're using BIND. Also, I think most DNS clients will ignore extra-domain glue records, which would explain what you're seeing.
Edit to follow up on comment.
With TLD glue records, you'd typically provide them to your registrar, but otherwise the same rules apply. I run domains in .co.uk
and .com
. I also have name servers in both of those TLDs that are authoritative for all of my domains.
If I run dig ns co.uk
and dig ns com
, I can see the big heap of servers that are authoritative for those TLDs. If I pick one of those listed .com
servers and dig @<server> ns <mydomain>.com
it'll return all four name servers for my domain, but only the glue records of the name servers in the same TLD (supplied as ADDITIONALs), which is what you're describing.
If I run dig @<co.uk server> <myotherdomain>.co.uk
, I'll again get all four name servers, but this time accompanied by the glue records for the 3 of them in the .co.uk
TLD.
This is all as it should be. If all of your name servers are in the .us
TLD, then clients looking for your .com
domains will be told the domain names of your name servers by the .com
servers; then the clients will perform another query on the .us
servers to find their IPs. That extra round trip might sound inefficient, but it only has to happen once per TTL period per client. (typically 48 hours for TLD records.)
(Apologies if you already know all of the above). To answer the original question. Glue records are not intended to save DNS lookups. They're necessary to prevent infinite loops.
Edit 2
Sorry for waffling around the issue. I see what you mean, now (Good diagrams, by the way).
My understanding of how clients should behave is that if one has the opportunity to get authoritative RRs, then it should; but in this case, the client is asking the name server for its own A records, which is pointless, since the Glue is those A records.
I'm reaching the limits of my knowledge here, but I can't think of any situation why a client would need to do this. I'm guessing here, but perhaps the client implementation needs to check that the server is definitely authoritative for ns_.host.us, even when that means what looks like a pointless, extra round-trip.
Try a dig +trace www.example.com
to see if it does the same thing. I'd be curious to see if it does the same lookup if the original query was for a _.host.us name, too.
Best Answer
I think you are in part confused by the term "glue". There is no "glue" record type in the DNS, that kind of records do not exist. What we do reference there are purely
A
orAAAA
records. They are called "glues" because they exist at the parent side of the DNS delegation, instead of at a child, where expected. They exist only to aid resolution, they are not authoritative. But without them, there would be a chicken and egg problem.Let's go back to basics.
Say you want to have domain
example.com
served by nameserversns1.example.com
andns2.example.com
When you register domain names, through a registrar, you provide various administrative details and for the technical part you provide the domain name obviously and its list of nameservers. The registrar sends all that to the registry, and normally, DNS wise there is only a single thing appearing as consequence: the registry publishes in its authoritative nameservers someNS
records that will tie your domain name to your nameservers by letting any resolver asking that there is a zone cut, that is the registry says, with thoseNS
records: I know nothing more aboutexample.com
because this name is handled by such and such resolvers, hence go query them for additional details.This is all fine, if your
example.com
domain was usingns1.provider.example
andns2.provider.example
nameserver the delegation would work as is, and the resolver would then continue by first trying to find out the IP address for the namens1.provider.example
(or the other one) and then query that nameserver for further information.But let us go back to our example which would mean the registry is publishing this:
which is to say for the registry it will reply: please go ask
ns1.example.com
for more information on domain nameexample.com
, but to do so a resolver will then need to get the IP address ofns1.example.com
and hence it is now in a loop with no exit as it goes back to first point to get information onexample.com
.This is where glue records exist and they break the loop.
Because when you (through your registrar) will create nameserver
ns1.example.com
you will be forced to provide an IP address (one or more, IPv4 or IPv6 of course), and same for other one. Those IP addresses will be published by the registry because they are needed for the resolution to happen. Those records are called glue records, but they are normalA
/AAAA
records just sitting on registry authoritative nameservers.Those records also need to exist on your nameservers (that is if you query directly
ns1.example.com
andns2.example.com
) so the same exact records (of course the IP addresses must match on both sides otherwise you create havoc, and it is a known and frequent source of problems) in fact exist on both side of the delegation cuts. They would normally exist only on the child (delegate) side, but they are needed on the parent for the resolution to work, and to discriminate, on the parent side they are called "glues".Your registrar (not registry, you never interact directly with registries, registries customers are registrars not end clients, with some exceptions for some TLDs like
.de
) should be able to explain all of this to you. Its interface or API should be able to let you create nameservers with IP addresses when needed (the above is a summary there are various other edge cases, like when you change the name of a nameservers, which is allowed normally, or when you associate/dissociate those nameservers with existing domains), so that the registrar sends the appropriate content to the registry.