DNS Tutorial part 1 - DNS basics

In the beginning
The Internet domain name space
Domains and zones
DNS building blocks
Authoritative DNS
DNS resolver and the iteration process
Cache
DNS resource records
Common resource record types
Resource record sets
Authoritative DNS Master & Slave

To build the Internet was quite an achievement by many smart people! There are a lot of intriguing and interesting stories about how the Internet was developed and how the process of the Domain name system came to be. The history spans over decades before the first functional DNS system saw the light of day at UC Berkeley back in 1984. See the historic link on the links page for further and more in-depth reading.

In short, the DNS and the domain name system were developed to come to terms with existing and developing problems that might have slowed or halted the development and growth of the Internet. The Domain name system is a set of rules of how the Internet names are hierarchically organised and how they work and interact.
The DNS is designed with the domain name system in mind. Form the start, the DNS were developed to be both fast and resilient. The architects succeeded with their intentions!

The domain name is an identification string that defines a realm of administrative autonomy, authority or control within the Internet. A tiny part of the domain name space is illustrated in this picture and has the shape of an upside down tree with the root domain on top. A domain name consist of one or more parts, called labels, delimited by dots, such as example.com. The hierarchy of domains descends from the right to the left label in the name, each label to the left specifies a subdomain to the domain to the right. The full domain name may not exceed 253 characters in length.

Below the root domain are the Top level domains. They are distinguished into the following six groups:

• Infrastructure top level domains (ARPA)
• Generic top level domains (gTLD)
• Restricted generic top level domains (grTLD)
• Sponsored top level domains (sTLD)
• Country code top level domains (ccTLD)
• Test top level domains (tTLD)

Below the Top level domains are the 2nd level domains. This is where most domain names are registered.
Today, ICANN, the Internet Corporation for Assigned Names and Numbers, manages the top-level development and architecture of the Internet domain name space. It authorises domain name registrars, through which domain names may be registered and reassigned.

Working with DNS, you will come across the notions of domains and zones. It might be a bit confusing, since to the naked eye, they appear to be the same. But there are differences:

• A domain defines the whole namespace from a certain point of origin (picture 1 and 2)
• In essence, a zone is a technical and administrative boundary within a domain for which individual DNS servers are responsible (picture 3)
• If there are no subdomains delegated from a zone, the zone and the domain is virtually the same (picture 4)
• A zone contains exactly one SOA record describing the general properties of the zone and any number of other DNS records. We will talk more about DNS records later on.

The DNS infrastructure is made up of two distinctive entities; authoritative name servers and iterative resolvers.

An authoritative name servers hold the data for its assigned domains as well as information about delegated domains or subdomains. The delegation information held by the name servers are imperative for the domain name system to work. An authoritative name server will only respond to queries about its authoritative data.

Iterative resolvers are entities that has no data on its own but are designed to look up the data they're  queried for. The iterative resolvers have only information about where to start its iteration. As a resolver processes queries by iteration it "learns" information to be able to cut corners to speed up the iteration process, this is known as caching.

An authoritative DNS contain zone files for the domains and zones it is responsible for and replies to queries about those domains.

In order to make the DNS and domain hierarchy work, authoritative DNS servers serving the different domain levels need to have an intimate relationship. This relationship is called parent and child, where the parent are the DNS servers delegating the subdomain and the DNS servers receiving the delegation are the children. The DNS records that make this possible are called delegation records or NS records.

Take note that the NS records in the example above are identical in both parent and child. This is important to assure that the name servers will be reached when resolvers perform their iteration and to avoid unnecessary name lookups. A subdomain should never be delegated to less than two DNS servers to maintain a decent amount of resiliency for the delegated domain.

The domain example.com is served by two name servers. These are the only two name servers that hold the authoritative data for that domain. Should both of them fail, no data for the example.com domain would be available including any delegated subdomains.

The counterpart to the authoritative DNS is the iterative resolver. The iterative resolver performs name lookups on requests from its clients using an iteration process which queries the different authoritative name servers.

In order for an iterative resolver to work it needs information about where to start its iteration process. That information is found at the IANA website and is called Root Hints and contains names and IP addresses to all authoritative root name servers.

The iteration for all queries start at the domain root, which is the common denominator of all domain names and DNS records. In the pictures below we have illustrated how a name iteration is performed and how the end result is returned to the client.

In the picture above we introduce something called a stub resolver. The stub resolver is nothing more than a resolver that lacks the iterative capabilities and can only be configured to know where to direct its queries to. A stub resolver can be found in virtually all Internet aware hosts.

1. The stub resolver queries its configured iterative resolver to find out the IPv4 address to the host www.example.com.
2. The iterative resolver don't know the answer so it begins an iteration process to find the answer to the query. The iterative resolver query one of the root name servers for the IPv4 address to www.example.com.
3. The root name server doesn't know the correct answer to this query since it only servers the root zone. What it does is to give a little help on the way. It does know which name servers that are authoritative for the .com domain. The query reply contains referral records to the authoritative name servers for the .com domain. This is called a referral response.
4. The iterative resolver repeats the same query but thanks to the referral response i just received it directs the query to one of the authoritative name servers for the .com domain.
5. The .com name server, like the root name server in the last query, doesn't know the correct answer either. It does know however, which name servers are authoritative for the example.com. domain and encloses that knowledge in a referral reply.
6. Once again, the resolver send the same query to the example.com. name servers.
7. This time around, the example.com. name servers knows the answer to the query and return a reply with the requested information.
8. The iterative resolver have successfully found the requested reply and return the answer to the stub resolver and closes the iteration process.

To increase the speed of the iteration process a resolver will cache each answer and each referral it receives. Instead of repeating the whole process, each resolver will cut corners and use the cached information whenever it gets another query.

In the example illustration above the iterative resolver will cache the referral information as well as the query response. The stub resolver will cache the query response. This caching will result in less DNS queries and improve the overall performance of name lookups. The stub resolver will not ask the iterative resolver again for www.example.com since it already have the answer in its own cache. All other queries will be sent to the iterative resolver.

Since the iterative resolver now knows which name servers are authoritative for the .com domain it can go straight to the .com name servers when receiving a query for another .com domain like acme.com If a query for another host record in the example.com domain would be received it can go straight to the example.com name servers.

The cached information will remain in cache as long as each individual resource record allows it to. Every DNS resource record set contains a TTL, Time To Live, which dictates how long the record is allowed to be cached before it should be discarded.

The terminology used for DNS resource records (RR) is explained below:

owner-name   ttl   class   type   type-specific data
www.example.com.   14400   IN   A    93.184.216.34

owner-name
Also known as label or left-hand name. The owner-name can't contain members outside the zone.

ttl
Time to live in seconds for this individual record. The TTL sets how long this record may be cached by a resolver.

class
Defines protocol family. The default value is IN. The classes HS, Hesiod and CH, Chaos are both historical MIT protocols and are not used today.

type
Determines the value of the type-specific data field.

type-specific data
The data content in this field is determined by the type and class values.

This is an introduction of the most frequently used DNS resource record types you will find in zone files throughout the Internet, including examples of how they look and what they do. If no other RFC is referred to, the resource record types are defined in RFC 1035.

SOA
example.com. 3600 IN SOA sns.dns.icann.org. noc.dns.icann.org. 2018100718 7200 3600 1209600 3600
As described earlier every zone file contains exactly one SOA record. SOA is short for Start Of Authority and contains definitions about the zone file itself.
The type-specific data must have the following fields in this order:

• Master Name (MNAME). A name server name that is referred to as the Master or data point of origin.
• Contact information (RNAME). Defines the email address to the responsible person of the zon. The first "." is replaced by the "@" to complete an email address.
• Serial number. Displays the version of the zone file. Used by slave servers to identify changes in the zone content.
• Refresh. Modern DNS master servers usually send notify messages when the zone content is updated. If a slave server haven't heard from its master they use this value to decide how often to check for updates.
• Retry. If a slave server can't reach its master it will use this value as the interval to try the request again.
• Expire. This timer value is used when a slave server can't reach its master for the duration of the expiry timer. After that the zone content in the slave can no longer count as valid and the slave server will stop responding to queries with its zone data and instead use a SERVFAIL response.
• DNS NCACHE, Negative cache of DNS queries. This is a TTL value that define how long a NXDOMAIN (non-existent domain) answers should be cached by a resolver. In RFC 2308 this field were redefined from its original definition as a TTL for the whole zone.

NS
example.com. 86400 IN NS a.iana-servers.net.
86400 IN NS b.iana-servers.net.
The NS record type defines the authoritative name servers for the domain defined in the owner-name field. There are usually more than one NS record in a zone file. The type-specific data field must contain a host name.

A
www.example.com. 86400 IN A 93.184.216.34
IPv4 address record type. The type-specific field contains the IPv4 address for the host name specified in the owner-name field.

AAAA
www.example.com. 86400 IN AAAA 2606:2800:220:1:248:1893:25c8:1946
IPv6 address record type. The type-specific field contains the IPv6 address for the host name specified in the owner-name field. The AAAA record type were defined in RFC 3596.

CNAME
alias.example.com. 86400 IN CNAME www.example.com.
The CNAME rRR type is used for alias of one name to another. This record type should be used when a host need more than one name instead of adding additional A or AAAA records.

MX
example.com. 86400 IN MX 10 mail.example.com.
86400 IN MX 20 backup-mail.example.com.
The Mail Exchanger record type routes mail to the domain. The type-specific fields are the preference and the mail host for that preference. The lowest preference value will be the primary mail host.

TXT
example.com. 86400 IN TXT "The example domain is used as an example"
example.com. 86400 IN TXT "v=spf1 -all"
The TXT record type was originally intended for human readable text. Since the early 1990's, this record is mostly used by machine-readable data like the Sender Policy Framework and other arbitrary string attributes described in RFC 1464.

SPF
example.com. 86400 IN SPF "v=spf1 -all"
example.com. 86400 IN TXT "v=spf1 -all"
The SPF record type defines the servers which are authorized to send mail for the domain. Take note of the identical TXT record type! Not all MTA's (Mail Transfer Agents or mail servers) have implemented the SPF record type. The SPF record type were defined in RFC 4408.

SRV
_sip._tcp.example.com. 86400 IN SRV 10 60 5060 bigbox.example.com.
86400 IN SRV 10 20 5060 smallbox.example.com.
The SRV record type allows for definition of services available in a zone, for example, ldap, http, zip and many more. The type-specific field must contain priority, weight, port and target. The SRV record type were defined in RFC 2782.

PTR
34.216.184.93.in-addr.arpa. 86400 IN PTR www.example.com.
The pointer record type is used as a reverse mapping of an IP address to its hostname. The PTR record type is used in the arpa domain.

A complete list of current, experimental and obsolete DNS resource record types can be found on Wikipedia. We will introduce additional RR types when we introduce the DNS security extension, DNSSEC later in this tutorial.

A resource record set is a grouping of two or more DNS resource records of the same type and with the same owner-name.
Below are a few examples of DNS resource record sets. You have seen them before in this tutorial but perhaps not reflected about them.

example.com. 86400 IN NS a.iana-servers.net.
86400 IN NS b.iana-servers.net.

or

example.com. 21599 IN MX 10 alt3.aspmx.l.google.com.
example.com. 21599 IN MX 1 aspmx.l.google.com.
example.com. 21599 IN MX 5 alt1.aspmx.l.google.com.
example.com. 21599 IN MX 10 alt4.aspmx.l.google.com.
example.com. 21599 IN MX 5 alt2.aspmx.l.google.com.

and

_sip._tcp.example.com. 86400 IN SRV 10 60 5060 bigbox.example.com.
86400 IN SRV 10 20 5060 smallbox.example.com.