A Domain Name System Tutorial

Here is a collection of my study notes on the Domain Name System protocol.

DNS Hierarchy and Database

Remember the format of a URL:

Figure: URL format – copyright www.examsmyantra.com

The Domain Name System protocol is hierarchical. It’s not flat. If you’ve worked with UNIX and Linux file systems, you’ll notice there is a similarity.

The next thing you’ll notice is you have a “dot” symbol at the top of the pyramid. This is the root domain, or root name server. Immediately below it, there are extensions that we all know such as “com” and “org”. These are the Top Level Domains TLDs:

The DNS hierarchy © Stanford University

Below the TLDs are the second-level domains, such as Cisco, Microsoft, etc. And every domain below them is simply called sub-domain:

Figure: DNS Structure – © usahitman.com

The domain name is segmented into different domain levels. Each domain level contains many servers. For example, “ru.wikipedia.org” has four levels:

  • the root domain “.”
  • the Top Level Domain (TLD) “org”
  • the domain “wikipedia”
  • the subdomain “ru”
Figure: an example of a DNS hierarchy for “ru.wikipedia.org”

DNS is distributed, i.e. the Domain Name System database is distributed across many servers. So no one Internet name server has a complete version of the DNS database.

Also, the database is replicated among servers with Anycast technology, which allows redundancy of the DNS information.

Each domain name is maintained by more than one server. For example, the information for the domain name Keyboardbanger.com exists on at least two name servers.

Domain Name System Resolver

The DNS resolver is a software that resides on the client machine (or computer) and performs DNS lookup.

If there are further DNS requests made by the client to the same domain name, the resolver retrieves the answer from its DNS cache. We’ll talk about the DNS cache in the next paragraph.

The information that the Resolver receives from a Domain Name System server is called Resource Records.

Facts about the Domain Name System protocol

DNS is an application-layer protocol that provides translation service to other protocols such as HTTP, email protocols and FTP.

In the past, clients used the HOSTS.txt file to maintain names-to-IP resolutions. The file was updated regularly through a file transfer protocol from a server on the Internet

DNS queries have a default UDP destination port of 53 and a highly-numbered source port. DNS can also run on TCP port 53.

A DNS datagram can have at maximum size of 512B. If the DNS response datagram has a bigger size, then the response is truncated over multiple datagrams. This is possible thanks to the TC flag in the DNS message header.

It takes some time to propagate changes in name-to-IP resolutions across the DNS servers, and it ranges from a couple of minutes to a couple of hours. But this is accepted in the DNS world.

DNS servers on the Internet are usually Linux servers running the BIND process

Remember the End-to-End design principle? DNS servers obey the rules and is implemented at the “edges” of the network

Domain Name System Benefits

DNS allows the following benefits:

    • Host aliasing: one canonical hostname can be associated with one or more alias names. We usually tend to prefer alias names because they are more mnemonic
    • Web and email server aliasing: instead of displaying websites or email addresses in canonical form, we can use aliases to display “fashionable” names. For example, having a website named “DC1-serv.contoso.com” is less desirable to type in a browser than “contoso.com”. And having an email address like “ali@srv2-eur-mail.abccompany.com” is not as cool as “ali@abccompany.com”
    • Load distribution: DNS allows traffic load balancing among IP hosts associated with a domain name. Some busy web servers such as cnn.com run on more than one host. The domain name “cnn.com” is mapped to more than one IP address. Each time  a DNS query is received, the DNS server replies with all the IP addresses mapped to the domain name, but reversing their order each time.

Domain Name System Cache

In order to avoid querying name servers and to make the DNS process a bit faster, DNS clients -the resolvers- have a Domain Name System cache. The DNS cache stores DNS resource records locally for future use whenever a request to a same domain name is made.

The entries in the Domain Name System cache -the resource records- have different aging times. Each record is kept for the duration of the value of TTL of the DNS message received. An implication of this fact is that, even if a resource record is updated somewhere on an Internet name server, the changes won’t be seen by the resolver unless the TTL of the local resource record entry expires.

For example, let’s say a record for keyboardbanger.com is cached and has TTL=3600 sec (1 hour). At time t=2mn, you make a change in a DNS resource record (on the Internet). The resolver won’t see these changes until t=60 – 2 = 58mn later. What does this mean is that, when your PC needs to resolve keyboardbanger.com, the DNS resolver willr return a local information, which is not up to date. In fact, it will take the resolver 58 minutes to clear the cache entry and learn about the resource record modification.

What about resolvers around the world that did not cache the old entry? Well, whenever they need to resolve the domain name keyboardbanger.com, after we made the manual changes, they will get the modified resource record.

So take this in mind whenever you want to make DNS changes.

Types of DNS Name Servers

Local Name Servers

Local name servers are geographically close to the querying host, such as corporate DNS servers or DNS servers for residential Internet users. In the latter case, the local name server sits a couple of routers away from the residential LAN.

Local name servers are able to respond to queries with the mapped IP address, if it’s about the same domain name.

On a computer, local name servers are usually configured automatically through DHCP or manually.

Local name servers have a file called root hints file that stores the IP addresses of root name servers.

Root Name Servers

Root name servers form the root domain. It is maintained by 13 highly secured logical servers. See that I said “logical” and not “physical”, because there are hundreds of physical servers dedicated to the root domain.

When solicited, if the root name server has the IP address of the requested name, it responds with it to the querying host. But this is not common because root name servers should not be burden with such a task. Often, it does not reply with an IP address. Instead, it queries an authoritative name server or forwards the query to an intermediate name server. Beware that the root name server queries the authoritative name server directly only if it knows its IP address.

Authoritative Name Servers

A name server is called “authoritative” for hostnameX if it has the mapping hostnameX-to-IP.

An authoritative domain is domain name on which the name server has authority, i.e. it can map the name to IP:

  • Root name servers are authoritative for the root zone.
  • Local name servers are often authoritative name servers for their respective domain names.

DNS Namespace and Zones

Figure: DNS zones – © Microsoft

A DNS namespace is the set of domain names created under the original domain name. for example, “mail.google.com” and “drive.google.com” form the DNS namespace for “google.com”.

A DNS zone is a subset of the namespace that can be managed (administered) separately from the original domain name. In the figure, the domain “microsoft.com” is a domain name that is under the top level domain “com”. It forms a DNS zone. A subdomain named “example” is created. The domain “example.microsoft.com” can be in the same zone as “microsoft.com” or in its own zone and administered by a different entity.

In a particular zone, records are stored on more than one name server for redundancy. Otherwise, if a name server crashes, a number of name servers would no longer be resolvable.

The way records are replicated between name servers of a zone is called zone transfer, in a client-server communication over TCP. The client is a name server requesting its database to be updated, and the server is either a master server (primary server) or another secondary server.

Domain Name System and UDP

DNS runs over UDP server port 53. The maximum size of a UDP datagram that carries DNS data is 512B (without counting neither UDP nor IP header overheads). If there is more than 512B to put in a UDP datagram, then the DNS message is truncated and the TC flag is set. (The TC flag is part of the DNS header.

Message Sections

The DNS message is composed of a the following sections:

  • Header
  • Question (if this is a query or a response)
  • Answer (if this a response)
  • Authority
  • Additional information
Figure: DNS message format © enclue.com

Message format: the Header section

Figure: DNS header © Inacon.de

The DNS message header is 12B long (32*3/8). The DNS message header is colored in salmon in the figure.

  • ID, aka Identification or Transaction ID. It identifies a query-response pair in a DNS communication
  • from QR to RCODE, these are flags. We will learn them below,
  • QDCOUNT: the number of questions in the message,
  • ANCOUNT: the number of RRs in the answer in the message,
  • NSCOUNT: the number of authority RRs in the message,
  • ARCOUNT: the number of additional information RR in the message.

Here are some of the flags that appear in the DNS message header (whether the message is a query or a response):

  • QR: identifies whether this message is a query or a response.
  • Opcode:if this value is 0 then the message is a standard query.
  • Authoritative Answer: this bit is available only for DNS replies. It tells whether the server is authoritative for the requested domain name.
    • AA = 1; the DNS server is authoritative on the domain name
    • AA = 0; the DNS server is not authoritative on the domain name
  • TrunCated: tells whether the message is truncated or not. A DNS message is truncated when it can not fit in a single UDP datagram with a maximum size of 512 Bytes.
  • Recursion Desired: expresses the querying host’s desire to make a recursive query or not.
    • If set to 1, then it means “the querying host desires a recursive query”. This flag is copied in the response too.
  • Recursion Available: appears only in DNS responses. It tells whether the name server that receives the query can do recursive queries or not
    • If set to 1, this flag says “I can do recursive queries”,
    • if set to 0, this flag says “Sorry dude I can not do recursive queries”.
  • Zero : actually set to 0. This flag is developed for future use.
  • ReplyCODE: This flag is only valid in a DNS reply. It tells whether the response contains errors or not
    • if RCODE = 0, then there are no errors,
    • else: there is an error

The remaining sections

We learned the parts that constitute the Header. This is just one part of a DNS message. In fact, the DNS message contains, in addition to the header, other sections :

  • Question section, if it’s a DNS query or a reply. Strangely enough, the DNS reply contains the Question section too,
  • Answer section, if it’s a DNS reply,
  • Authority section (optional in a DNS reply),
  • Additional section (optional in a DNS reply).

The Question section

When the DNS message is a DNS query, then it has a header and a Question section. The Question section is composed of the three 16-bits fields:

  • QNAME: QNAME is the domain name encoded in labels (we will learn about labels later),
  • QTYPE: determines the type of the query. You can find a complete list of types on Wikipedia,
  • QCLASS: determines the class of the query. Usually QCLASS has the value “IN” to mean “INternet”.

The Answer Section

Figure: DNS RR format © tcpipguide.com

A DNS response message has at least a header,  a Question section and an Answer section. I said “at least” because there can be an Authority section and an Additional section.

The Answer section contains the following parts:

  • NAME: has the same format as QNAME
  • CLASS: has the same format as QCLASS
  • TYPE: has the same format as QTYPE
  • TTL: describes how much time – in seconds- can this record be cached before it must be discarded
  • RDLENGTH: describes the length of the RDATA field
  • RDATA: contains the resource itself. For example, if the RR is of type A, then RDATA is an IPv4 address. If the RR is of type NS, then RDATA is a name server alias hostname.

We saw that QNAME, NAME and RDATA (in case of NS record) contain an alias hostname. But how is the hostname written in the DNS packet?

How a domain name is represented inside the DNS packet

To understand how QNAME is represented (and also NAME and RDATA), we need to understand the way a domain name is represented in a DNS packet. It may seem a bit odd, but once you get the idea, it will become simple.

As I mentioned earlier, the domain name is represented in the form of labels separated by dots (.):


A label can be of two types:

  • Data label
  • Compression label

We’ll talk about compression labels in the DNS Name Compression paragraph. Let’s now define data labels.

Data label

A data label is composed of :

  • Label length: a byte that describes the length of the current label (just before the dot). The value ranges from 0 to 63.
  • the bytes of the current label. Their maximum size is 63 bytes.

For example, the domaine name “www.microsoft.com” has three labels and is encoded in the DNS message in this format:

3     ‘w’     ‘w’     ‘w’     9     ‘m’     ‘i’     ‘c’     ‘r’     ‘o’     ‘s’     ‘o’     ‘f’     ‘t’     3     ‘c’     ‘o’     ‘m’     0

Notice the trailing “0”. This is called the label of length 0 and means the root label. Remember that all DNS domain names end with a root domain; the dot.

The maximum size of a domain name is 255 Bytes (or 255 characters if we suppose that each character is encoded in 1 Byte), including the length bytes and the trailing label of length 0. The dots between labels are not counted.

Pay attention that this is not name compression. It’s just how DNS domain names are encoded in a DNS message.

This domain name encoding is found in the following fields: QNAME, NAME and RDATA.

DNS Analysis with Wireshark

Here is the setting:

  • Client IP address =
  • DNS server IP address =
Figure: a DNS query Wireshark example

DNS Header

The DNS header is the following section in Wireshark:

Figure: DNS header in Wireshark

This is a DNS communication, since the transport protocol is UDP and the destination port is 53:

Figure: UDP port 53

The identification field has the same value for both the DNS query and the DNS response:

Figure: Transaction ID
Figure: Transaction ID in DNS response

The first packet sent is a DNS query:

Figure: DNS query

DNS Query Message

A DNS query message does not contains an Answer field. It only contains a header and a Question fields.

Figure: DNS question section

The query contains QNAME, QTYPE and QCLASS

Figure: DNS question: QNAME, QTYPE and QCLASS

DNS response message

We see that the DNS response contains both “queries” field and “answers” field. This is as if the DNS server says “hey your question is blablabla, and the answer to it is blablabla”. Also, in the flags field, the Questions flag is activated although this is a DNS response. It’s just a way to tell that this message has answers to a previous question.

Figure: queries and answers fields in the DNS response

Here is an example that shows how ANCOUNT equals the number of answer RRs in the DNS message:

Figure: ANCOUNT and answer RR

DNS response: additional records

Here is an example of the Additional information field of the DNS message. The querying host  asked for an MX record of google.com. The DNS server replied with all the email servers that have the alias hostname of google.com, and as additional information, it gives the name-to-IP address mapping of these email servers in A records (pretty generous):

Figure: DNS query for an MX record

DNS lookup process


The Domain Name System and its group of over-the-world scattered servers has grown and continues to grow each day. Newer DNS techniques appeared later such as dynamic DNS.




Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *