COMP347 (Revision 10) | TrustOpen University
Upon completion of this expanded tutorial, students will be able to:
The Domain Name System (DNS) is a critical Internet infrastructure component, translating human‑readable domain names into IP addresses. This tutorial provides a rigorous, university‑level examination of DNS, starting from its distributed, hierarchical architecture and moving through the details of resolution, message formats, and caching.
We analyse the operational aspects of root servers, including the use of anycast for global resilience. We dissect DNS message headers and the wire format, explaining compression pointers and EDNS0 extensions. A significant focus is placed on security: the Kaminsky attack, cache poisoning, and the countermeasures that have evolved, including source port randomisation and 0x20 encoding. Finally, we explore DNSSEC's chain of trust and the modern encrypted transports—DoH and DoT—that address privacy concerns.
The DNS namespace is a tree, with the root zone (`.`) at the top. Below are Top‑Level Domains (TLDs): generic (gTLDs like `.com`, `.org`) and country‑code (ccTLDs like `.uk`, `.jp`). Below TLDs are second‑level domains (e.g., `example.com`), and subdomains below them.
Each zone is administered by a registrar or organisation. The parent zone delegates authority to the child zone by placing NS records in the parent zone. The child zone's authoritative servers are responsible for providing answers for that zone.
There are 13 logical root servers, named A through M. They are operated by various organisations (VeriSign, USC‑ISI, Cogent, etc.). Anycast is used for all root servers: a single IP address is advertised from many geographically distributed locations. BGP routing directs a query to the closest (topologically) instance, providing low latency and resilience against DDoS attacks.
A, AAAA, CNAME, MX, NS, SOA, PTR, TXT, SRV, CAA.
The Start of Authority (SOA) record is essential for zone maintenance:
The resolver (usually a local DNS server) takes full responsibility for answering the query. It contacts root, TLD, and authoritative servers iteratively on behalf of the client. This is the default for stub resolvers (client OS).
The resolver returns the best answer it has, or a referral to the next server. Used between servers (e.g., root → TLD).
To reduce message size, domain names are compressed using pointers (2‑byte offset) to previous occurrences in the same message.
EDNS0 extends DNS over UDP beyond the 512‑byte limit. It allows:
EDNS0 is essential for DNSSEC, as signatures increase response size. If a response exceeds the UDP buffer size, the TC bit is set, and the client retries over TCP.
Recursive resolvers cache responses (positive and negative) to reduce latency and load on authoritative servers. The TTL determines how long a record is cached. Negative caching (NXDOMAIN) uses the SOA Minimum TTL (or a separate `min‑ttl` in modern servers).
The Kaminsky attack (2008) allowed an attacker to poison a resolver's cache without seeing the query ID. The attacker sends a flood of responses with different query IDs and spoofed IPs, guessing the ID and the source port. If a matching response arrives before the legitimate one, the cache is poisoned with a malicious NS record.
Mitigations:
| Attack | Description | Mitigation |
|---|---|---|
| Cache poisoning | Insert malicious records into resolver cache | Source port randomisation, DNSSEC |
| DDoS (reflection) | Amplification using large responses (e.g., ANY query) | Rate limiting, response rate limiting (RRL), remove ANY queries |
| Domain hijacking | Unauthorised changes to domain registration | Registrar locks, two‑factor authentication |
| NXDOMAIN attacks | Flood with non‑existent names, overloading resolver | Negative caching, rate limiting |
Authoritative servers implement RRL to prevent their resources from being used in amplification attacks. RRL limits the number of identical responses sent to a client per second.
Q1: How many logical root servers are there, and what technique is used to distribute them globally?
13 logical root servers; they use Anycast (the same IP is advertised from many locations).
Q2: What is the purpose of the SOA serial number in a zone file?
It indicates the zone version; secondary servers check it to detect changes and trigger a zone transfer.
Q3: In the DNS header, what does the TC flag indicate?
Truncated — the response was too large for UDP; the client should retry over TCP.
Q4: What is the primary goal of the Kaminsky attack?
To poison a resolver's cache by injecting a fake NS record for a domain, redirecting queries to a malicious server.
Q5: What are two mitigations for the Kaminsky attack?
Source port randomisation and 0x20 encoding (randomising case in queries).
Q6: What is the role of a DS record in DNSSEC?
It is placed in the parent zone and contains a hash of a child zone's DNSKEY, establishing the chain of trust.
Q7: How does EDNS0 help DNS?
It extends the UDP payload size beyond 512 bytes, enabling DNSSEC and other large responses without TCP fallback.
Q8: What is the difference between DNS over TLS (DoT) and DNS over HTTPS (DoH)?
DoT uses a dedicated port (853) and TLS; DoH uses port 443 with HTTPS framing. DoH is harder to block but can be more complex and may centralise DNS traffic.
Q9: What is the purpose of NSEC3 in DNSSEC?
It proves non‑existence of a name (NXDOMAIN) while preventing zone enumeration by hashing the names.
Q10: Why do root servers use anycast?
To reduce latency (clients reach the nearest instance) and improve resilience (DDoS attacks are absorbed by the anycast network).
Q11: What is DNS Response Rate Limiting (RRL)?
A feature on authoritative servers that limits the rate of identical responses to prevent their use in amplification attacks.
Q12: What is the difference between a stub resolver and a full recursive resolver?
A stub resolver sends recursive queries to a configured resolver; a full resolver performs iterative resolution itself, contacting root, TLD, and authoritative servers.
Exercise 1 – Zone File Interpretation
Interpret the following SOA record: `example.com. 3600 IN SOA ns1.example.com. admin.example.com. ( 2024052301 7200 1800 604800 3600 )`.
Serial=2024052301; Refresh=7200s (2h); Retry=1800s (30min); Expire=604800s (7 days); Negative TTL=3600s (1h).
Exercise 2 – DNS Query Analysis
Trace the iterative resolution for `www.example.com`, listing the queries and referrals.
(1) Query root for `.com` → referral to .com TLD. (2) Query .com TLD for `example.com` → referral to `example.com` authoritative. (3) Query authoritative for `www.example.com` → returns A record.
Exercise 3 – Cache Poisoning Attack Scenario
Explain how the Kaminsky attack works and why source port randomisation helps.
The attacker sends many spoofed responses with different transaction IDs to guess the correct ID and source port. Randomising the source port increases the search space (16-bit ID × 16-bit port = 2^32 possibilities), making the attack impractical.
Exercise 4 – DNSSEC Validation
Describe the steps a resolver takes to validate an A record using DNSSEC.
(1) Obtain the A record and its RRSIG. (2) Obtain the DNSKEY for the zone. (3) Verify the RRSIG using the DNSKEY. (4) Obtain the DS record from the parent zone to validate the DNSKEY (chain of trust). (5) Repeat recursively up to the root.
Exercise 5 – EDNS0 and TCP Fallback
Why might a DNS response be truncated (TC=1)? How does the client handle it?
The response exceeds the UDP buffer size (either 512 or the EDNS0 advertised size). The client retries the query over TCP (port 53), which has no size limit for messages.
Exercise 6 – DoH vs DoT Decision
A corporate network wants to prevent DNS leaks and protect user privacy. Compare DoH and DoT for this environment.
DoT is easier to implement on the network level (port 853), but it can be blocked. DoH uses port 443, making it harder to block, but it also bypasses corporate DNS filtering. For a corporate environment, DoT with a dedicated internal resolver is often preferred for centralised logging and policy enforcement.
Homework 1 – DNS Root Server Anycast Research
Research the anycast deployment for a specific root server letter (e.g., K‑root). Write a report on the number of instances, geographic coverage, and BGP routing policies.
Consult the root server operator's website (e.g., RIPE for K‑root).
Homework 2 – DNSSEC Deployment Plan
Create a step‑by‑step plan for enabling DNSSEC for a domain. Include key generation, zone signing, DS record submission, and testing tools (dig +dnssec, delv).
Use a test domain first; mention the registrar's DS submission process.
Homework 3 – Performance Analysis of DoH
Measure and compare the latency of DoH (e.g., Cloudflare 1.1.1.1) vs plain UDP DNS (8.8.8.8) under different network conditions. Discuss the overhead of TLS.
Use `dig` with `+https` or a DoH client; document RTT differences.
Homework 4 – DNS Reflection DDoS Mitigation
Design a mitigation strategy for a DNS reflection attack targeting your authoritative server. Include RRL, anycast, and possibly third‑party DDoS protection.
Discuss rate limiting, blacklisting, and using a CDN with DNS‑specific DDoS protection.
Homework 5 – DNS Query Performance Tuning
Optimise the DNS resolution time for a web application. Consider caching, TTL tuning, pre‑resolving, and using a local resolver vs a public one.
Use `dig` to measure times; adjust TTLs based on update frequency; implement a local caching resolver (e.g., `dnsmasq`, `unbound`).
This expanded tutorial has provided a comprehensive, technical examination of DNS. Key takeaways:
Understanding DNS is fundamental for network operations, security, and application performance.