DNS Primer

Introduction

The DNS can be considered the phonebook of the Internet. DNS is used to look up different bits of information about domain names. For instance, your Web browser needs to know which IP address to connect to in order to request a Web site from a Web server. Similarly, when you send an email to someone, your email server needs to know both the domain name and the IP address of the mail server responsible for delivering the message to its recipient. DNS provides the means with which to find this information.

The Layout of DNS

The layout of DNS resembles a top down tree structure. The root of the structure consists of a group of Root Name Servers. Below the root are the Top Level Domain Servers. The names "com" (as in "www.example.com") and "net" are both examples of top level domains. Below the top level, DNS provides no specific classification beyond the term "Name Server".

Delegation of Authority

"Authority" in the context of DNS refers to the responsibility of a name server to handle requests for a given domain. If a name server is Authoritative for servicing DNS requests for anything under example.com, it has been delegated the authority to do so by the higher-level domain server(s). The Virtual Traffic Manager's built-in DNS capability is an example of an authoritative DNS server.

Name Resolution

The process of "looking up a piece of information" using DNS is called "resolution". For example, when your Web browser needs to find an IP address for a Web site, it attempts to resolve the domain name to get an IP address. When your email server needs to know which mail server is responsible for delivering a message to a particular domain, it attempts to resolve the "Mail Exchange (MX)" name and its IP address.

As part of its network configuration settings, a computer typically knows of at least one "Name Server". That Name Server in turn provides the computer with responses to DNS requests. Only under special circumstances1 does a computer send DNS requests to a different Name Server.

Resource Records

Each piece of information for a domain name is held in what is called a Resource Record. Typically, Resource Records are distinguished by type. For instance, when your Web browser wants to know the IP address for www.example.com, it sends a query for an "A record" that matches www.example.com. If your email server needs to know where it should send a message addressed to [email protected], it sends a query for an "MX record" that matches example.com. Some commonly used and supported resource record types are:

SOA (Start of Authority): Provides a few pieces of useful information about a given domain.

NS (Name Server): Indicates the domain name of a name server that is authoritative for a given domain. This resource determines how authority is delegated from a higher-level domain to a lower-level domain.

MX (Mail eXchange): Indicates the domain name of a mail server that should accept mail for a particular domain.

A (Address): Contains an IPv4 address of a domain name.

AAAA (Address): Contains an IPv6 address of a domain name.

CNAME (Canonical Name): Contains an alias for a domain name.

PTR (Domain Pointer): Used for reverse lookups, from IP back to DNS name.

SRV (Service Record): Defines the hostname and port number of servers used for specified services.

TXT (Text Message): Contains an arbitrary human readable text message, used for many purposes.

Zone Files

Resource Records are typically stored in text files on authoritative DNS servers. A zone file contains a set of records that are specific to a domain. Each zone file must contain at least an SOA record and an NS record.

The Virtual Traffic Manager supports zone files with the following example format:

$TTL 604800 ; This TTL declaration applies to all
; records defined below that do not define
; their own TTL

; In this file, @ means the "current origin domain"

@ IN SOA ns.example.com. root.example.com. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ; Negative Cache TTL
)

@ NS ns
ns A 192.168.0.1
@ NS ns.example.com.
ns A 192.168.0.254

@ IN MX 1 host
@ IN MX 2 mail2.example.net. ; note this is
; in another
; zone/domain

host IN A 192.168.0.2
AAAA 2001:db8:85a3:0:0:8a2e:370:7334

$TTL 1w2d3h4m5s ; The TTL defined here overwrites the
; setting above and applies to all the
; records below it that do not define their
; own TTLs.

foo.bar A 192.168.0.3 ; An example of a
; relative address:
; foo.bar.example.com.
foo.bar.example.com. A 192.168.0.4 ; An example of an
; absolute address

alias CNAME host

_sip._udp SRV 0 5 5060 sipserver
sipserver 3600 A 192.168.0.5 ; This record has
; its own TTL (3600)

text1 TXT "This is a TXT record"
*.wildcards TXT "This is a wildcard TXT record"

The Virtual Traffic Manager parses zone files using a top-down approach, and it assumes inheritance from the preceding line where indentation occurs.

If you modify or update your zone file after the initial deployment, you must increment the "serial" counter to ensure the DNS service is made aware of the change.

A zone file typically contains at least one TTL (Time To Live) definition, in particular at the top of the file. The Virtual Traffic Manager uses this value to determine how long clients should wait before refreshing DNS-related information. The following rules and observations apply to TTL values in zone files:

If you do not define a TTL value in your zone file, the Virtual Traffic Manager uses instead the Negative Cache TTL value from the SOA definition. The Negative Cache TTL is normally used as a TTL in "negative responses". That is, NXDOMAIN (domain name not found) and NODATA (domain name found, but no records of given type).

All records with the same domain name should have the same TTL value.

A TTL can be specified as a single number of seconds or the alternative format of 1w2d3h4m5s to mean 1 week, 2 days, 3 hours, 4 minutes, and 5 seconds. The alpha components of this format are case insensitive, and they can be specified as uppercase, lowercase, or mixed (for example, 3W1h5M4s).

The Resolution Process

The following steps detail how a user's client workstation resolves a Web site's URL to a correct IP address:

If you are using the Virtual Traffic Manager's built-in DNS server capability, "dns.example.com" in this scenario might correspond to the Virtual Traffic Manager as the authoritative DNS server.

When a user opens a Web browser and types www.example.com into the address bar, their workstation needs to send an HTTP request to a Web Server. Before it does so, it must resolve the domain name of the Web server. Their workstation sends a DNS request to the Local Name Server in order to determine the IP address.

The Local Name Server then refers to its Root Hints zone file. The Root Hints zone file contains a list of domain names and IP addresses for the Root Name Servers. The Local Name Server then sends a DNS request for www.example.com to one of the Root Name Servers listed in its Root Hints zone file. "f.root-servers.net." compares the DNS request to the list of zones for which it is authoritative. In this case, it is authoritative for the "." domain. Within the zone file for ".", there are delegation records for all Top Level Domains. The Top Level Domain for www.example.com is ".com.", so "f.root-servers.net." sends a DNS response back to the Local Name Server containing the domain names and IP addresses for the Name Servers that are authoritative for ".com."

A.GTLD-SERVERS.NET2 is listed (among others) as authoritative for the ".com." domain, so the Local Name Server then sends the same request to it. A.GTLD-SERVERS.NET then responds with a list of name servers authoritative for "example.com.".

Since "dns.example.com." is an Authoritative Name Server for the "example.com." domain, the local name server then sends it the request. Because "dns.example.com" contains all of the Resource Records for "example.com." in its Zone Files, it provides the IP addresses (in the form of one or more "A" records).

Now that the Local Name Server has the IP address, or IP addresses, for www.example.com, it passes on the information to the workstation that made the initial DNS request. The machine that performed the recursive lookup is the Local Name Server.

The type of query the client made is known as "recursive" due to the fact that the local name server searches the DNS tree from top to bottom. A "non recursive" query might also be sent. This means that only a name server authoritative for the domain name being asked about should provide the answer; otherwise, the name server receiving the query should refuse to respond to the query.

In addition to returning the final DNS result to the end user, the Local Name Server usually caches the results of the intermediate lookups. Consequently, not every request requires the full set of DNS requests illustrated above. For this reason, the Local Name Server can be referred to as either a "Recursive Name Server" or a "Caching Name Server".