Exploring DNS - Part 1: The Basics

dig is a utility commonly found on Linux and OS X platforms and is part of the BIND software suite. You'll have to download it separately if you're using Windows. It has since become a staple Domain Name System (DNS) client utility since its introduction. This will be a three part (at minimum) series exploring the DNS infrastructure that is crucial to the functioning of nearly every Internet service available while learning the capabilities of dig at the same time. DNS' criticality is obvious when the root cause of someone's Internet not working is that some node that handles DNS transactions is not responsive or misconfigured, emulating the behavior of having not having accessible Internet.

For many that are familiar with DNS, most know of its functionality to find the IP address of a specific domain, except there's much more than that. This will allow the computer you're using and network it's on to find and talk to the resource. These transactions happen automatically, and there's rarely a need to do a manual query, except when things do not work the way you want. This article discusses the variety of things that can be discovered about a network through DNS queries.

The article attempts to tailor to both a non-technical and technical crowd, hopefully allowing those unfamiliar with certain terminology to gloss over them and still understand the message of a particular section.

A and PTR Records

A domain can often be thought of for many users as simply a friendly name for an IP address. If you wanted to browse to "www.google.com", it'd be a lot easier typing that than memorizing and typing "74.125.226.208" into your browser each time. Administrators define what these friendly names translate to as "A" records in their domain's zone configuration on the authoritative nameservers for that domain (we'll talk more about those later).

To perform a simple query for a domain's IP address (also known as an A record lookup), you simply specify the domain and type as follows:

 dig example.com A

Executing this command will cause your computer to ask the configured DNS server on your local system to find what the A record is for the domain "example.com". Depending on your network configuration, this is something that's statically configured by you, an Administrator, or through an automated deployment process. Otherwise, it's often provided automatically as part of DHCP via a configuration option. Most often your local DNS server will not have the record you're looking for cached in its system, so it will have to go through a series of steps querying authoritative nameservers on your behalf to ultimately find the answer to your initial query.

In our example, let's pretend "example.com" resolves to "93.184.216.119". You'll receive this answer with what appears to be a lot of other useless information, but is a parsed representation of the received answer:

 ; <<>> DiG 9.8.3-P1 <<>> example.com A
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26804
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

 ;; QUESTION SECTION:
 ;example.com.                   IN      A

 ;; ANSWER SECTION:
 example.com.            1734    IN      A       93.184.216.119

 ;; Query time: 18 msec
 ;; SERVER: 75.75.75.75#53(75.75.75.75)
 ;; WHEN: Tue Jan  7 23:16:14 2014
 ;; MSG SIZE  rcvd: 45

If you only wanted the answer to the query (the IP address), and could not care about the rest of it, you can use some of dig's filtering options to get the exact information you want.

 dig example.com A +short

In this case, you'll simply get the list of IPs (or IP) back, each on its own line.

What if you had the IP address but wanted to know what the IP address resolves to, or what's commonly known as a reverse lookup? This information is defined as a different record type, or query type. Instead of querying for the "A" record of that domain, we will be querying for the "PTR" recordof the IP address. There are two ways you can do this, either through a shortcut or a verbose query mimicking how it actually is sent out on the wire.

 dig -x 93.184.216.119

The '-x' is a shortcut to do a reverse lookup. To do this explicitly:

 dig 119.216.184.93.in-addr.arpa PTR

You might've noticed that what we queried for does not look like an IP address, and in fact it's also reversed. The way nameservers discover who is responsible, or authoritative, for a particular domain is a fundamental part that makes DNS work. For a standard domain lookup, your caching nameserver will take the domain, "example.com.", and find out who is authoritative for each successive word from the right to left delimited by the 'dot'. In this case, it'll ask the DNS root-servers who is authoritative for the "com" (top-level) domain. Once it knows who is (and also caches that answer as defined by the TTL so it does not have to query the root-servers again), it sends a request to those servers asking who is authoritative for the "example" domain. Once it finds out those nameservers, it'll direct its specific request, the original query, to that authoritative nameserver ultimately responding with our desired answer. PTR record lookups work the same way for the same reason.

As certain individuals or organizations are responsible or authoritative for domains, they can also be authoritative for IP addresses, and there must be a way to represent that. One organization is responsible for "google.com" and another for "apple.com", and the same can be said about the 4.0.0.0/8 IP CIDR and 24.86.1.0/24 CIDR. Thus, the reversing of the IP address and suffixing it with a special top-level domain (.in-addr.arpa for IPv4 space) causes the IP address to be looked up in the same way as a domain allowing proper delegation to lower level organizations. For example, Verizon might be the owner for 24.97.0.0/16, but Verizon might route and give authority for 24.97.2.0/24 to one of their business customers, and thus allow that customer to define how that IP space resolves. There are certain services that require a circular records to be in place for a set of domains and IP addresses, meaning a domain that resolves to an IP address as defined by its "A" record, must have a "PTR" record on that IP address pointing back to the domain.

CNAME

Not all domains have to resolve directly to IP addresses. If I hosted a webserver which contained many different websites on many different domains at a specific IP address, it would be an unmanageable process for me (or the people who own domains but choose to host their site on my server) to update their A records if the IP address of my server ever changed, or if I wanted to introduce DNS-based load-balancing. To ease this process, authoritative nameservers can point the requesting client to another domain as an answer to its query. To show a specific example, let's show the answer of querying for www.apple.com's A record,

 dig www.apple.com A +noall +answer

Leads us to the following chain of answers:

 www.apple.com.          1306    IN      CNAME   www.isg-apple.com.akadns.net.
 www.isg-apple.com.akadns.net. 39 IN     CNAME   www.apple.com.edgekey.net.
 www.apple.com.edgekey.net. 550  IN      CNAME   e3191.dscc.akamaiedge.net.
 e3191.dscc.akamaiedge.net. 19   IN      A       23.48.61.15

Apple's authoritative nameserver redirected the client via a CNAME answer to an Apple-specific subdomain on 'akadns.net' (Akamai), which is a third-party content delivery organization. Akamai's authoritative nameserver then leads through two more CNAME records before ultimately resolving to an IP address that the client can request the web page from. You'll notice a number after each of the domains. This is called the TTL value, or Time To Live, and specifies how long other nameservers and your client should cache that record since the authoriatitive nameserver does not believe it will change during that period, and if it does, the TTL is an acceptable enough period that your computer will ultimately find the right answer after a reasonable amount of time. This is a value configured and chosen by Administrators.

DNS is not limited to simply resolving domains to IP address or vice versa, although clearly that's its predominant use for end-users. There have been many other uses for DNS implemented since its inception, and that's what we'll start taking a look at now.

MX Records

At this point, every one using the Internet has likely sent an e-mail. Each e-mail is suffixed with the domain of the hosting company or organization that represents the "destination" the mail should be delivered to. If Alice sends an e-mail to Bob, once Alice writes an e-mail addressed bob@gmail.com and hits the send button, the e-mail is handed off to Alice's e-mail server. The e-mail server doesn't know what IP address to send the e-mail address at this point. Through our previous example, we demonstrated we could find the IP address that resolves from the domain by using an "A" record query, but it may not necessarily be the resource also handling receiving mail for that domain. Thus, a special query type was specified to find the "Mail Exchange" servers for a particular domain, the MXrecord.

It ultimately looks very much like a CNAME answer in that its response contains other domains, with the exception that multiple answers are to be expected and the priority of the mail servers used are specified.

If we wanted to figure out gmail.com's receiving mail servers that Alice's e-mail server should be sending the mail to, we can issue the following command:

 dig gmail.com MX +short

That responds with:

 30 alt3.gmail-smtp-in.l.google.com.
 20 alt2.gmail-smtp-in.l.google.com.
 40 alt4.gmail-smtp-in.l.google.com.
 10 alt1.gmail-smtp-in.l.google.com.
 5 gmail-smtp-in.l.google.com.

Since highest priority is specified by lowest number, Alice's mail server would issue another DNS request to find the IP address ofgmail-smtp-in.l.google.com via an "A" record lookup so it can initiate the SMTP connection and send the mail on its way.

These four record types, A, PTR, CNAME, and MX are the most common record types, and perhaps the most frequently queried. However, there are other records that play a prominent role in many services, for example TXT records and their common use for SPF and DKIM. In the next part, we'll dive into TXT records and its common uses. Subsequent posts will take a look into the SOA record and what it can reveal, response codes, proper and improper DNSSEC configuration, AXFR and IXFRs, and some of the more extravagant record types.