1. What DNS Is and Why It Exists¶

The Domain Name System (DNS) is the distributed, hierarchical naming system that maps human-readable names (www.example.com) to the identifiers machines actually use to communicate — most commonly IPv4/IPv6 addresses, but also mail server locations, service endpoints, cryptographic keys, and arbitrary text data.

Before DNS (pre-1983), the ARPANET used a single flat file, HOSTS.TXT, maintained centrally by the Stanford Research Institute's Network Information Center and distributed to every host on the network. This didn't scale: every new host meant a manual update and a fresh copy pushed everywhere. DNS, defined by Paul Mockapetris in RFC 882 and RFC 883 (later obsoleted by RFC 1034 and RFC 1035), solved this with three ideas that still define the system today:

1. A hierarchical namespace — so name ownership can be delegated instead of centrally managed.
2. Distributed authority — every part of the tree is owned and served by whoever administers that branch.
3. Caching — so the same answer doesn't need to be re-fetched from the authoritative source on every request.

2. The Namespace: A Tree, Read Right to Left¶

DNS names are organized as an inverted tree rooted at an unnamed node written as a trailing dot: www.example.com. The tree is read right to left in terms of authority:

                    . (root)
                    |
        +-----------+-----------+
        |           |           |
       com         org         net        ... (TLDs)
        |
     example
        |
       www

• Root zone — the top of the hierarchy, represented by .. Served by 13 named root server clusters (a.root-servers.net through m.root-servers.net), each of which is actually dozens to hundreds of physically distributed machines using anycast routing.
• Top-Level Domain (TLD) — com, org, net, country-code TLDs like ca or uk, and newer generic TLDs like cloud or dev. Each TLD is operated by a registry (e.g., Verisign runs .com and .net).
• Second-level domain — the part you typically register, e.g. example in example.com.
• Subdomains — any further label to the left, e.g. www, mail, dev.example.com.

Each node in this tree can be a zone — a point where administrative authority is delegated to a different party. This is the critical distinction: a "domain" is a name; a "zone" is a unit of administration. example.com might be one zone containing everything under it, or the owner might delegate dev.example.com to a different DNS provider or team, making it a separate zone with its own authoritative servers.

3. Resource Records: The Actual Data¶

Every zone is a collection of resource records (RRs). Each has the same basic shape:

name    TTL    class    type    data

Example:

www.example.com.   300   IN   A   93.184.216.34

• name — the owner name this record applies to.
• TTL — Time To Live, in seconds; how long resolvers may cache this record.
• class — almost always IN (Internet); other classes (CH, HS) are effectively historical.
• type — what kind of record this is.
• data — type-specific payload.

Common record types¶

The SOA record in detail¶

Every zone has exactly one SOA record, and its fields govern how secondary servers behave:

@   IN   SOA   ns1.example.com. admin.example.com. (
                2024010101   ; Serial
                3600         ; Refresh
                900          ; Retry
                1209600      ; Expire
                3600 )       ; Minimum / negative-cache TTL

• Serial — a version number for the zone. Secondaries compare this to decide whether to transfer a fresh copy. Convention is YYYYMMDDnn, but it just needs to increase monotonically (wraparound rules exist in RFC 1982 for when it doesn't).
• Refresh — how often a secondary checks the primary for a new serial.
• Retry — how long a secondary waits before retrying after a failed refresh.
• Expire — how long a secondary will keep serving stale data if it can't reach the primary before it stops answering entirely.
• Minimum — historically the default TTL; since RFC 2308 it specifically governs how long negative answers (NXDOMAIN) may be cached.

4. Zones vs. Domains vs. Delegation¶

Delegation is what makes DNS distributed rather than centralized. When .com's authoritative servers are asked about example.com, they don't hold the actual records — they hold NS records pointing to example.com's own name servers, plus (often) glue records: A/AAAA records for those name servers, supplied directly in the parent zone so resolvers aren't stuck in a chicken-and-egg problem (glue is required whenever a zone's name servers live inside that same zone, e.g. ns1.example.com being a name server for example.com).

This is why registering a domain and configuring DNS for it are two different things done with two different parties: the registrar records which name servers are authoritative (updating the delegation in the TLD's zone), while whoever runs those name servers controls the actual records.

5. How a Lookup Actually Happens¶

Say a browser needs www.example.com. Two resolution models are involved:

Recursive vs. iterative¶

• A client (a laptop, a phone) makes a recursive query to a recursive resolver — often the ISP's resolver, a corporate resolver, or a public one like 1.1.1.1 or 8.8.8.8. "Recursive" means: give me the final answer, and do whatever work is necessary to get it.
• The recursive resolver then does the legwork using iterative queries — asking one server, getting either an answer or a referral to a more specific server, and following referrals down the tree.

Step by step¶

1. Client asks its configured recursive resolver for www.example.com A.
2. Resolver checks its cache. If it has a fresh (non-expired) answer, it returns it immediately — no network round trip beyond the client.
3. On a cache miss, the resolver asks a root server: "who handles .com?" The root replies with a referral: the NS records (and glue) for the .com TLD servers.
4. Resolver asks a .com TLD server: "who handles example.com?" It replies with a referral to example.com's authoritative name servers.
5. Resolver asks one of those authoritative servers directly for www.example.com A. This server holds the actual zone data and returns an authoritative answer.
6. The resolver caches the answer (per the record's TTL) and returns it to the client.
7. The client's stub resolver (a thin, non-caching piece of OS code, sometimes with a small local cache) hands the address to the application.

In practice this whole chain typically completes in single-digit to low double-digit milliseconds, and subsequent lookups for the same or sibling names are usually served entirely from cache.

Query types worth knowing¶

• QNAME minimization (RFC 7816) — modern resolvers avoid sending the full query name to upstream servers that don't need it (e.g., they ask the root only about .com, not www.example.com), reducing information leakage.
• Negative caching — NXDOMAIN (name doesn't exist) and NODATA (name exists, but not that record type) responses are cached too, governed by the SOA minimum/negative-TTL field, to avoid repeatedly querying for names that don't exist.

6. Caching and TTLs¶

Caching is what makes DNS viable at internet scale — without it, every single web request would require a round trip to authoritative servers on the other side of the world. TTLs are a deliberate trade-off:

• Long TTL (hours to days): fewer lookups, less load on authoritative servers, but slower propagation of changes.
• Short TTL (seconds to a few minutes): fast propagation, useful before planned changes or for failover/load-balancing use cases, but more query volume and load.

A common operational pattern: lower the TTL well in advance of a planned change (so caches expire the old value quickly), make the change, then raise the TTL back once it's stable. Note that lowering a TTL only helps if it's done before caches have already cached the record at the old, longer TTL — you can't retroactively shrink an already-cached record's remaining lifetime.

Caching happens at multiple layers simultaneously: OS-level stub resolver caches, browser-level caches, the recursive resolver, and sometimes intermediate forwarders — which is why DNS changes can appear to "propagate" unevenly across different networks and devices even well past a TTL's expiry.

7. Authoritative vs. Recursive Servers¶

These two roles are conceptually and often physically distinct, and conflating them is a common source of confusion:

• Authoritative name servers hold the actual zone data for specific domains and answer only for those zones. They do not perform recursion for arbitrary names on behalf of the public — a well-run authoritative server has recursion disabled entirely.
• Recursive resolvers hold no zone data of their own (beyond cache). Their job is to chase referrals down the tree on behalf of clients.

Running one server as both (common in small/home setups, and shown in the accompanying BIND notes) works, but at internet scale doing so is a security and operational anti-pattern — it enables cache poisoning and DNS amplification attacks, discussed next.

8. Security Considerations¶

Cache poisoning / spoofing¶

Since classic DNS runs over UDP with no built-in authentication, an attacker who can guess or intercept a query's transaction ID and source port can inject a forged response before the real authoritative answer arrives, poisoning a resolver's cache. Mitigations include randomized source ports and query IDs (0x20 encoding randomizes the query name's letter case as an extra entropy source), and ultimately DNSSEC.

DNSSEC¶

DNSSEC adds cryptographic signatures to DNS responses so resolvers can verify data hasn't been tampered with in transit, without encrypting it (DNSSEC provides authenticity and integrity, not confidentiality).

• DNSKEY — public keys published in a zone.
• RRSIG — a signature over a record set, made with the zone's private key.
• DS — a hash of a child zone's DNSKEY, published in the parent zone, forming a chain of trust from the root down.
• NSEC/NSEC3 — used to authenticate the non-existence of a record (proving a name doesn't exist, without a signable "nothing" record) — NSEC3 adds hashing to prevent trivial zone enumeration.

Validation walks this chain: a resolver trusts the root's key (the trust anchor, distributed out-of-band and periodically rolled), verifies the root's signature over the TLD's DS record, verifies the TLD's signature over the next DS record, and so on down to the record being requested.

Amplification and reflection attacks¶

Because DNS responses can be much larger than the queries that generate them (especially with EDNS0 and DNSSEC records), and because it runs over connectionless UDP where source addresses are easy to spoof, DNS is a common vector for reflection/amplification DDoS: an attacker spoofs a victim's IP as the query source, and open resolvers flood the victim with oversized responses. This is precisely why authoritative-only servers should refuse recursion, and why recursive resolvers should restrict who's allowed to query them (an "open resolver" answering the entire internet is considered a misconfiguration).

Transaction security: TSIG¶

TSIG (Transaction SIGnature) uses a shared secret key to authenticate specific transactions — most commonly zone transfers and dynamic updates — independent of DNSSEC, which secures record data itself rather than the transaction.

Encrypted transport: DoT and DoH¶

Traditional DNS queries between a client and its resolver travel in cleartext, visible to anyone on-path. Two newer transports address this:

• DNS over TLS (DoT), RFC 7858 — DNS wrapped in TLS on a dedicated port (853).
• DNS over HTTPS (DoH), RFC 8484 — DNS queries sent as HTTPS requests, often on port 443, which also makes DNS traffic harder to distinguish/block from ordinary web traffic.

Both protect the client-to-resolver leg from eavesdropping and tampering; neither by itself replaces DNSSEC's guarantee about the authoritative data's authenticity, since the resolver itself must still be trusted (or perform validation).

9. Zone Transfers and Redundancy¶

Every zone should have more than one authoritative server for redundancy — DNS's own design assumes this (multiple NS records, geographically and topologically separated). The mechanism for keeping secondaries in sync with the primary is a zone transfer:

• AXFR — a full zone transfer, copying every record.
• IXFR — an incremental transfer, sending only the changes since the secondary's last known serial number.

Secondaries periodically poll the primary's SOA record (per the Refresh interval) and pull a transfer when the serial has advanced. Zone transfers should be restricted (via ACLs and ideally TSIG) to known secondary servers — an open AXFR to the world hands out a full inventory of a domain's infrastructure to anyone who asks.

10. Dynamic DNS¶

Static zone files work for infrastructure that rarely changes. Environments with frequent changes (DHCP-assigned hosts registering their own names, ACME-based certificate validation via TXT records, clustered services) instead use Dynamic DNS Update (RFC 2136): a client sends an authenticated update message directly to the authoritative server, which applies it and bumps the SOA serial, without an administrator hand-editing a zone file. This is what an allow-update clause in a BIND zone controls.

11. Split-Horizon / Split-View DNS¶

It's common for internal clients and external (internet) clients to need different answers for the same name — e.g., an internal client resolving app.example.com to a private RFC 1918 address on the LAN, while external clients get a public address. This is called split-horizon (or split-view) DNS, implemented either as entirely separate authoritative servers for internal vs. external audiences, or via a single server matching the querying client's source address to different "views," each with its own zone data.

12. Practical Tools¶

• dig — the standard modern query tool, e.g. dig www.example.com A, dig +trace example.com (walks the full delegation chain from root down, useful for debugging delegation problems), dig -x 93.184.216.34 (reverse lookup).
• nslookup — older, still common, more limited and considered semi-deprecated in favor of dig.
• host — a terse, script-friendly lookup tool.
• whois — not DNS itself, but adjacent: queries registry/registrar data about domain ownership and delegation.

13. Glossary¶

• Zone — a unit of administrative authority in the DNS tree.
• FQDN — Fully Qualified Domain Name, a name specified completely from the root (technically ending in a trailing dot, though it's usually omitted in casual use).
• Glue record — an A/AAAA record supplied by a parent zone for a delegated name server whose own name falls inside the zone it serves.
• Stub resolver — the minimal, non-caching (or barely-caching) resolver built into an OS's networking stack, which forwards all real work to a recursive resolver.
• Forwarder — a resolver configured to pass queries it can't answer from cache to another specific resolver, rather than performing iterative resolution itself.
• Anycast — routing the same IP address to the topologically nearest of many physical servers, used heavily by root and TLD server operators for both performance and DDoS resilience.