DNS Tutorials

Table of content

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

In the beginning

Building the Internet was quite an achievement by a lot of smart people! There are many fascinating and interesting stories about how the Internet and the Domain Name System came to be. The story spans decades before the first functional DNS system saw the light of day at UC Berkeley in 1984. If interested we recommend that you read A Brief History of the Internet at Internet Society.

In short, the DNS and the Domain Name System were developed to address existing and emerging problems that could have slowed or halted the development and growth of the Internet. The Domain Name System is a set of rules about how Internet names are organised hierarchically, and how they work and interact.

The DNS was designed with the Domain Name System in mind. From the start, the DNS was designed to be both fast and resilient. The architects succeeded in their intentions!

The Internet domain name space

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.

Domains and zones

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 (pictures 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 are 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.

DNS building blocks

The DNS infrastructure comprises two distinctive entities: authoritative name servers and iterative resolvers.

An authoritative name server holds the data for its assigned domains as well as information about delegated domains or subdomains. The delegation information held by the name servers is 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 have no data on their own but are designed to look up the data they’re queried for. They have only information about where to start their 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.

Authoritative DNS

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

In order for the DNS and domain hierarchy to 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 is the DNS server 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.

Note that the NS records in the example above are identical in both parent and child. This is important to ensure 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 holding that domain’s authoritative data. Should both of them fail, no data for the example.com domain, including any delegated subdomains, would be available.

DNS resolver and the iteration process

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

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

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

In the picture above, we introduce a stub resolver. This resolver lacks iterative capabilities and can only be configured to know where to direct its queries. It can be found in virtually all Internet-aware hosts.

The stub resolver queries its configured iterative resolver to find the IPv4 address to the host www.example.com.
The iterative resolver doesn’t know the answer, so it begins an iteration process to find the answer to the query. The iterative resolver queries one of the root name servers for the IPv4 address to www.example.com.
The root name server doesn’t know the correct answer to this query since it only serves the root zone. What it does is to give a little help along the way. It does know which name servers 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.
The iterative resolver repeats the same query, but thanks to the referral response it just received, the query is directed to one of the authoritative name servers for the .com domain.
The .com name server, like the root name server in the last query, doesn’t know the correct answer either. However, it does know which name servers are authoritative for the example.com domain and encloses that knowledge in a referral reply.
Once again, the resolver sends the same query to the example.com name servers.
This time, the example.com name servers know the answer to the query and return a reply with the requested information.
The iterative resolver has successfully found the requested reply, returns the answer to the stub resolver, and closes the iteration process.

Cache

To speed up the iteration process, a resolver caches each answer and referral it receives. Instead of repeating the whole process, each resolver cuts corners and uses the cached information whenever it gets another query.

IIn the example illustration above, the iterative resolver will cache the referral information as well as the query response, while the stub resolver will cache the query response. This caching will result in fewer 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 has 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 is received, it can go straight to the example.com name servers.

The cached information will remain in the cache as long as each individual resource record allows. 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.

DNS resource records

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.

Common resource record types

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

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 precisely 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). This defines the email address of the zone’s responsible person. 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 notification messages when the zone content is updated. If a slave server hasn’t heard from its Master, it uses 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 TTL value defines how long a resolver should cache a NXDOMAIN (non-existent domain) answer. In RFC 2308, this field was 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 specified in the owner-name field. A zone file usually contains more than one NS record. The type-specific data field must contain a hostname.

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 hostname 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 hostname specified in the owner-name field. The AAAA record type was defined in RFC 3596.

CNAME

alias.example.com. 86400 IN CNAME www.example.com.

The CNAME rRR type is used to alias one name to another. This record type should be used when a host needs 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 1990s, however, machine-readable data like the Sender Policy Framework and other arbitrary string attributes described in RFC 1464 have mostly used this record.

SPF

example.com. 86400 IN SPF "v=spf1 -all"
example.com. 86400 IN TXT "v=spf1 -all"

The SPF record type defines the servers authorized to send mail for the domain. Take note of the identical TXT record type! Not all MTAs (Mail Transfer Agents or mail servers) have implemented the SPF record type, which was 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 the definition of services available in a zone, such as LDAP, HTTP, zip, and many more. The type-specific field must contain priority, weight, port, and target. The SRV record type was 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.

Wikipedia has a complete list of current, experimental, and obsolete DNS resource record types. Later in this tutorial, we will introduce additional RR types when we introduce the DNS security extension DNSSECl.

Resource record sets

A resource record set groups 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 on them.

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

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.

Authoritative DNS Master & Slave

An established and familiar way to set up authoritative DNS servers is to configure one server as a master and the rest of the servers as slaves. This setup allows for easy administration. The updates to the zone files are performed on the master server, which, in turn, makes the new zone file available to the slaves.

The slave servers picks up the zone files from the master server by zone transfers, either by periodically checking in to the master server using the SOA refresh timer or by way of a notification sent by the master server.

The DNS servers make no distinction in their zone data, whether configured as master or slave. The zone data is identical as long as all slave servers are correctly updated.