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.
Glue should only exist when the name servers for your domain are within the same domain name.
Technically this is not a circularity problem - those occur when two domains have NS records that mutually point into the other domain name. These are now considered to be a configuration error.
Any A record included along with the NS records should be ignored unless it meets the same domain criteria above, since remembering "out of bailiwick glue" can lead to security issues such as the Kaminsky attack.
See also s5.4.1 of RFC 2181
[in other words - your ISP is essentially correct here, and the intodns.com advice is incorrect].
Best Answer
The parent zone is not obligated to provide glue records for a delegation if the delegated-to host names is not under the delegated name. Glue records are only needed if a delegation points to something that the delegation would need to be followed for to be useful.
Since you are delegating
gignouser.comto name servers undereu.clouds.host, that is not the case and glue records are thus not required to be returned by the name servers hosting the delegation togignouser.com-- meaning thecomTLD DNS servers.If you look at the delegation of
clouds.hostyou will see that the delegation from thenic.hostDNS servers does include glue records.I do however notice something that may contribute to problems:
You are serving NS RRs with a 0 TTL, for both domains. This can be problematic. If you want to minimize the time that DNS servers cache the delegation data (why you'd want to do that to such an extent I don't know), then serve it with some small but non-zero TTL. I suggest using a minimum of 10 seconds TTL to give resolvers and proxies a chance to do their thing even if they abide by TTLs internally during the recursive resolution process.
I would fix the TTLs first, and see if the problem goes away. It's certainly possible that the report tool you are using is being confused by the zero TTLs.
I also notice that it appears that you are running both name servers on the same subnet -- specifically, on adjacent IP addresses -- which presents a massive single point of failure. If that is the case, strongly consider getting an off-site slave DNS server, especially if you want to serve zone authority data with very short TTLs. While "everything else will be down anyway" is a valid point on the face of it, which error would you rather the users get if your servers are unavailable; "the host name www.gignouser.com was not found" or "the server did not respond"? I would absolutely prefer the latter, even if the end result at that moment is the same in that your web site is unavailable.