Second in a series. View the first post here.
In the last post introducing the dig(1) command, you’ll recall seeing an entry like this:
$ dig +noall +answer google.com
google.com. 300 IN A 216.58.216.238Every DNS record has a similar format to this, and the fields are:
| Name | The domain name. |
|---|---|
| TTL | Time To Live, the number of seconds for which this entry should be cached. |
| Class | A code describing what kind of network the record is for, in practice always `IN` (for “Internet”). |
| Type | The kind of record: `A` for IPv4 address, `CNAME` for an alias to another name, `MX` for the domain’s mail server, etc. |
| RData | The thing that this record points to. Depending on the Type field, this can be an IP address, another domain name, or other kinds of entries. |
In this case, the answer says “The IPv4 address (A) of the domain name google.com. is 216.58.216.238, and you can cache that fact for the next five minutes.”
You can request other kinds of records with the -t option. For example, if you want to know, “What host do I connect to to send mail to someone with a gmail.com address?” you want the MX record(s):
$ dig -t mx +noall +answer gmail.com
gmail.com. 3599 IN MX 5 gmail-smtp-in.l.google.com.
gmail.com. 3599 IN MX 20 alt2.gmail-smtp-in.l.google.com.
gmail.com. 3599 IN MX 30 alt3.gmail-smtp-in.l.google.com.
gmail.com. 3599 IN MX 40 alt4.gmail-smtp-in.l.google.com.
gmail.com. 3599 IN MX 10 alt1.gmail-smtp-in.l.google.com.
This says “Try gmail-smtp-in.l.google.com first (priority 5); if that doesn’t work, try these others in increasing priority order.” Or if you need to know what the authoritative nameservers (type NS) are for google.com.:
$ dig -t ns +noall +answer google.com
google.com. 21599 IN NS ns3.google.com.
google.com. 21599 IN NS ns2.google.com.
google.com. 21599 IN NS ns4.google.com.
google.com. 21599 IN NS ns1.google.com.
Authoritative who-what? This, combined with the TTL field, is where the “distributed database” part comes in: every domain has one authoritative nameserver (or at most a handful), which is the canonical data source for information about that domain. This is true not just of domain names that you or I would buy, but the so-called top-level domains (TLDs) as well. Ever wonder what the canonical nameserver for the .com. space is?
$ dig -t ns +noall +answer com
com. 13307 IN NS d.gtld-servers.net.
com. 13307 IN NS h.gtld-servers.net.
com. 13307 IN NS m.gtld-servers.net.
com. 13307 IN NS g.gtld-servers.net.
com. 13307 IN NS i.gtld-servers.net.
com. 13307 IN NS l.gtld-servers.net.
com. 13307 IN NS j.gtld-servers.net.
com. 13307 IN NS e.gtld-servers.net.
com. 13307 IN NS c.gtld-servers.net.
com. 13307 IN NS a.gtld-servers.net.
com. 13307 IN NS k.gtld-servers.net.
com. 13307 IN NS b.gtld-servers.net.
com. 13307 IN NS f.gtld-servers.net.
Those top-level name servers, operated by ICANN, don’t contain all the DNS records for every .com domain; rather, they delegate to the authoritative nameserver for a given domain.
But when you type google.com into your browser’s address bar, it doesn’t go to the authoritative nameserver every time. Your computer is configured to talk to a recursive resolver, which accepts DNS queries just like an authoritative nameserver but will follow the chain of lookups to find what the authoritative response is. It will then cache the result records according to their TTL, and the next time you look up the same address, it’ll just return it from its cache.
Try looking up google.com. again, and you’ll see the TTL decrease:
$ dig +noall +answer google.com
google.com. 232 IN A 216.58.216.206
That’s your internet provider’s recursive resolver telling you, “Hey, I know this one (at least for the next four minutes). It’s 216.58.216.206.”
That’s how DNS works as a global distributed database: anyone can query it, there’s always one canonical source of a given record, and the results are cached by the server your users are querying. By now it should also be obvious that this is why DNS changes take time to propagate: the higher the TTL (a common value is 86400 seconds, or 1 day), the longer it will take for all of your site’s users to see the same records.
Up next: how I used this to debug a problem with AWS.