Skip to end of metadata
Go to start of metadata

DNS beginners guide

A brief history

In the beginning, the Internet consisted of only a few servers and clients. Back then they used a text file (the /etc/hosts file) to identify Internet hosts by their names rather than their IP addresses. These files were constantly updated and redistributed. It doesn’t take anyone long to understand that this concept didn’t scale very well. For that reason the DNS was invented.DNS is short for Domain Name System and is a hierarchical distributed database. In short it is a phonebook for the Internet name space. The DNS is used to translate human readable names into computer understandable IP addresses. DNS also routes mail between mail servers and keep track of where to find particular network services.This crash course will not turn you into a DNS expert but it will provide you with a basic understanding about how the intricate components of the DNS works.

DNS servers

To make the Domain Name System scalable the DNS servers consists of two distinctive parts: The Authoritative DNS, which contains the DNS data and the resolver, which is designed to navigate the DNS tree to lookup any available DNS data.

The Domain Name System

The domain name system contains the whole Internet name space.

Take a look at the picture below.

This is a small part of the ever growing domain name space. As of February 2015, the root domain contains 810 top-level domains (TLD) where approximately 250 of them are two-letter country-code TLD’s. The domain name space is like an inverted tree where the domains branches out from the root (top) and down. The name space consists of Domains, Zones and Resource Records. Without getting in to too much detail, here is a run-down of the domain “apicasystem.com”. The domain “apicasystem.com” is a sub-domain under the “.com” domain. “Apicasystem.com” is also a zone file residing on the authoritative name servers delegated from the “.com” name servers. Resource records are the building blocks of a zone file. The most common resource records are describe later in this beginners guide. A “delegated” domain is a way for the parent (in this case the “.com” TLD servers) to distribute the administrative responsibility of a subdomain to another DNS. A DNS server who has been delegated a certain domain is considered to be “authoritative” for that domain. This means that correct first hand data for that particular domain can’t be found anywhere else on the Internet.

Registration authorities (registrars)

A domain is acquired through different registrars. The registrars are responsible for keeping the TLD name servers up to date on which domains are registered and which name servers are authoritative for the specific domain. As a part of the registration process at least two Domain Name Servers must be appointed (for redundancy reasons). These name servers are the only name servers in the world that is authoritative for the specific domain.

Authoritative DNS

Throughout the Internet there are millions of authoritative name servers. An authoritative name server for a certain domain, will only answer queries for the content of that specific domain. It will also provide information of its own delegations.

As an example, the authoritative name servers for “apicasystem.com” will respond with correct data to queries for “www.apicasystem.com” but will not respond to queries concerning, for example, “google.com” or “amazon.com”. It will also provide information on where you can find answers to the delegated subdomain “dev.apicasystem.com”.

An DNS server can be authoritative for lots of domains.

DNS resolvers and name resolution

There are two different type of resolvers, the  stub resolver and the iterative resolver.

The stub resolver

The stub resolver is what you usually find in any type of computer device. The stub resolver can only be configured with IP addresses to iterative resolvers.

The stub resolver will cache any answers it receives.

The iterative resolver

The DNS resolver is purpose built to find out which domain name resolves into what particular IP address.  To help in doing that, the iterative resolver knows the IP addresses to the 13 root name servers of the Internet.

The resolver find the answers by way of iteration, starting from the top, or the “root” domain, working its way through the DNS tree until it receive an answer.

The resolver will cache all data it receives during a query. The cached data will remain cached for as long as the TTL allows.

The iteration process

The iteration process starts when an iterative resolver receives a recursion request from a stub resolver. In this example the request is to resolve the IP address of the domain name “www.example.com”. The iteration process is a series of DNS queries where each query finds out where to place the next query to finally receive the answer it was looking for. The first query is placed to one of the root name servers who will provide a referral to the name servers responsible for the “.com” TLD. The second query is placed to one of the “.com” name servers provided by the first query. The response will provide information of which name servers responsible for the “.example.com” domain (2nd level domain). The final query will be placed to one of the name servers responsible for the “.example.com” which will provide the correct answer. The final step is to deliver the response to the stub resolver who initially requested the information.

In this example the request is to resolve the IP address of the domain name “www.google.com”. Thanks to the cache mentioned earlier, the consecutive queries will first try to use cached information before performing the whole iterative sequence. Since the iterative resolver already know which name servers responsible for the “com.” domain it will skip the first iteration round and start the iteration process on one of the name servers responsible for “.com”. The following steps works identical as the first example.

In our final example a query for the name “ftp.example.com”, the resolver get two consecutive cache hits: for the “com.” name servers and the “example.com” name servers. The resolver can skip the first and second iteration round and place the query to the “example.com” name server.

Resolver cache

Both the stub resolver and the iterative resolver cache all replies it receives. This has great impact on response times since the resolver very rarely need to go through the whole iteration process each time it receive a query.

TTL

Each resource record have a Time To Live. The TTL controls how long a record can be cached by a resolver before it have to be discarded.

Resource record types

Below is a list of the most common resource record types.

SOA

Start Of Authority. The SOA record define the zone file and how the master and slaves keep track of DNS data.

NS

Name Server record. Also known as a delegation point. The record set states which name servers should be used by resolvers to obtain information about the domain.

A

IPv4 host record.

AAAA

IPv6 host record

MX

Mail exchanger record. The MX record defines where a sender MTA (Mail Transfer Agent) should deliver mail to the domain.

PTR

Pointer record. Where the A and AAAA records map a host name to a certain IP address, the PTR record maps an IP address to a specific host (FQDN).