Domain Name System (DNS) - Part 1

This is a DNS blog series of two parts.

In this first part I will give an introduction to DNS, including some examples and hands-on experiments on the command line. So you will understand the concept of DNS much better! In Part 2 we will setup our own DNS server. Let’s get started!

What is DNS?

DNS stands for Domain Name System. DNS is actually not a single server, but DNS a hierarchical and distributed service.

DNS is very important for the current Internet as you know it. DNS is used, for among other things, to lookup IP address for a specific domain name.

Without DNS, users (yes you) would have to enter the IP addresses in your web browser or manually keep track of IP addresses, which are long and difficult to remember 😵‍💫.

Which is no fun. Hence we have DNS!

Before DNS

Before DNS, people manually kept track of IP addresses by storing it a HOSTS.TXT (which is now just /etc/hosts under Linux) file on each computer:

192.168.1.204 melroy-threadripper

And before host files there was ARPANET. However in this blog post will only focus on DNS with its current technologies.

How does DNS work?

DNS works by using a hierarchical system of domain names and IP addresses. When a user types a domain name into their browser, their computer sends a request to a DNS server, which then looks up the IP address associated with that domain name and returns it to the user’s computer.

Root servers are the highest level of the DNS hierarchy. They are responsible for resolving the domain names of the top-level domains (TLDs) such as .com, .org, .net and so much more TLDs.

Ever wondered why are there dots in domain names 😏?

Take for example: blog.melroy.org. Well actually, the domain is: blog.melroy.org. (with a period at the end). Since it’s a fully qualified domain name. But often the dot at the end is omitted.

And each dot separate the domain name in different hierarchical levels, in our case we have:
“blog”, “melroy” and “org”.

We start from right to left. Let’s show how this DNS request works in an use-case diagram (click on the image to enlarge):

In the diagram above we made an assumption there was no DNS cache and we are using a recursive DNS server.

The search will start at one of the root servers (see diagram above). The root server doesn’t know the IP of blog.melroy.org, but responsds with a name server for the TLD (top-level domain), which is .org in our case.

The recursive name server will then query the authoritative TLD (.org) name server for the domain name “melroy.org”. The TLD name server will again respond with a name server, but this time for the domain name “melroy.org”.

Finally, the recursive resolver will contact that authoritative name server for “melroy.org” in order to find the IP address for “blog.melroy.org”. This final name server hopefully finds the IP address for this sub domain and returns it.

After that, the application (eg. the web browser) can setup a request towards the IP address. In case of a web browser a request is made to the IP address and the web server will respond with the webpage content, assuming the request was valid and the server is up and running.

Did you know?

Did you know all the domains you visit are actually fully qualified domain names? And these domain names should always contain a dot at the end?

Try it out yourself, use your browser and type: blog.melroy.org. (notice the trailing dot). If you leave out the dot at the end, your browser always assume it’s a fully qualified domain name.

Opmitting this trailing dot only works if you have at least one dot in the domain name (which is always the case nowadays).

So in theory we could have had: http://ai. (yes with the trailing dot), but that doesn’t work since the browser either don’t understand it and people don’t know how to enter it. And if you just type: ai in most browsers that will just triggers a web search.
However, we do have http://www.ai/.

What are root servers?

We briefly mentioned root servers before. That being said, these root servers are at the highest level of the DNS hierarchy. They are responsible for resolving the domain names of the top-level domains (TLDs) such as again .com, .org, and .net and others.

And how does your computer know where to find the root servers?🤔 Well, actually the root servers are hardcoded within the operating system. Or compiled within the software.

There can only be 13 root servers by design. Yes, you heard that right, only thirteen. Most of the internet root servers are in operated by USA as its origin.
DNS isn’t decentralized. DNS might be distributed, but DNS definitely not decentralized.

DNS cache

DNS servers will NOT constantly query the root servers or top-level domain servers. DNS servers typically cache the DNS records for a period of time. The duration is described at the authoritative server or you can override this behaviour as well.

The cache is also the reason that changing a DNS record will take some time to propagate across the internet and to other name servers. In some cases a hour or longer.

If you run software like Unbound on your computer, this will cache DNS records for you. Same for systemd-resolved. If you use systemd-resolved? First of all sorry to hear that 🤭. However you can see the cache via:

sudo resolvectl show-cache

If you use Unbound, you can see the cache via:

sudo unbound-control dump_cache

What is a DNS zone?

A DNS zone is a collection of DNS records that are associated with a specific domain name. Each DNS zone has its own set of DNS records, which are used to resolve domain names within that “DNS zone”. A zone could be just a single domain name.

The zone file is plain text file, it’s initial release year was in 1987 (38 years ago) 😵. It’s a very old format and used till this day by most authoritative DNS servers.

I won’t go into the details of the zone file format, but it’s important to know that the zone file contains the DNS records for a specific zone. And the trailing dot at the end in a domain, used to indicate that the domain name is fully qualified, which is critical in a zone file.
Also in the zone file the cache values are stored (like the TTL values).

Recursive vs authoritative name servers

A recursive name server (also known as: recursive resolver) is a DNS server that is responsible for resolving domain names by querying other DNS servers.

A recursiver server does not have a zone file / the information itself. It only knows how to query other DNS servers and store + cache the response for a specific requested domain name.

So which servers do have the answers? These are the authoritative name servers. The root servers (mentioned earlier) are all authoritative name servers. Software like Bind or NSD are used for authoritative name servers.

In part 2 of this DNS series, we will actually use NSD to setup our own authoritative name server. Including your own zone files.

What are the common DNS records?

The most common DNS records are:

SOA record is important for the DNS system it stands for Start Of Authority. It is the first record in a zone file and contains information about the zone, such as the name server that is authoritative for the zone, the serial number of the zone (aka version number basically), and the refresh, retry, and expire times for the zone.

Like shown above the A & AAAA records are the basics and the most common records to point to an IP address. CNAME is used to create aliases for domain names. NS records are used to specify the name server for the domain.

Ready to roll up your sleeves?

Hands-on experiment

We will use the dig BIND command to query the DNS servers. Each example given can be executed on your own computer.

Under GNU/Linux the package is called bind9-dnsutils (Linux Mint/Ubuntu) in my case. On other distros it might be called bind-tools or just bind (Arch Linux). BIND is a full-fledged name server software, for now we just use DNS utility called dig. Using native Windows, then you are out of luck 🤐. Maybe try WSL or install Linux already.

We start with the most basic command. Execute the following command:

dig facebook.com.

That should contain an ;; ANSWER SECTION: section. With the IPv4 address of Facebook.

Did you know?

The name server used depends on your computer’s configuration. Most likely your computer is configured by a DHCP server. The DHCP server probably provided you the primary (and secondary) DNS name servers. Which are often by default your ISP name servers (blehh). Within your router, you might be able to change the default name servers that are used across your network. On the device itself, you can also change the DNS settings per network interface.

Did you know, did you know!??

Under Linux you have the /etc/resolv.conf file. However this file can be very misleading if this file only contains nameserver 127.0.0.53 (meaning localhost/loopback). If you are using NetworkManager under a Debian/Ubuntu distro, it’s very likely you are using something like systemd-resolved. Which has it’s own configuration file: /etc/systemd/resolved.conf.

Systemd-resolved has a DNS stub resolver which create the DNS message and sends it to a DNS recursive server. If you want to know the actual DNS server used by systemd-resolved, you can use the following command: resolvectl status

Using another DNS server (eg. 8.8.8.8, which is the Google DNS server) is also possible via the following @ syntax:

dig @8.8.8.8 facebook.com.

In both cases the output is hopefully the same as earlier 😊. Actually the dig facebook.com. command is the same as running (notice the A):

dig facebook.com. A

Because the dig command will use the A record type by default in case no type argument is provided.

If you want to know the IPv6 address of Facebook for example, you can use the AAAA record type:

dig facebook.com. AAAA

Or what about the mail server of Facebook. We can use the MX record type:

dig facebook.com. MX

Next, let’s start querying the root server. We talked earlier about root servers already. Let’s see what the name server is for the .com TLD:

dig @a.root-servers.net. com.

The output include the name server (NS) records under ;; AUTHORITY SECTION:, as well as A, AAAA records:

com.			172800	IN	NS	l.gtld-servers.net.
com.			172800	IN	NS	j.gtld-servers.net.
com.			172800	IN	NS	h.gtld-servers.net.
com.			172800	IN	NS	d.gtld-servers.net.
com.			172800	IN	NS	b.gtld-servers.net.
com.			172800	IN	NS	f.gtld-servers.net.
com.			172800	IN	NS	k.gtld-servers.net.
com.			172800	IN	NS	m.gtld-servers.net.
com.			172800	IN	NS	i.gtld-servers.net.
com.			172800	IN	NS	g.gtld-servers.net.
com.			172800	IN	NS	a.gtld-servers.net.
com.			172800	IN	NS	c.gtld-servers.net.
com.			172800	IN	NS	e.gtld-servers.net.

So there you have it, these are the top level domain servers for the .com. These DNS name servers have the information about all the dot com domains. What about the A and AAAA records? We will come back to that later.

You could now query the name .com top-level domain server records for let’s say google.com:

dig @k.gtld-servers.net. google.com. NS

The answer you should get back under the ;; AUTHORITY SECTION: section is:

google.com.		172800	IN	NS	ns2.google.com.
google.com.		172800	IN	NS	ns1.google.com.
google.com.		172800	IN	NS	ns3.google.com.
google.com.		172800	IN	NS	ns4.google.com.

That are the name servers for the google.com domain. Which can be queried in case of sub-domains like mail.google.com or www.google.com.

The dig response also included a ;; ADDITIONAL SECTION: section as well:

;; ADDITIONAL SECTION:
ns2.google.com.		172800	IN	AAAA	2001:4860:4802:34::a
ns2.google.com.		172800	IN	A	216.239.34.10
ns1.google.com.		172800	IN	AAAA	2001:4860:4802:32::a
ns1.google.com.		172800	IN	A	216.239.32.10
ns3.google.com.		172800	IN	AAAA	2001:4860:4802:36::a
ns3.google.com.		172800	IN	A	216.239.36.10
ns4.google.com.		172800	IN	AAAA	2001:4860:4802:38::a
ns4.google.com.		172800	IN	A	216.239.38.10

What is that!? These are the glue records of the name servers. What are glue records?!?
Glue records provide A (or AAAA) DNS records with the IP address of the name server(s). So for the Google name server ns2.google.com. will have both an A record and AAAA record, respectively set to: 216.239.34.10 and 2001:4860:4802:34::a.

OK. But why?

The usecase for glue records is when you don’t know the IP address behind the the name server, but the domain name is the same as the name server root-name.

Like how do you know the IP address of the name server ns2.google.com? You will need to know the IP address of the name server google.com. But you can find the IP address of the name server google.com. For that you will need to find the A record of that domain. But you will need to know the name server of that domain, but that will only tell you the name server domain, not the IP address etc. etc. This is causing a endless loop ∞. A glue record solves this problem, and breaks the vicious circle.

A DNS glue record is stored on a top-level domain server. And this extra information is under ;; ADDITIONAL SECTION:. See also the following figure:

Reverse DNS

Reverse DNS is the opposite of a forward DNS look-up. Instead of looking up an IP address, a reverse DNS look-up looks up the domain name for a given IP address.

You can also use dig to execute a reverse DNS look-up by using the -x option. For example:

dig -x 8.8.8.8

The answer should be: dns.google. using a PTR (Pointer) DNS record.

We didn’t talk about the PTR record type yet, but this type is used to map an IP address to a domain name. Thus only used for reverse DNS lookups.

Here is another example of a reverse DNS lookup:

dig -x 129.134.30.12

Can you figure out what the domain this IP is associated with? And where this domain is used for?

• DNS
• Network
• GNU
• Bash
• Linux
• Dig
• Unbound
• Terminal
• Facebook