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.
Both approaches are valid, do know that this record will not show as the originating address. When you send an email to one of your configured addresses, the sending MTA will look up the MX record configured for your domain. It will get the IP from that domain and it will open an SMTP session with your SMTP server (or one of your SMTP servers if you have configured more than one).
Even without an MX record it will work, because then the MTA just looks up the A record for your domain. (providing your A record points to your SMTP server of course)
Best Answer
You need to configure the reverse DNS (PTR) records for your elastic IPs by filling out this form. Make sure your A records are correct or they will not create the PTR record.