DNS — The Internet's Distributed Phone Book
The Internet works the same way. Computers communicate using IP addresses (e.g. 142.250.80.46) — but humans remember names (google.com). DNS bridges this gap: a globally distributed database that translates human-readable domain names into machine-usable IP addresses.
What makes DNS remarkable is its scale: it handles over 1 trillion queries per day, responds in milliseconds anywhere on Earth, has no single point of failure, and has run continuously since 1983 — making it arguably the most reliable piece of infrastructure on the entire Internet.
DNS (Domain Name System) was designed by Paul Mockapetris in 1983 (RFC 882, 883, later replaced by RFC 1034/1035). Before DNS, every host on the Internet had to download a single text file called HOSTS.TXT from a server at SRI International — listing every known hostname and IP address. When the Internet grew from hundreds to thousands of hosts, this system collapsed. DNS replaced it with a distributed, hierarchical, delegated database that scales to billions of records.
Distributed — no single server holds all DNS data. The data is
spread across millions of servers worldwide. No one server can fail and take DNS down.
Hierarchical — DNS is a tree structure: root → TLD (.com, .uk) →
domain (google, bbc) → subdomain (www, mail). Each level delegates authority
to the level below it.
Delegated — each organisation controls its own portion of the
namespace. Google controls google.com. The BBC controls bbc.co.uk. IANA controls
the root. No central authority approves individual records.
🏭 Animated: The DNS Hierarchy — Root, TLD, and Authoritative
The DNS namespace is a tree with a single root — represented by a dot (.).
Every domain name, read right to left, traces a path from leaf to root through this tree.
www.bbc.co.uk. reads: host "www" in domain "bbc" in second-level "co"
in top-level "uk" under the root "."
💡 The trailing dot (www.example.com.) represents the root and is always present — most software omits it for readability. When you type "google.com" your resolver appends the dot internally before querying.
DNS Server Types — Four Different Roles
Not all DNS servers do the same job. There are four distinct server roles in the DNS ecosystem, each with a specific responsibility. Confusing them is the most common source of DNS configuration errors.
Authoritative vs Non-Authoritative Answers — The Critical Distinction
Every DNS response carries a single bit — the AA flag (Authoritative Answer) — that tells the client whether the answer came directly from the server that owns the zone, or from a resolver that merely cached it. This distinction is one of the most important concepts in DNS and is frequently misunderstood.
Option A: The author herself — she knows definitively. Her answer is authoritative. It cannot be wrong.
Option B: A librarian who looked it up last month and remembers — probably correct, but she might be remembering wrong, or the information might have changed. Her answer is non-authoritative.
In DNS: the authoritative server is the author — it holds the zone file and its answers are definitive. The recursive resolver is the librarian — it caches answers and serves them from memory, which may be stale if the TTL has not expired yet. Both can give you the correct answer most of the time, but only one is guaranteed to be right at this exact moment.
The AA Bit — One Flag, Two Worlds
| Property | Detail |
|---|---|
| Source | The zone's own name server (ns1.example.com) |
| AA flag | Set to 1 in the DNS response header |
| Data freshness | Always current — read directly from zone file |
| TTL meaning | TTL instructs the receiver how long to cache |
| Trust level | Highest — this is the ground truth |
| Who returns it | Only the primary or secondary authoritative servers |
| nslookup label | (no "Non-authoritative" label shown) |
| Example | Querying ns1.google.com for google.com A records directly |
When you query the authoritative server directly with dig google.com @ns1.google.com, you see flags: qr aa rd — the AA bit is set, confirming you got the real answer from the source.
| Property | Detail |
|---|---|
| Source | A recursive resolver's cache (8.8.8.8, 1.1.1.1) |
| AA flag | Set to 0 in the DNS response header |
| Data freshness | Potentially stale — age depends on remaining TTL |
| TTL meaning | Remaining TTL — how long ago this was cached |
| Trust level | High in practice, but not guaranteed current |
| Who returns it | Any recursive resolver (your ISP, 8.8.8.8, etc.) |
| nslookup label | "Non-authoritative answer:" printed as a warning |
| Example | Querying 8.8.8.8 for any domain — always non-auth |
Non-authoritative answers are the norm for everyday usage — 99.9% of DNS queries go to a resolver cache. This is correct and expected behaviour, not an error. nslookup's "Non-authoritative answer" label alarms beginners but is completely normal.
🏭 Animated: AA Flag Comparison — Authoritative vs Cached Response
💡 Notice the TTL difference: the authoritative server always returns the full TTL (e.g. 3600s). The resolver returns a decremented TTL — if it cached the record 2000 seconds ago, it returns 1600s remaining. This tells you exactly how old the cached answer is.
The DNS Response Header — Flags Decoded
When Does Non-Authoritative Become a Problem?
dig example.com @ns1.example.com. If the authoritative server returns the new value (AA=1) but your ISP's resolver still returns the old value (AA=0) — the change is correct, just cached at the resolver.
In dig output:
flags: qr aa rd → Authoritative (AA bit present)
flags: qr rd ra → Non-Authoritative (no AA bit, RA=1 means from resolver)
In nslookup output:
No label → Authoritative answer
Non-authoritative answer: → Came from resolver cache
In dig TTL:
TTL = exactly the configured value (e.g. 3600) → Fresh from authoritative
TTL = odd number (e.g. 2847) → Cached at resolver (decremented since caching)
🏭 Animated: Full DNS Resolution — Every Packet
The animation below shows the complete DNS resolution process for
www.example.com — from the client's first query to the final answer,
including every server contacted, every response type, and the caching behaviour.
💡 Steps 1–2 show a cache hit (answer found locally — <1ms). Steps 3–10 show a full recursive lookup with 4 server interactions. Real-world resolution time: 20–200ms on first query, <1ms on cache hit. The average web page triggers 8–15 DNS lookups on first load.
DNS Zones — Forward, Reverse, and Zone Files
A DNS zone is a portion of the DNS namespace that a specific administrator controls. Zones are stored in zone files — plain text files containing DNS resource records. Understanding zones is the key to running your own DNS server.
Translates domain names → IP addresses. The "normal" direction. Filename convention: db.example.com
; Forward zone file for example.com
; $ORIGIN sets the default domain suffix
$ORIGIN example.com.
$TTL 3600 ; Default 1-hour TTL
; SOA — Start of Authority record
@ IN SOA ns1.example.com. admin.example.com. (
2024070101 ; Serial (YYYYMMDDNN)
3600 ; Refresh (1h)
900 ; Retry (15min)
604800 ; Expire (1 week)
300 ) ; Negative TTL
; NS records — authoritative name servers
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.
; A records — IPv4 addresses
@ IN A 93.184.216.34 ; example.com itself
www IN A 93.184.216.34 ; www.example.com
mail IN A 93.184.216.35 ; mail.example.com
ns1 IN A 93.184.216.36
ns2 IN A 93.184.216.37
; AAAA — IPv6 address
www IN AAAA 2606:2800:220:1:248:1893:25c8:1946
; CNAME — alias (ftp → www)
ftp IN CNAME www
; MX — mail exchange, priority 10
@ IN MX 10 mail.example.com.
; TXT — SPF record
@ IN TXT "v=spf1 mx a ~all"Translates IP addresses → domain names (PTR records). Used for email anti-spam, logging, and security audits. Filename: db.216.184.93 (reversed octets)
; Reverse zone for 93.184.216.0/24
; Zone name: 216.184.93.in-addr.arpa.
$ORIGIN 216.184.93.in-addr.arpa.
$TTL 3600
@ IN SOA ns1.example.com. admin.example.com. (
2024070101 ; Serial
3600 ; Refresh
900 ; Retry
604800 ; Expire
300 ) ; Negative TTL
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.
; PTR records — IP last octet → hostname
; 93.184.216.34 → www.example.com
34 IN PTR www.example.com.
35 IN PTR mail.example.com.
36 IN PTR ns1.example.com.
37 IN PTR ns2.example.com.
; Why "in-addr.arpa"?
; IP octets are reversed: 93.184.216.34
; becomes 34.216.184.93.in-addr.arpa.
; This lets DNS tree work right-to-left
; just like forward lookups.
The Start of Authority (SOA) record is the most important record
in any zone file. It defines:
MNAME — primary name server for this zone
RNAME — email of zone administrator (@ replaced by .)
Serial — version number. Secondary servers transfer the zone when
this increases. Convention: YYYYMMDDNN (e.g. 2024070101)
Refresh — how often secondaries check for updates
Retry — how often to retry if refresh fails
Expire — how long secondaries serve stale data if primary is unreachable
Minimum TTL — negative cache TTL (how long NXDOMAIN is cached)
nslookup & dig — DNS Query Tools
Every network engineer needs to query DNS manually. Two tools are essential:
nslookup (available on Windows, macOS, and Linux) and
dig (more powerful, primarily Linux/macOS). Both send DNS queries
and display the raw response — invaluable for troubleshooting.
🏭 Animated: nslookup & dig Query Examples
💡 dig shows the full DNS response including flags, authority section, and query time — far more useful than nslookup for debugging. The +short flag gives a minimal one-line answer. The @server syntax lets you query a specific DNS server directly, bypassing your default resolver.
Essential dig & nslookup Commands Reference
| Command | What It Does |
|---|---|
dig example.com | Default A record lookup for example.com |
dig example.com MX | Query Mail Exchange records |
dig example.com NS | Query Name Server records (who is authoritative) |
dig example.com TXT | Query TXT records (SPF, DKIM, verification) |
dig example.com ANY | Request all record types (many resolvers block this) |
dig -x 8.8.8.8 | Reverse lookup: IP → hostname (PTR record) |
dig example.com +short | Minimal output — just the answer |
dig example.com @1.1.1.1 | Query specific resolver (1.1.1.1 = Cloudflare) |
dig example.com +trace | Trace full delegation from root to answer |
dig example.com +dnssec | Request DNSSEC signatures in response |
nslookup example.com | Basic A lookup (Windows-friendly) |
nslookup -type=MX example.com | Specify record type in nslookup |
nslookup example.com 8.8.8.8 | Query specific server with nslookup |
Build Your Own DNS Server — BIND9 on Linux
BIND (Berkeley Internet Name Domain) is the world's most widely deployed DNS server software — powering a majority of DNS servers on the Internet. Setting up your own BIND9 authoritative server gives complete control over your domain's DNS records and teaches the inner workings of the protocol.
Two public IP addresses — ICANN requires at least two authoritative
name servers in different locations for any domain.
A registered domain name — purchased from a registrar (Namecheap,
GoDaddy, Cloudflare).
Firewall rules — open UDP/TCP port 53 from anywhere.
Reverse DNS — contact your hosting provider to set PTR records for
your server IPs (required for email deliverability).
Step-by-Step: BIND9 Authoritative Server Setup
/etc/bind/named.conf.options to set your server's behaviour: allow-query (who can query), recursion (only for internal use on authoritative servers), listen-on (which interfaces), and forwarders (for internal caching resolver)./etc/bind/db.example.com) and reverse zone file (/etc/bind/db.93.184.216) using the format shown in Section 05. Every change requires incrementing the SOA serial number.named-checkconf checks named.conf syntax. named-checkzone example.com /etc/bind/db.example.com checks zone file syntax. A syntax error in a zone file stops the entire BIND9 process — validate every time.── Step 1: Install BIND9 ─────────────────────────────────────────
$ sudo apt update && sudo apt install -y bind9 bind9utils
$ sudo systemctl status bind9 # Verify running
$ sudo systemctl enable bind9 # Start on boot
── Step 2: /etc/bind/named.conf.options ──────────────────────────
options {
directory "/var/cache/bind";
recursion no; // Authoritative only — disable recursion
allow-query { any; }; // Accept queries from anywhere
allow-transfer { none; }; // Restrict zone transfers
listen-on { any; }; // Listen on all interfaces
dnssec-validation auto; // Validate DNSSEC responses
auth-nxdomain no; // RFC 2308 compliant
};
── Step 3: /etc/bind/named.conf.local ────────────────────────────
// Forward zone
zone "example.com" {
type primary;
file "/etc/bind/zones/db.example.com";
allow-transfer { 93.184.216.37; }; // Allow transfer to ns2
notify yes;
};
// Reverse zone (for 93.184.216.0/24)
zone "216.184.93.in-addr.arpa" {
type primary;
file "/etc/bind/zones/db.93.184.216";
};
── Step 4: Create zone directory ─────────────────────────────────
$ sudo mkdir -p /etc/bind/zones
# Copy zone files as shown in Section 05
── Step 5: Validate and apply ────────────────────────────────────
$ sudo named-checkconf # Check named.conf syntax
$ sudo named-checkzone example.com /etc/bind/zones/db.example.com
$ sudo systemctl reload bind9 # Apply changes
── Step 6: Test your server ──────────────────────────────────────
$ dig www.example.com @localhost # Query your own server
$ dig -x 93.184.216.34 @localhost # Test reverse lookup
$ dig example.com SOA @localhost # Verify SOA recordDNSSEC, DoH, DoT — Making DNS Secure
Classic DNS was designed in 1983 with no security — all responses are unsigned UDP packets that anyone can forge. Three major security extensions address this.
dnssec-keygen and dnssec-signzone in BIND9.
systemd-resolved
with DNS=1.1.1.1 and DNSOverTLS=yes.
Dan Kaminsky discovered a fundamental flaw in DNS: an attacker could forge UDP responses and inject false records into any resolver's cache — redirecting entire domains to attacker-controlled servers. By flooding the resolver with fake responses on thousands of source ports simultaneously (birthday attack), the attacker could win the race against the legitimate response. The flaw affected every DNS resolver in the world. An emergency coordinated patch was released in July 2008 — the largest coordinated security patch in Internet history. The fix: source port randomisation. The permanent fix: DNSSEC. Source: Kaminsky, "It's the End of the Cache as We Know It," Black Hat 2008; CERT Advisory CA-2008-06.
Real-World DNS Incidents
Golden Rules — DNS Administration & Troubleshooting
named-checkzone before reloading BIND9.
A single misplaced character in a zone file crashes BIND9 and takes down all
your zones — not just the one with the error. named-checkzone
catches syntax errors before they reach production. Automate this in your
deployment pipeline: no reload without a passing check.
recursion no; in named.conf.options on all
authoritative servers exposed to the Internet.
dig +trace to diagnose resolution failures, not ping.
When a domain is unreachable, ping example.com tells you almost nothing
about DNS. dig example.com +trace shows you every step of the delegation
chain — exactly which server is failing, what response it returns, and whether
the problem is at root, TLD, or authoritative level. This is the single most
powerful DNS troubleshooting command.
allow-transfer { ns2_ip; };
in your zone configuration. Leaving AXFR open to any IP exposes your entire
internal network map to attackers — a common reconnaissance technique in penetration testing.
DNS is the infrastructure beneath all Internet infrastructure. Every web request,
every email, every API call starts with a DNS lookup. Understanding it end-to-end
— from the root zone to a zone file entry, from a recursive resolution to a
cached response, from dig +trace to named-checkzone
— is foundational knowledge for any network engineer, system administrator,
or security professional.
The hierarchy (root → TLD → SLD → host) is the architecture of the entire
Internet namespace. The delegation model (NS records pointing to authoritative servers)
is what makes it scalable to billions of domains with no central bottleneck.
The TTL mechanism is what makes it performant — 1 trillion queries per day served
mostly from cache, with a tiny fraction touching the actual authoritative servers.
When DNS breaks — as Dyn's 2016 outage proved — nothing works. When DNS is
compromised — as the Kaminsky attack demonstrated — nothing is safe. Mastering
DNS is not optional for anyone who works with networked systems.