How do I fix “no GLUE” problem with DNS lookups?

Question

When I look up my domain at http://www.intodns.com, here's a problem I get:

GLUE was not sent when I asked your nameservers for your NS records. This is ok but you should know that in this case an extra A record lookup is required in order to get the IPs of your NS records. You can fix this for example by adding A records to your nameservers for the zones listed above.

But I do have A entries for all my nameservers in each zone entry:

ns1.example.com. IN A <IP>
ns2.example.com. IN A <IP>

How do I fix this GLUE problem?

Answer 1

Glue records are special A records which are needed when the name server for a DNS domain is itself in the same domain.

For example, if your domain is example.com and your name server is ns.example.com, you need to create a "glue" A record for ns.example.com in the next-highest DNS zone, in this case in the "com" zone. This should be done via your registrar.

This is required because DNS requests for name servers (NS records) are always answered with a name, not an IP.

Without a glue record, if a request were made for the A records www.example.com, a name server serving "com" would return the NS record for example.com as ns.example.com (not an IP), and the original request would have no way of being resolved, because any further attempt to resolve ns.example.com would merely refer back to ns.example.com.

Answer 2

The issue with GLUE from the root DNS servers is that when you have the following situation:

example.com has DNS records ns1.example.net and ns2.example.net as its NS servers. The .com authority which is where the DNS resolver is going to look for the domain name is UNABLE to provide the IP addresses for ns1.example.net and ns2.example.net because they are not in its authority.

The way to fix this is for a .com domain to use .com originated NS servers. So example.com would use ns1.example-2.com and ns2.example-2.com and everything will be fine since the .com authority is able to provide the IP address for the name server. This saves multiple round trips to the root DNS servers, since in your case to get example.com it now also needs to ask .net about example.net.

In my case, all of my domains have their own NS entries, so for example.com I have a.ns.example.com and b.ns.example.com and for my example.net domain I have a.ns.example.net and b.ns.example.net.

It does require more setup, and not all hosts might be willing to allow you to do so. You may be stuck with what you currently have!

Answer 3

Trying the tool myself, and seeing what it reports with some domains I'm familiar with, I'd say that it could be a number of things that lead to that informational message (note that it's an 'i' for information, not an '!')

For instance, one of my zones has nameservers outside the zone, and of the authoritative nameservers for the zone they don't all have A records within their authoritative data to be returned in a response.

But that's ok - any querying nameserver shouldn't trust such data anyway. Long ago, you'd have gotten away with it, but these days every nameserver could be trying to lie and sneak out of zone data into your cache.

So don't worry about it. By the time the query reaches your nameserver, it's already found at least some of your nameservers' IP addresses. Be more concerned with the delegations being the same as your own zone data (the next entry, "Mismatched NS records") and that none are 'lame' ("Nameservers are lame: All the nameservers listed at the parent servers answer authoritatively for your domain" -- worded badly, but you want to ensure that there's a tick there.)