Skip to main content

DNS 101: An introduction to Domain Name Servers

Domain names provide the internet much more user-friendly way of referencing servers, but have you ever wondered how it works under the covers?
Image
complex whiteboard problemImage by <a href="https://pixabay.com/users/geralt-9301/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=2853022">Gerd Altmann</a> from <a href="https://pixabay.com/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=2853022">Pixabay</a>

Image by Gerd Altmann @ Pixabay

Second star to the right and straight on ‘til morning — Peter Pan

At the beginning of the ARPANET, there were only a few hosts that could be kept in a simple text file of hostnames. Over the years, and with the explosive growth of the internet, a system was required to help organize the endless number of existing domains and addresses.

Why DNS?

Originally, the Domain Name System (DNS) was created to support the growth of communications by email, and the first email addresses only consisted of <user>@<host>. With the increase of users over time, RFC 805 was created to extend email addresses to <user>@<host.domain>, where domain should be a hierarchy of hosts.

DNS currently supports the internet on a global scale with this model.

IPs vs hostnames

In order to distinguish between each host that is part of a network, each of them is assigned with a hostname and a unique numerical address. The hostname is easier to use and remember for humans, while the numerical addresses are handled by the internal binary system on which the computers are based.

An IP address is the set of numbers that hierarchically identify an interface of a device within the network. The way in which the hierarchy of this grouping is formed is known as addressing, such as 192. 168. 1. 34.

Each of these groups, or segments, indicate the routing mechanism necessary to communicate with them. DNS is the system that performs the translation, in both directions, so that humans can communicate with the hosts and vice versa.

DNS resolution

The Domain Name System has three main components:

  • The domain namespace is the specification for the domain name tree structure.
  • Name servers are server programs that contain the domain tree’s structure information. These servers can set the information or cache it.
  • Resolvers are client programs that extract information from name servers in response to user requests.

Domain name resolution (or DNS resolution) is the process of associating IP addresses with domain names. From the user’s point of view, the domain name system is accessed through the simple call of a program (such as a web browser) by the resolver, which contacts the name server and obtains the information contained in the domain namespace.

Domains and name delegation

The domain namespace is a tree structure. The entire database can be seen as an inverted tree, with the root at the top. Each node and leaf on the tree corresponds to a resource set. The name of the root is the empty string (" ") generally denoted with a dot (.):

Image
The inverted tree of the domain name hierarchy.

A domain name identifies a set of resources that, in turn, is integrated with the separate resource registry (RR). One of the main components of the RRs is the identification of the resource that stores this record, and hence is the owner or the authoritative source of the information.

Public domain names are registered with a registrar authorized by ICANN, a non-profit entity that regulates them. In most cases, these registrants offer the service of taking over the domain name's administration. This process is known as domain name delegation.

The most commonly used DNS server on the internet, Berkeley Internet Name Domain (BIND), provides many tools to query and verify domain information. This is one of the main tasks of a sysadmin who manages servers with services exposed to the internet.

To install BIND and its tools, run:

# yum install bind-utils

The most common types of RRs to verify are:

  • A - The host address associated with the domain name.
  • NS - The authoritative name server for the domain.
  • SOA - Identifies the start of a zone of authority.
  • CNAME - Identifies the canonical name of an alias.
  • PTR - Identifies the IP address associated with the domain/hostname.

For example, if we want to validate the record type A of the redhat.com domain:

# dig redhat.com

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-17.P2.el8_0.1 <<>> redhat.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59061
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;redhat.com.         IN   A

;; ANSWER SECTION:
redhat.com. 3600   IN   A   209.132.183.105

The PTR (or reverse) record query is used to validate that the IP address is assigned to the same host that is resolved in the Mail eXchanger (MX) record query:

# dig redhat.com -t                  MX

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-17.P2.el8_0.1 <<>> redhat.com -t MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4708
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

;; QUESTION SECTION:
;redhat.com.                      IN    MX

;; ANSWER SECTION:
redhat.com. 3394              IN    MX    5 mx1.redhat.com.
redhat.com. 3394              IN    MX    10 mx2.redhat.com.

;; ADDITIONAL SECTION:
mx1.redhat.com. 3419      IN    A     209.132.183.28

# dig -x 209.132.183.28**

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-17.P2.el8_0.1 <<>> -x 209.132.183.28
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59058
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;28.183.132.209.in-addr.arpa.          IN    PTR

;; ANSWER SECTION:
28.183.132.209.in-addr.arpa. 491    IN    PTR
mx1.redhat.com.

This configuration is necessary when the domain manages its own mail service because otherwise, the server can be blacklisted and untrusted.

Another useful troubleshooting procedure is to review the trace left by the routing of our query:

# dig redhat.com @localhost +trace

; <<>> DiG 9 <<>> @localhost redhat.com A
; (1 server found)
;; global options: +cmd
.     513373    IN    NS    g.root-servers.net.
.     513373    IN    NS    h.root-servers.net.
.     513373    IN    NS    a.root-servers.net.
.     513373    IN    NS    k.root-servers.net.
.     513373    IN    NS    b.root-servers.net.
.     513373    IN    NS    m.root-servers.net.
.     513373    IN    NS    c.root-servers.net.
.     513373    IN    NS    f.root-servers.net.
.     513373    IN    NS    l.root-servers.net.
.     513373    IN    NS    j.root-servers.net.
.     513373    IN    NS    e.root-servers.net.
.     513373    IN    NS    d.root-servers.net.
.     513373    IN    NS    i.root-servers.net.
;; Received 228 bytes from 127.0.0.1#53(127.0.0.1) in 7 ms

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

;; Received 504 bytes from 2001:500:2d::d#53(2001:500:2d::d) in 19 ms

redhat.com.    172800    IN    NS    a13-66.akam.net.
redhat.com.    172800    IN    NS    a10-65.akam.net.
redhat.com.    172800    IN    NS    a9-65.akam.net.
redhat.com.    172800    IN    NS    a1-68.akam.net.
redhat.com.    172800    IN    NS    a28-64.akam.net.
redhat.com.    172800    IN    NS    a16-67.akam.net.
;; Received 160 bytes from 2001:503:d414::30#53(2001:503:d414::30) in 197 ms

redhat.com.    3600        IN    A       209.132.183.105
;; Received 44 bytes from 2a02:26f0:117::41#53(2a02:26f0:117::41) in 11 ms

In this query, we can see that it starts in the root DNS servers, who walk to the Top-Level Domains (TLDs) until the domain name registration requested is found and returns the hosts that are identified with it.

Masters and slaves

From the previous examples, we can note that the domain name is assigned to several authoritative hosts. This is a setting similar to the cluster, in order to provide availability in the resolution service.

Domain name record information is contained in a zone file, which can be configured as read/write or read-only. Zone files with read/write are known as Master Zones. There should only be one Master Zone file on a DNS server at a time. All DNS records must be added or modified in the Master Zone.

Slaves Zones are read-only copies of the Master Zone, transmitted from the DNS Master, and are synchronized every certain time to preserve the integrity of the information from the domain name records.

Zone synchronization is a process that can be secured by asynchronous keys for encrypting communication and restricting hosts.

Dynamic DNS

When a variable IP address is assigned to a device, a variant of the DNS server is required to assign a domain hostname. The Dynamic Domain Name System (DDNS) monitors the change of device IP addresses and updates the registry when they are modified.

DDNS is generally used when you have devices on a local network that are required to be accessible through the internet. There are multiple providers on the web that offer this kind of service such as: FreeDNS, Securepoint DynDNS, Dynu, DynDNS Service, DuckDNS or No-IP, some of them with totally free plans or premium paid services.

The toolkit that we previously installed contains a utility (nsupdate) to submit DDNS update requests as defined in RFC 2136 to a name server.

In a future article, I will show you a simple way to set up our own DNS and DDNS server.

What to read next

Topics:   Networking  
Author’s photo

Alex Callejas

Alex Callejas is a Senior Technical Support Engineer of Red Hat, based in Mexico City and an Enable SysAdmin contributor. With more than 10 years of experience as SysAdmin, he has strong expertise on Infrastructure Hardening and Automation. More about me

Related Content

OUR BEST CONTENT, DELIVERED TO YOUR INBOX