Domain Name System (DNS) #

Domain Name System (DNS) is the distributed database and protocol that translates human-friendly domain names (like www.example.com) into the IP addresses (like 93.184.216.34) that computers actually use. The web, email, API traffic, CDNs, SaaS — every modern internet workload passes through DNS resolution. DNS uses UDP/TCP port 53 by default (and 853 / 443 / 443-QUIC for the modern encrypted variants).

1. The history of DNS #

1.1 The limits of the HOSTS.TXT era #

In the early ARPANET, the mapping from hostnames to IP addresses was managed in a single centrally-curated file: HOSTS.TXT. SRI-NIC (the Stanford Research Institute Network Information Center) maintained the master copy, and every host periodically downloaded it.

Once the host count crossed a few thousand, this approach broke down:

• The central administrator became a bottleneck (update requests piled up)
• The file got bigger and the distribution traffic grew
• Consistency across hosts was hard to guarantee
• Naming collisions were unavoidable

1.2 Designed by Paul Mockapetris (1983) #

In 1983, Paul Mockapetris designed DNS as a distributed name-resolution system, published as RFC 882 / 883. Three ideas underpin the design:

1. Hierarchical name space — domains form a tree of .-separated labels.
2. Delegation — each subtree's management can be handed off to a different organization.
3. Caching — resolved answers can be reused to spread load.

These together let any organization run its own slice of the namespace and made the system scale to global size.

1.3 Standardization in RFC 1034 / 1035 (1987) #

The RFC 1034 (concepts and facilities) and RFC 1035 (implementation and specification) documents from 1987 are still the foundation of DNS today. Over thirty years on they remain in force (many extensions have been layered on, but the core hasn't changed) — among the longest-lived specs on the internet.

1.4 BIND and operational maturity #

BIND (Berkeley Internet Name Domain), developed at UC Berkeley, was the de-facto standard DNS server implementation for a long time and shipped with virtually every major OS. Alternative implementations like NSD, Knot DNS, PowerDNS, and Unbound later emerged and are now picked according to use case.

1.5 Incremental hardening #

Over the years DNS has been hardened in stages:

• EDNS (RFC 6891, 1999) — extends past the UDP 512-byte limit; needed for DNSSEC and large responses.
• DNSSEC (RFC 4033-4035, 2005) — public-key cryptography for response authenticity.
• DoT (DNS over TLS, RFC 7858, 2016) — TLS encryption.
• DoH (DNS over HTTPS, RFC 8484, 2018) — HTTPS encryption.
• DoQ (DNS over QUIC, RFC 9250, 2022) — QUIC for low-latency encryption.

2. The structure of DNS #

2.1 An inverted tree #

DNS is best visualized as an inverted tree with the root at the top. The four layers, the delegation flow, and how an FQDN is composed are summarized below.

• The root (.) sits at the top.
• Below it are the top-level domains (TLDs): com, org, jp, io, etc.
• And then the second-level, third-level … domains underneath.

2.2 Naming conventions #

Domain names are written like www.example.com. with . separators (the rightmost label is the highest in the hierarchy). The trailing . (the root) is usually omitted in casual use, but is technically there.

• Label: each .-separated component. Maximum 63 octets.
• FQDN (Fully Qualified Domain Name): the complete form including the root, e.g. www.example.com.
• A whole name is at most 253 octets.
• Case-insensitive (Example.COM = example.com).

2.3 The delegation model #

Each organization is delegated authority over its own zone. Verisign manages .com, JPRS manages .jp, and individual domain owners (example.com, example.jp) manage their own.

Delegation is expressed via NS records. The parent zone (com) saying "the authoritative servers for example.com are ns1.example.com and so on" is what tells resolvers where to look next.

3. DNS components #

3.1 The root servers #

The servers that serve the root zone (.). There are 13 letter labels (a.root-servers.net through m.root-servers.net) worldwide; each label is anycast to many physical instances around the globe (well over 1,000 in total).

The root servers don't return final answers — they only return referrals like "the authoritative servers for .com are over here."

3.2 TLD servers #

Servers that manage TLD zones like .com, .jp, and .io. Operated by registries (Verisign, JPRS, ICANN-accredited entities). Like the root servers, they don't have final answers — they return "the authoritative servers for the requested domain are over here."

3.3 Authoritative DNS servers #

The servers that hold the records for a specific zone (e.g. example.com) and return the final answers. The domain owner runs them directly, or — much more commonly — delegates the work to a hosted DNS provider (Cloudflare, AWS Route 53, Google Cloud DNS, Akamai).

3.4 Resolvers #

The components that perform name resolution on the user's side.

• Stub resolver — a lightweight client built into the OS. Always asks an upstream full resolver (via APIs like getaddrinfo()).
• Full / recursive resolver — does the actual work: queries from root downward, holds the final answer, caches it. Provided by ISPs, by enterprises internally, or as public services (8.8.8.8, 1.1.1.1, 9.9.9.9).

3.5 Caching DNS / forwarders #

Run inside an organization to serve internal stub resolvers. They keep their own cache, and forward cache misses to an external full resolver. They also keep internal-domain resolution local to the organization.

4. How resolution works #

4.1 The full recursive flow #

A typical resolution of the A record for www.example.com. The sequence diagram below shows the round-trip of query / referral / answer between the actors.

In text form:

[1] Client → stub resolver:
    "What's the A record for www.example.com?"

[2] Stub resolver → full resolver (e.g. 8.8.8.8):
    "Recursive resolution please" (RD=1)

[3] Full resolver → root server:
    "Tell me about www.example.com"
    → Root: "The authoritative servers for .com are a.gtld-servers.net etc.
             — ask them" (referral)

[4] Full resolver → .com TLD server:
    "Tell me about www.example.com"
    → TLD: "The authoritative servers for example.com are
            ns1.example.com etc. — ask them" (referral)

[5] Full resolver → example.com authoritative server:
    "What's the A record for www.example.com?"
    → Authoritative: "93.184.216.34" (authoritative answer)

[6] Full resolver → stub resolver → client:
    "93.184.216.34"
    Cached for the duration of the TTL

4.2 Iterative vs. recursive queries #

• Recursive query: client → resolver. The client wants the final answer.
• Iterative query: resolver → each authoritative server. Each authoritative server only returns "go ask this next."

Exposing a public resolver too widely (open recursive) makes it usable as a DNS amplification weapon, so the iron rule is: don't accept recursive queries from outside your network.

4.3 Caching and TTL #

Each record has a TTL (Time To Live) — the number of seconds a resolver is allowed to cache it.

• Short TTL (60-300 seconds): failover and migrations are fast, but it generates more upstream queries.
• Long TTL (86400 seconds = 1 day): cache-efficient, but changes take longer to propagate.

A records for CDNs and DDoS-protected services are usually short (e.g. 60s); MX and NS records for a stable organization are typically long (3600-86400s).

4.4 DNS message format #

DNS queries and responses share the same format: a fixed 12-byte header plus four variable-length sections.

In text form:

+---------------------+
|  Header (12 bytes)  |  ← ID, flags (QR, OPCODE, AA, TC, RD, RA, AD, CD), section counts
+---------------------+
|  Question           |  ← What's being asked (name, type, class)
+---------------------+
|  Answer             |  ← Answer RRs
+---------------------+
|  Authority          |  ← Authoritative NS records, etc.
+---------------------+
|  Additional         |  ← Supplementary (glue records, etc.)
+---------------------+

Key flags:

5. Major resource record (RR) types #

6. Major commands and use cases #

6.1 dig (Domain Information Groper) #

The most useful and diagnostic DNS query tool. Comes with BIND.

# Basic: A record
dig example.com

# By type
dig example.com MX
dig example.com NS
dig example.com TXT
dig example.com AAAA
dig example.com ANY        # all-in-one (some authoritative servers refuse it)

# Query a specific resolver or authoritative server
dig @8.8.8.8 example.com
dig @ns1.example.com example.com SOA

# Show every step of the iterative resolution
dig +trace example.com

# Just the answer
dig +short example.com

# Reverse lookup
dig -x 93.184.216.34

# Include DNSSEC RRSIG / DNSKEY
dig example.com +dnssec

# DoT (kdig, or dig 9.18+)
kdig -d @1.1.1.1 +tls example.com

A typical dig output:

;; ANSWER SECTION:
example.com.        86400   IN  A   93.184.216.34

;; AUTHORITY SECTION:
example.com.        86400   IN  NS  a.iana-servers.net.
example.com.        86400   IN  NS  b.iana-servers.net.

;; Query time: 25 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)

6.2 nslookup #

The traditional DNS query tool. The default on Windows. For diagnostic depth, dig is preferable.

nslookup example.com
nslookup example.com 8.8.8.8
nslookup -type=MX example.com

6.3 host #

A simpler shorthand query.

host example.com
host -t MX example.com
host -a example.com         # close to ANY
host 93.184.216.34          # reverse

6.4 drill / kdig #

drill comes from NLnet Labs; kdig ships with Knot DNS. Both are strong for verifying modern DNS features like DoT and DoH.

# Query over DoT
kdig -d @1.1.1.1 +tls example.com

# Query over DoH
kdig -d @1.1.1.1 +https example.com

6.5 whois #

Not a DNS command itself, but commonly used alongside DNS troubleshooting to inspect domain registration and authoritative name-server configuration.

whois example.com

7. Security extensions for DNS #

Plain UDP/53 DNS was, for a long time, a hotbed for tampering, eavesdropping, and forged responses. The following extensions hardened it incrementally.

7.1 DNSSEC (DNS Security Extensions) #

Cryptographic verification that a response really came from the authoritative server and hasn't been altered. RFC 4033-4035 (2005).

• DNSKEY: the zone's public key
• RRSIG: signature over each RR
• DS: a fingerprint of the child zone's key, kept in the parent zone
• NSEC / NSEC3: proofs of "this name doesn't exist" (preventing forged NXDOMAIN answers)

Verification chains from root → TLD → authoritative zone (the Chain of Trust). When the resolver returns the AD flag, validation succeeded.

DNSSEC does not encrypt traffic — the contents are still visible. To hide the contents themselves, combine with DoT/DoH/DoQ.

7.2 DoT (DNS over TLS, RFC 7858) #

Wraps the DNS query/response in TLS over TCP/853. Defends against eavesdropping and tampering by intermediate ISPs and public Wi-Fi. Implemented in Android 9+ ("Private DNS") and iOS 14+.

7.3 DoH (DNS over HTTPS, RFC 8484) #

Encapsulates queries in HTTPS POST/GET. Uses TCP/443 just like regular HTTPS, making firewall-level tracking difficult. Available in Firefox, Chrome, and Edge.

DoT and DoH are complementary rather than competitive: DoT for transparent OS-wide replacement, DoH for browser-level encryption.

7.4 DoQ (DNS over QUIC, RFC 9250) #

Carries DNS over QUIC (the transport behind HTTP/3). 0-RTT session resumption and multiplexed streams make it lower-latency than DoT. Forward-thinking resolvers like AdGuard and NextDNS support it.

8. Notable attacks and history #

8.1 Cache poisoning (Kaminsky attack, 2008) #

Disclosed by Dan Kaminsky in 2008 — a serious vulnerability that affected every resolver of the era.

• While the resolver was waiting on an upstream answer, the attacker would flood it with forged responses.
• DNS at the time used only a 16-bit transaction ID to identify responses; with a birthday attack, hitting a forged response was easy.
• A single poisoning persisted in the cache until the TTL expired — and everyone using that resolver was redirected to the attacker's IP for the duration.

Fix: source-port randomization (boosting entropy from 16 bits to 16+16 bits). Every major resolver applied it. The proper long-term fix is DNSSEC.

8.2 DNS spoofing #

A man-in-the-middle on the local segment (e.g., after ARP spoofing) returns forged DNS responses. The implicit trust in the ISP's DNS breaks down — particularly dangerous on free Wi-Fi.

Defense: end-to-end encryption with DoT/DoH, picking trustworthy resolvers, layering on a VPN.

8.3 DNS amplification attack #

A DDoS technique that exploits the property that DNS has small queries and large responses.

• The attacker spoofs the victim's IP as the source and queries an open recursive resolver.
• The resolver returns a much larger response (a DNSKEY response can be 100x the query size or more) to the victim.
• Multiple resolvers x many spoofed queries = saturated victim bandwidth.

Defense: don't run open recursive resolvers (keep them internal-only); apply Source Address Validation (BCP 38) so spoofing is rejected at the network edge; enable Response Rate Limiting (RRL).

8.4 DNS tunneling #

Encode arbitrary data into DNS queries and responses to smuggle C2 traffic and exfiltrate data through the DNS channel firewalls happily allow. Tools like dnscat2 and iodine exist. Slow but hard to detect.

Defense: monitor query length, frequency, and patterns (suspiciously long TXT responses, or spikes of queries to a single domain, are red flags); use DPI; deploy Response Policy Zone (RPZ) to block known C2 domains.

8.5 Subdomain takeover #

A subdomain like old-blog.example.com still CNAMEs to an external service (GitHub Pages, Heroku, S3, Azure, etc.) even though the underlying resource has been deleted. An attacker who creates a resource of the same name on that service can claim the subdomain.

Defense: always remove retired CNAMEs, audit DNS regularly, run automated scanners (subjack, nuclei).

8.6 NXDOMAIN attack / random subdomain attack #

Flood resolvers with queries for random non-existent subdomains (xyz123.example.com). The resolver gets no cache hits and forwards each query to the authoritative server, which collapses under the load.

Defense: rate-limit at the authoritative server; cache NXDOMAIN responses upstream; spread the load via Anycast.

DNS isn't "just name resolution" — it's the trust foundation of the Internet itself. It looks unglamorous, but if it's poisoned, everything riding on top of it (HTTPS, email, APIs, CDNs) collapses with it. The arc of this article — hierarchy → resolution → RRs → encrypted extensions → attack history — gives you a concrete frame for what you're actually looking at when you read dig +trace output or stare at an incident log.