DNS What and HowTo –

The Domain Name System (DNS) translates human-readable names like www.example.com into the IP addresses computers use to connect, such as 93.184.215.14 or 2606:2800:21f:cb07:6820:80da:af6b:8b2c. It is often called the phone book of the internet.

DNS is a distributed, hierarchical database. No single server holds every name; instead, responsibility is delegated down a tree of zones, and answers are cached widely so most lookups finish in milliseconds.

Almost every network action starts with DNS: loading a web page, sending email, calling an API, or joining a Windows domain. When DNS fails, services look “down” even when the servers behind them are healthy.

Key facts at a glance:

• Protocol: defined in RFC 1034 and RFC 1035 (1987).
• Transport: UDP port 53 for most queries; TCP port 53 for large responses and zone transfers; port 853 for DNS over TLS; port 443 for DNS over HTTPS.
• Data unit: the resource record (RR), e.g. an A record mapping a name to an IPv4 address.
• Freshness: every record carries a TTL (time to live) in seconds that controls how long it may be cached.

The DNS hierarchy

DNS names are read right to left, from the most general label to the most specific. www.example.com. is really four levels: the root (the invisible trailing dot), the top-level domain com, the second-level domain example, and the host www.

DNS namespace hierarchy · root, TLDs, zones, hosts

Each box only knows its own names plus who is responsible for the level below, which is how DNS scales to hundreds of millions of domains.

• Root servers know only which servers run each TLD. There are 13 named identities (a.root-servers.net to m.root-servers.net), run by 12 organizations and served from well over a thousand anycast sites worldwide.
• TLD servers know which name servers are authoritative for each domain registered under them. TLDs include generic ones (.com, .org, .net), country codes (.uk, .de, .jp) and newer brand or topic TLDs (.app, .dev).
• Authoritative servers for a zone such as example.com hold the actual records: A, MX, TXT and so on.

Labels can be up to 63 characters each, and a full name up to 253 characters. Names are case-insensitive.

How a lookup works

A full lookup takes eight messages, but your device sends only one; the recursive resolver does the walking and caches every step.

DNS resolution flow · 8 messages, 4 servers

1. You type www.example.com. The browser and OS check their own caches and the hosts file. On a miss, the stub resolver sends a recursive query to the configured resolver.
2. Resolver asks a root server. If it has nothing cached, it starts at one of the root servers, whose addresses ship with it in a root hints file.
3. Root replies with a referral listing the name servers for .com, not the final answer.
4. Resolver asks a .com TLD server.
5. TLD replies with a referral to the authoritative name servers for example.com (e.g. ns1.example.com), plus glue IPs if needed.
6. Resolver asks the authoritative server.
7. Authoritative server answers with the A record, 203.0.113.10, and its TTL.
8. Resolver returns the answer to your device and caches every record it learned along the way, so the next lookup for any .com name skips steps 2 and 3.

In practice most lookups are answered from cache in under 10 ms; a cold lookup through all levels typically takes 50 to 200 ms.

Server roles

Four roles do the work in every lookup; one machine can play more than one.

Recursive vs iterative queries. A recursive query says “give me the final answer”; the stub sends this to its resolver. An iterative query says “give me the best you know”; the resolver sends these to root, TLD and authoritative servers, which reply with either the answer or a referral to the next server down.

Primary and secondary. Authoritative servers come in sets: the primary holds the editable copy of a zone, and secondaries hold read-only copies kept in sync by zone transfer. Registrars require at least two name servers per domain for redundancy.

Record types

Each resource record has five parts: name, TTL, class (almost always IN), type, and data. These are the types you will meet most often.

Apex aliases. A CNAME is not allowed at the bare domain (example.com) because the apex must also hold SOA and NS records. Providers work around this with proprietary ALIAS, ANAME or CNAME-flattening records that resolve the target and return A/AAAA answers.

Trailing dots matter. In zone files a name ending in . is fully qualified; without it, the zone origin is appended, so mail.example.com inside example.com becomes mail.example.com.example.com.

Caching and TTL

Caching is why DNS is fast, and TTL is why changes are not instant: a record can be served from cache for up to its TTL after you change it.

DNS cache layers · browser, OS, resolver, authoritative

The TTL is a countdown in seconds set by the zone owner. A resolver that caches a record with TTL 3600 serves it for up to an hour without asking again, decrementing the TTL it hands to clients. So-called DNS propagation is simply these caches expiring one by one.

Negative caching. A “does not exist” answer (NXDOMAIN) is cached too, for the lower of the SOA minimum field and the SOA record TTL. Creating a record right after someone looked it up can leave them seeing NXDOMAIN until that timer ends.

Trade-off. Short TTLs make changes take effect fast but send more queries to your authoritative servers and add latency on misses. Long TTLs are cheaper and more resilient if your DNS provider has an outage, because resolvers keep serving cached answers.

Zones, delegation and zone transfers

A zone is the slice of the namespace one set of authoritative servers is responsible for. A domain and a zone are not the same: example.com can be one zone, or it can delegate eu.example.com to a separate zone run by another team.

Delegation happens when the parent zone publishes NS records for the child. If the child’s name servers live inside the child itself (e.g. ns1.example.com for example.com), the parent also publishes their A/AAAA records, called glue, so resolvers can reach them without a circular lookup.

The SOA record controls how secondaries stay in sync:

Zone transfers copy zone data from primary to secondaries. AXFR sends the whole zone; IXFR sends only the changes since a given serial. NOTIFY messages let the primary push an immediate “check now” instead of waiting for Refresh. Restrict transfers to known secondary IPs (or TSIG keys): an open AXFR hands an attacker your entire host inventory.

Split-horizon DNS serves different answers to internal and external clients for the same name, e.g. a private IP for intranet.example.com inside the office and nothing outside.

DNS security

Classic DNS is unauthenticated and unencrypted, so anyone on the path can read queries and a forged reply can redirect users. These are the main threats and their defences.

DNSSEC adds digital signatures, not encryption. Each zone signs its records (RRSIG) with keys published as DNSKEY records; the parent publishes a DS hash of the child’s key, forming a chain of trust up to the root key. A validating resolver that finds a broken chain returns SERVFAIL rather than a possibly forged answer. The most common self-inflicted outage is a stale DS record at the registrar after a key rollover or a provider move.

Encrypted transports protect the hop between client and resolver:

• DoT (RFC 7858) runs DNS over TLS on port 853; easy for network teams to see and allow or block.
• DoH (RFC 8484) runs DNS inside HTTPS on port 443; blends with web traffic and is built into modern browsers.
• DoQ (RFC 9250) runs DNS over QUIC for lower latency.

Enterprises that rely on internal DNS filtering often disable browser DoH via policy, or point it at their own DoH endpoint, so split-horizon names and security filtering keep working.

Tools and commands

dig (Linux, macOS) gives the most detail; nslookup works everywhere; Resolve-DnsName is the PowerShell equivalent on Windows.

Clearing caches after a change:

• Windows: ipconfig /flushdns (view with ipconfig /displaydns)
• macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
• Linux (systemd-resolved): resolvectl flush-caches
• Chrome: chrome://net-internals/#dns → Clear host cache
• Windows DNS Server: Clear-DnsServerCache

Reading dig output. The status: field in the header is the first thing to check: NOERROR means the name exists, NXDOMAIN means it does not, SERVFAIL means the resolver could not get a valid answer (often DNSSEC or unreachable authoritative servers), and REFUSED means the server will not answer you. The flags: line shows aa when the answer came from an authoritative server, and the number beside each record in the ANSWER section is its remaining TTL.

Online checkers such as DNSViz (DNSSEC chains), MXToolbox (mail records) and whatsmydns.net (propagation across global resolvers) are useful when you cannot run commands from the affected network.

Troubleshooting

Work from the client outward: confirm it is DNS, then find which hop gives the wrong answer.

1. Confirm it is DNS. If ping 203.0.113.10 works but ping www.example.com fails, name resolution is the problem.
2. Check which resolver the client uses. ipconfig /all (Windows), resolvectl status (Linux), scutil –dns (macOS). A VPN or DHCP change often swaps it silently.
3. Query that resolver directly, then a public one (1.1.1.1, 8.8.8.8). Different answers point at the local resolver, a cache, or split-horizon.
4. Ask the authoritative server with +norecurse. If it is wrong there, the problem is the zone data, not caching.
5. Trace delegation with dig +trace. Mismatched NS records between parent and child, or missing glue, show up here.
6. Check DNSSEC if you see SERVFAIL: compare dig +cd (checking disabled) with a normal query. If +cd works, the signature chain is broken.

Before any migration, lower the TTL on records you will change to 300 seconds at least one old-TTL period in advance. After the move, raise it again.

Glossary