Domain Name System (DNS)¶

Overview¶

Domain Name System (DNS) translates human-readable domain names (like www.example.com) into numerical IP addresses (like 192.0.2.1) that computers use to identify each other on the network. Practically every internet-connected system relies on a working DNS — without it, users would need to memorize IP addresses for every service they want to reach.

DNS is a hierarchical, distributed database. No single server holds all the information; instead, the responsibility for different parts of the namespace is delegated across thousands of servers worldwide. This makes DNS both scalable and resilient.

How It Works¶

Domain Hierarchy¶

DNS is organized as a tree structure, starting from a root (.) and branching into top-level domains (TLDs), second-level domains, and subdomains:

.                          (root)
├── ee                     (TLD)
│   └── ut.ee              (second-level domain)
│       └── cs.ut.ee       (subdomain)
│           └── sa.cs.ut.ee
└── com
    └── google.com

Each level can delegate authority for its subdomains to other DNS servers. For example, .ee delegates ut.ee to the University of Tartu's name servers, which in turn can delegate sa.cs.ut.ee to the course infrastructure.

DNS Resolution (Recursion)¶

When a client asks "where is courses.cs.ut.ee?", a recursive resolver walks the hierarchy:

Ask root servers: "Who handles .ee?"
Ask .ee servers: "Who handles ut.ee?"
Ask ut.ee servers: "Who handles cs.ut.ee?"
Ask cs.ut.ee servers: "What is the IP for courses.cs.ut.ee?"

The recursive resolver caches answers to speed up subsequent queries. The TTL (Time to Live) on each record controls how long a cached answer is considered valid.

A recursive resolver does this full lookup on behalf of clients. An authoritative server holds the actual zone data and answers queries about its own domain — it does not look up other domains.

Zone Files¶

A zone file is a text file that contains the mappings between domain names and IP addresses (and other data) for a particular domain. The zone is served by an authoritative DNS server.

Example zone file structure:

$TTL    15M
@       IN      SOA     ns1.example.com. admin.example.com. (
                     2024030101         ; Serial
                            15M         ; Refresh
                             5M         ; Retry
                           120M         ; Expire
                            600 )       ; Negative Cache TTL

@              IN      NS      ns1
@              IN      A       192.0.2.1
ns1            IN      A       192.0.2.1
www            IN      CNAME   example.com.
mail           IN      A       192.0.2.1
@              IN      MX  10  mail

Key syntax rules:

; marks a comment
$TTL sets the default cache time for all records
$ORIGIN sets the base domain (often inferred from the zone declaration)
@ expands to the zone origin (e.g., example.com)
Short hostnames (like ns1) are automatically expanded with the origin (→ ns1.example.com)
FQDNs must end with a . (e.g., example.com.) to prevent automatic expansion

Key Terminology¶

SOA (Start of Authority): Defines the zone name, email contact, serial number, and timing values (refresh, retry, expire, negative cache TTL). The serial number must be incremented whenever the zone is updated — slave servers compare serials to decide whether to fetch new data. Convention: YYYYMMDDNN format.
A Record: Maps a hostname to an IPv4 address. Example: www IN A 192.0.2.1
AAAA Record: Maps a hostname to an IPv6 address.
NS Record: Declares the authoritative name server(s) for a domain. Used to delegate subdomains.
MX Record: Specifies the mail server responsible for accepting email for the domain. Includes a priority value — lower numbers mean higher priority. Example: @ IN MX 10 mail.example.com.
CNAME Record: Creates an alias pointing to another domain name. Resolution happens in two steps: alias → canonical name → IP. Limitations: MX and NS records cannot point to CNAMEs; root domain records typically cannot be CNAMEs.
PTR Record: Reverse DNS — maps an IP address back to a domain name. Used in ARPA zones.
Record format: <name> <ttl> <class> <type> <data> — where name is the hostname, ttl is optional cache time, class is almost always IN (Internet), type is the record type, and data is the type-specific value.

Reverse DNS (ARPA)¶

Forward DNS maps names to IPs. Reverse DNS maps IPs back to names using PTR records under the .in-addr.arpa domain.

To construct the reverse lookup name for an IPv4 address, reverse the octets and append .in-addr.arpa.:

IP address: 192.0.2.10
Reverse name: 10.2.0.192.in-addr.arpa.
The zone for the /24 subnet 192.0.2.0/24 is: 2.0.192.in-addr.arpa

Reverse DNS is important for:

Email: Many mail servers reject messages from IPs without valid PTR records
Logging: Identifying the hostname associated with an IP in log files
Security: Verifying that forward and reverse DNS records match (forward-confirmed reverse DNS)

Zone Transfers and Hidden Primary¶

In production, DNS zones are served by multiple servers for redundancy. The primary server holds the master copy, and secondary servers obtain copies via zone transfers (AXFR/IXFR).

In a hidden primary configuration, the primary server is not listed in public NS records — it only pushes zone data to known secondaries. The secondaries are the publicly visible authoritative servers. This improves security because the primary is not directly queried by the public.

When zone data changes on the primary, it sends a NOTIFY message to secondaries, which then initiate a zone transfer.

Common Ports and Protocols¶

Port	Protocol	Purpose
53	TCP/UDP	DNS queries and zone transfers
5353	TCP/UDP	Used in this course for the authoritative server

Most regular queries use UDP. TCP is used for zone transfers (AXFR) and responses larger than 512 bytes.

Why It Matters¶

DNS is foundational infrastructure. If DNS is down or misconfigured:

Websites become unreachable (even though the servers are running)
Email delivery fails (MX records not found)
TLS certificate validation can fail
Service discovery breaks

As a system administrator, you will configure DNS zones for your services, troubleshoot resolution failures, and understand how caching affects propagation of changes.

Common Pitfalls¶

Forgetting the trailing dot in FQDNs within zone files — mail.example.com without a dot becomes mail.example.com.example.com.
Not incrementing the serial number after zone changes — slave servers won't pick up the update until TTL expires.
Confusing recursive and authoritative roles — a server can be both, but they serve different purposes.
TTL caching — after changing a record, old cached values persist until the TTL expires. Plan ahead for critical changes by lowering TTL first.
CNAME restrictions — you cannot use a CNAME for a domain that also has MX or NS records.