DNS by design does not enable having an authoritative copy of all zones, as it utilizes a hierarchical naming system.
The root servers are authoritative for identifying the server responsible for the Top Level Domain (TLD) in question. For example, resolving www.example.net
will first query a root server to identify the authoritative nameserver for .net
. The .net
nameserver will identify the authoritative nameserver for example.net
, which will then return the record for www.example.net
.
You cannot download a copy of all zones. However, you can run a local caching nameserver. The caching nameserver will provide a local copy of all records resolved, which expire using the Time To Live (TTL) specified for the record. Please keep in mind that my explanation is a simplistic description of the DNS protocol, which can be explored in detail by reading definitions in the Request For Comments.
While NXDOMAIN hijacking can be avoided by running a local cache, keep in mind that all DNS resolution traffic will still be transmitted via your Internet connection unencrypted. Your ISP could potentially monitor that traffic and still see the communication. The contracts you have with your ISP as well as your local laws are going to be your definitive means for establishing how your communications are treated. Your ISP's contracts will include the Terms of Service, Privacy Policies and any additional contracts that you may have with your ISP.
Using encrypted protocols is one of the best methods for insuring your data against eavesdropping during transit. However, even that has no guarantee of anonymity. There are additional protocols out there such as Tor and Freenet, which attempt to introduce anonymity to the Internet, as it was never designed to be truly anonymous.
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
Actually, it's more complicated than that - rather than one "central registry (that) holds a table that maps domains (www.mysite.com) to DNS servers", there are several layers of hierarchy
There's a central registry (the Root Servers) which contain only a small set of entries: the NS (nameserver) records for all the top-level domains -
.com
,.net
,.org
,.uk
,.us
,.au
, and so on.Those servers just contain NS records for the next level down. To pick one example, the nameservers for the
.uk
domain just has entries for.co.uk
,.ac.uk
, and the other second-level zones in use in the UK.Those servers just contain NS records for the next level down - to continue the example, they tell you where to find the NS records for
google.co.uk
. It's on those servers that you'll finally find a mapping between a hostname likewww.google.co.uk
and an IP address.As an extra wrinkle, each layer will also serve up 'glue' records. Each NS record maps a domain to a hostname - for instance, the NS records for
.uk
listnsa.nic.uk
as one of the servers. To get to the next level, we need to find out the NS records fornic.uk
are, and they turn out to includensa.nic.uk
as well. So now we need to know the IP ofnsa.nic.uk
, but to find that out we need to make a query tonsa.nic.uk
, but we can't make that query until we know the IP fornsa.nic.uk
...To resolve this quandary, the servers for
.uk
add the A record fornsa.nic.uk
into theADDITIONAL SECTION
of the response (response below trimmed for brevity):Without these extra glue records, we'd never be able to find the nameservers for
nic.uk.
and so we'd never be able to look up any domains hosted there.To get back to your questions...
For one thing, it allows edits to each individual zone to be distributed. If you want to update the entry for
www.mydomain.co.uk
, you just need to edit the information on yourmydomain.co.uk
's nameserver. There's no need to notify the central.co.uk
servers, or the.uk
servers, or the root nameservers. If there was only a single central registry that mapped all the levels all the way down the hierarchy that had to be notified about every single change of a DNS entry all the way down the chain, it would be absolutely swamped with traffic.Before 1982, this was actually how name resolution happened. One central registry was notified about all updates, and they distributed a file called
hosts.txt
which contained the hostname and IP address of every machine on the internet. A new version of this file was published every few weeks, and every machine on the internet would have to download a new copy. Well before 1982, this was starting to become problematic, and so DNS was invented to provide a more distributed system.For another thing, this would be a Single Point of Failure - if the single central registry went down, the entire internet would be offline. Having a distributed system means that failures only affect small sections of the internet, not the whole thing.
(To provide extra redundancy, there are actually 13 separate clusters of servers that serve the root zone. Any changes to the top-level domain records have to be pushed to all 13; imagine having to coordinate updating all 13 of them for every single change to any hostname anywhere in the world...)
Because DNS utilises a lot of caching to both speed things up and decrease the load on the NSes. Without caching, every single time you visited
google.co.uk
your computer would have to go out to the network to look up the servers for.uk
, then.co.uk
, then.google.co.uk
, thenwww.google.co.uk
. Those answers don't actually change much, so looking them up every time is a waste of time and network traffic. Instead, when the NS returns records to your computer, it will include a TTL value, that tells your computer to cache the results for a number of seconds.For example, the NS records for
.uk
have a TTL of 172800 seconds - 2 days. Google are even more conservative - the NS records forgoogle.co.uk
have a TTL of 4 days. Services which rely on being able to update quickly can choose a much lower TTL - for instance,telegraph.co.uk
has a TTL of just 600 seconds on their NS records.If you want updates to your zone to be near-instant, you can choose to lower your TTL as far down as you like. The lower your set it, the more traffic your servers will see, as clients refresh their records more often. Every time a client has to contact your servers to do a query, this will cause some lag as it's slower than looking up the answer on their local cache, so you'll also want to consider the tradeoff between fast updates and a fast service.
Yes, this is easy if you're testing manually with
dig
or similar tools - just tell it which server to contact.Here's an example of a cached response:
The flags section here doesn't contain the
aa
flag, so we can see that this result came from a cache rather than directly from an authoritative source. In fact, we can see that it came from97.107.133.4
, which happens to be one of Linode's local DNS resolvers. The fact that the answer was served out of a cache very close to me means that it took 0msec for me to get an answer; but as we'll see in a moment, the price I pay for that speed is that the answer is almost 5 minutes out of date.To bypass Linode's resolver and go straight to the source, just pick one of those NSes and tell dig to contact it directly:
You can see that this time, the results were served directly from the source - note the
aa
flag, which indicates that the results came from an authoritative source. In my earlier example, the results came from my local cache, so they lack theaa
flag. I can see that the authoritative source for this domain sets a TTL of 600 seconds. The results I got earlier from a local cache had a TTL of just 319 seconds, which tells me that they'd been sitting in the cache for (600-319) seconds - almost 5 minutes - before I saw them.Although the TTL here is only 600 seconds, some ISPs will attempt to reduce their traffic even further by forcing their DNS resolvers to cache the results for longer - in some cases, for 24 hours or more. It's traditional (in a we-don't-know-if-this-is-really-neccessary-but-let's-be-safe kind of way) to assume that any DNS change you make won't be visible everywhere on the internet for 24-48 hours.