How DNS resolution works in practice
By the end of this module you will be able to:
- Trace a DNS query from stub resolver through recursive resolver to authoritative server
- Name the common DNS record types and explain what each one does
- Explain why TTL and caching cause DNS changes to propagate unevenly across the internet
Real-world incident · October 21, 2016
The Dyn DDoS attack: when the internet lost its phone book
On October 21, 2016, a botnet of compromised Internet of Things (IoT) devices called Mirai launched a massive distributed denial-of-service (DDoS) attack against Dyn, a DNS provider based in Manchester, New Hampshire. Dyn provided managed DNS services for a large portion of the internet's major platforms.
The attack flooded Dyn's infrastructure with tens of millions of DNS lookup requests per second. Their authoritative nameservers became unable to respond consistently. Recursive resolvers retried, served cached answers where they still had valid data, or returned resolution failure such as SERVFAIL or timeout when no usable answer could be obtained. NXDOMAIN is different: it means the queried name does not exist, not that an authoritative server stayed silent under attack.
The platforms themselves were fine. Twitter's servers were running. Netflix's servers were running. The routing was fine. The failure was entirely at the DNS naming layer. Without working name resolution, none of the downstream infrastructure mattered.
Twitter, Netflix, Spotify, Reddit, and PayPal all stopped working at the same time. They are unrelated companies with separate infrastructure. What single point connected them all?
NXDOMAIN and SERVFAIL mean different DNS failures
One says the name does not exist. The other says the resolver could not complete the answer safely.
Each DNS error name has a precise meaning. NXDOMAIN is not SERVFAIL is not timeout. Read the RCODE first, then run the test that matches the cause.
10.1 The DNS hierarchy: stub, recursive, and authoritative
DNS (Domain Name System) is a distributed, hierarchical, cached naming system. RFC 9499 is the current DNS terminology reference. Understanding where each role sits is essential for diagnosing DNS failures correctly.
The stub resolver runs on your machine. It is not a full DNS implementation. It takes a question from the application (what is the IP for example.com?), forwards it to a configured recursive resolver, and returns the answer. Most operating systems have a stub resolver built into their networking stack.
The recursive resolver (also called a full-service resolver or caching resolver) does the actual work. It either answers from its cache or walks the DNS hierarchy to find the authoritative answer. ISP resolvers, Google's 8.8.8.8, and Cloudflare's 1.1.1.1 are all recursive resolvers.
Authoritative nameservers hold the final, definitive records for a zone. When you update your domain's A record, you update it at the authoritative server. The recursive resolver fetches the answer from there and caches it for the duration of the TTL (time to live).
“The domain name space is a tree structure.”
RFC 1034 - Section 3.1, Name Space Specifications and Terminology
The hierarchy matters for fault isolation. Root servers direct queries to TLD (top-level domain) servers. TLD servers direct to authoritative servers. Each level can fail independently. When you know which tier failed, you know where to look.
The resolution path for `api.example.com` works like this. The stub resolver asks the recursive resolver. If the recursive resolver has no cache entry, it asks a root server which TLD server handles `.com`. The root server responds. The recursive resolver asks the `.com` TLD server which nameserver handles `example.com`. The TLD server responds. The recursive resolver asks the `example.com` authoritative server for the IP of `api.example.com`. It gets an A record back, caches it for the TTL, and returns it to the stub resolver.
A cold DNS lookup walks authority, then caches the result
The stub asks one recursive resolver. The recursive resolver follows referrals until an authoritative answer can be cached with its TTL.
A cold lookup walks the DNS hierarchy. Each tier refers the resolver to the next; only the authority answers; the recursive resolver caches what it learned.
Each step in the resolution hierarchy can return different types of records. Knowing what each record type does stops you wasting time checking the wrong one.
10.2 DNS record types
DNS records are not just IP address lookups. Each record type has a specific purpose. Confusing them is one of the most common sources of DNS misconfiguration.
A record. Maps a hostname to an IPv4 address. Example: `api.example.com → 93.184.216.34`
AAAA record. Maps a hostname to an IPv6 address. The name comes from IPv6 being four times larger than IPv4.
CNAME (canonical name) record. Creates an alias pointing to another hostname. `www.example.com CNAME example.com` means "look up example.com and use that answer for www.example.com." CNAME chains are valid but add resolution steps and latency.
MX (mail exchanger) record. Specifies the mail server for a domain. Points to a hostname (not an IP), with a priority number. Lower priority numbers are tried first.
NS (nameserver) record. Identifies the authoritative nameservers for a zone. These are the servers the TLD delegate queries to.
SOA (start of authority) record. Contains zone metadata: the primary nameserver, the zone administrator's email address, zone serial number, and timing parameters for secondary nameserver synchronisation.
TXT (text) record. Stores arbitrary text. Used for SPF (Sender Policy Framework) email anti-spoofing, DKIM (DomainKeys Identified Mail) public keys, domain ownership verification, and various application tokens.
SVCB and HTTPS records. RFC 9460 defines service binding records that publish connection information before the client opens a transport connection. For web origins, HTTPS records can advertise alternative endpoints, supported application protocols, and parameters that help clients choose HTTP/3 or encrypted client hello paths.
Record types describe what DNS stores. TTL controls how long each answer survives in the cache, which is the main reason DNS behaviour is so often misunderstood during incidents.
10.3 TTL, caching, and why DNS changes are slow
Every DNS record has a TTL value measured in seconds. When a recursive resolver caches an answer, it keeps it until the TTL expires. This is why a change you made to your DNS record may not be immediately visible to everyone on the internet.
A user whose resolver cached the old A record an hour ago with a 24-hour TTL will continue seeing the old IP for up to 23 more hours. A user whose resolver just looked up the record will get the new one. This is not a bug; it is the design. Caching is what makes DNS scale to billions of queries per day without the authoritative servers handling every single request.
If you are preparing for a DNS migration, reduce the TTL to 300 seconds (five minutes) a day or two before the change. After the change, you can increase it again. This limits how long stale records persist while keeping normal load on the authoritative servers manageable.
"DNS is propagating" usually means "some recursive resolvers are still serving the old TTL." There is no central broadcast. Each resolver serves its cached answer until the TTL expires and fetches fresh data.
DNS uses cache first and TCP when UDP is not enough
A cache hit avoids the hierarchy. A truncated UDP response triggers a TCP retry instead of pretending DNS is UDP-only.
A cache hit answers in milliseconds. A UDP response over 512 bytes (or marked truncated) forces a TCP retry that walks back to the authoritative server.
Caching is a scalability mechanism. The remaining concern is whether the answers cached are trustworthy and whether the queries themselves are visible to observers.
10.4 DNSSEC, DoH, and DoT
DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records. It allows resolvers to verify that a response was actually signed by the zone owner and has not been tampered with in transit. DNSSEC prevents cache poisoning attacks where a malicious actor injects false DNS answers.
DNSSEC does not encrypt DNS traffic. Queries and responses are still visible to network observers. What it adds is integrity: you know the answer came from the real zone and has not been modified.
DNS over HTTPS (DoH), defined in RFC 8484, and DNS over TLS (DoT), defined in RFC 7858, encrypt the DNS exchange. Queries go over an encrypted channel, hiding the question from network intermediaries. DoH uses port 443 and looks like normal HTTPS traffic. DoT uses port 853. Both are increasingly common in modern browsers and operating systems.
“sending DNS queries and getting DNS responses over HTTP”
RFC 8484 - Section 1, Introduction
DoH was standardised in 2018. Its use of port 443 means DNS queries blend into regular HTTPS traffic, making them harder to block or monitor at the network level. This has privacy benefits but complicates traditional network-level DNS filtering.
Common misconception
“DNS is just a phone book.”
DNS is a distributed, hierarchical, cached system with multiple server roles, transport options (UDP, TCP, TLS, HTTPS), security extensions, and record types that do far more than IP lookup. The phone book analogy breaks when you need to explain cache TTLs, recursive vs authoritative roles, DNSSEC validation chains, or why different users see different answers after a DNS change.
Your website works on some ISPs but not others after a DNS change you made two hours ago. What is the most likely cause?
A recursive resolver asks a root server for help resolving api.example.com. What does the root server return?
You set a DNS A record with a TTL of 86400 seconds (24 hours). You then need to change the IP urgently. What happens?
What does DNSSEC add that DNS over TLS (DoT) does not?
Core distinctions
- DNS resolution is a multi-step hierarchy: stub resolver contacts recursive resolver, which walks root, TLD, and authoritative servers, then caches the answer for the TTL.
- Record types have specific purposes: A for IPv4, AAAA for IPv6, CNAME for aliases, MX for mail, NS for nameserver delegation, TXT for text metadata.
- TTL caching means DNS changes propagate unevenly. Reduce TTL before planned changes; increase it afterwards.
- DNSSEC adds integrity (cryptographic signing). DoH and DoT add privacy (encryption of the query). They solve different problems.
Standards and sources cited in this module
RFC 1035, Domain Names: Implementation and Specification
Section 3.2, RR Definitions; Section 4, Messages
Defines the DNS message format, record types (A, CNAME, MX, NS, SOA, TXT), and the wire protocol. The record type descriptions in Section 10.2 reference this specification.
RFC 1034, Domain Concepts and Facilities
Section 3.1, Name Space Specifications; Section 5, Resolvers
Defines the DNS name space hierarchy and resolver roles. Quoted in Section 10.1 to distinguish stub, recursive, and authoritative roles.
RFC 8484, DNS Queries over HTTPS (DoH)
Section 1, Introduction
Defines the DNS over HTTPS protocol. Quoted in Section 10.4 for the DoH definition.
RFC 9499, DNS Terminology (BCP 219)
Throughout
Current authoritative terminology reference for DNS roles and concepts. Referenced for stub resolver and recursive resolver definitions in Section 10.1.
RFC 9460, Service Binding and Parameter Specification via the DNS
SVCB and HTTPS resource records
Defines SVCB and HTTPS records for publishing connection parameters. Referenced in Section 10.2.
Dyn Blog: DDoS Attack Against Dyn Managed DNS
Published October 22, 2016
Post-incident analysis of the Mirai botnet attack on Dyn's DNS infrastructure. Used as the opening case study to demonstrate the impact of authoritative DNS infrastructure failure.
DNS converts names to addresses. Module 11 asks when you should skip TCP entirely: what UDP provides, why real-time applications choose it, and how QUIC rebuilds reliability on top of UDP while solving TCP's head-of-line blocking problem.
Module 10 of 21 · Applied stage