Networking and Protocols

DNS

Distributed naming system that maps domain names to records like IP addresses.

Where you will see it: Shows up in packet captures, network diagrams, firewall rules, and system or network logs.

What it is

DNS (Domain Name System) is the Internet's phonebook and a lot more. It stores records under domain names, such as which IP addresses serve a hostname, which mail servers handle a domain, or which keys are used for DNSSEC.

Key points

Resolvers cache answers using TTL to reduce load and latency.
Queries usually use UDP, with TCP used for larger replies or zone transfers.
Understanding recursion and authority explains most DNS behavior.

How it works in broad strokes

Your device asks a local resolver (often your router or OS stub resolver) for a name, like www.example.com.
If the answer is cached and still valid (TTL not expired), the resolver replies immediately.
If not cached, a recursive resolver performs the lookup by asking the DNS root servers where to find the relevant top level domain.
The resolver asks the top level domain servers for the authoritative servers for the domain.
The resolver asks an authoritative server for the final record, like an A or AAAA record.
The authoritative answer comes back with a TTL. The resolver caches it and returns it to the client.
If the response is large, the resolver may retry over TCP, and modern deployments also use encrypted transports like DoH or DoT for privacy.

Concrete example

You type a URL. Before any TCP or TLS connection happens, your machine resolves the hostname through a resolver. If the resolver already cached the answer, the lookup can be microseconds. If not, it may contact several servers across the DNS hierarchy before returning the final IP.

Why it matters

Hard coding IP addresses does not scale. Services move, load balance, and fail over. DNS provides a stable name while the underlying addresses and routing can change.

Security angle

DNS can be poisoned or spoofed without protections, so resolvers use randomization and may validate DNSSEC where available.
Open resolvers can be abused for amplification. Recursive resolvers should be restricted to trusted clients.
Encrypted DNS (DoH, DoT) improves privacy but can also hide DNS from traditional network monitoring.

Common pitfalls

Chasing the wrong server. The client usually talks to a recursive resolver, not the authoritative server.
Ignoring caching. A change may not show up until TTLs expire.
Assuming DNS always means A records. Many failures are actually MX, TXT, CNAME, or SRV related.
Forgetting about negative caching. NXDOMAIN responses can also be cached.
Debugging by only pinging an IP. Name resolution and connectivity are different problems.

DEEP DIVE

▾

The cast: stub, recursive, authoritative

On most devices, an application does not speak directly to the global DNS system. It asks a local stub resolver, usually part of the OS, which then queries a recursive resolver. The recursive resolver is the workhorse. It performs the search across the DNS hierarchy and returns a final answer to the stub.

Authoritative servers are different. They do not search. They answer for zones they control, like example.com, and they return records along with TTL values. Root servers and top level domain servers are also authoritative for their specific zones, and their main job is to tell the resolver where to go next.

Thinking in roles clarifies troubleshooting. If your laptop cannot resolve names but a different resolver works, the problem is often the recursive resolver or the path to it. If everyone on the internet cannot resolve a domain, the problem is more likely in the authoritative side or the zone configuration.

Step by step: resolving a name you have never seen

Imagine you type a fresh domain into your browser. The stub resolver first checks its own cache and the hosts file. If it has no entry, it sends a query to the configured recursive resolver. If the resolver also lacks a cached answer, it begins an iterative walk down the tree.

First it asks a root server for the domain. The root server does not know the final answer, but it returns a referral to the correct top level domain servers. Next the resolver asks a top level domain server, which returns a referral to the domain's authoritative name servers. Finally the resolver asks an authoritative server for the record type it needs, such as A or AAAA, and receives the answer with TTL values.

The resolver then caches the result and returns it to your device. From your perspective the whole thing looks like one lookup, but under the hood it is several network round trips. The payoff is that future lookups are fast because most pieces of the path are cached, including referrals.

Caching is the reason DNS scales

Caching happens at multiple layers: in the stub resolver, in the recursive resolver, in forwarders, and sometimes in applications themselves. The TTL on a DNS record tells caches how long they may reuse the data. When the TTL expires, the cache must ask again, which is why changes do not propagate instantly even if the authoritative server was updated.

Negative caching also matters. If a name does not exist, the resolver can cache that fact for a while to avoid repeating the same failed search. This improves resilience during typos and attacks, but it can surprise you during deployment if you create a record shortly after a cached negative response.

A useful mental model is that DNS is not a single database. It is a set of authoritative truths plus a vast number of temporary copies. Debugging often means finding which copy someone is using, and whether that copy is stale.

Transport details you notice in the wild

Most DNS queries and responses use UDP because it is fast and simple. If a response is too large for UDP, the server can set a truncation flag and the client retries with TCP. TCP is also used for zone transfers between authoritative servers and in some DNSSEC heavy scenarios.

Modern DNS uses EDNS to allow larger UDP payloads than the old default, but size still matters because oversized datagrams can fragment. Operators often tune DNS response sizes to avoid fragmentation on common paths, which is why some responses are deliberately compact.

If you see intermittent failures, look for middleboxes that mishandle UDP fragments, or for resolvers that cannot reach authoritative servers due to firewall rules. DNS is sensitive to small connectivity issues because it relies on multiple distinct destinations during a single resolution.

Security and privacy considerations

Classic DNS has no encryption, so on path observers can see which names you look up, and attackers can try to spoof responses. Resolvers defend with random transaction IDs, random source ports, and careful caching rules, but it is still a protocol that assumes a mostly honest network.

DNSSEC adds authenticity by letting resolvers validate signed records, but it does not encrypt the query. DNS over TLS and DNS over HTTPS add encryption for the client to resolver leg, improving privacy on local networks, but they do not change how the resolver talks to authoritative servers unless configured to do so.

A pragmatic takeaway is to separate integrity from confidentiality. DNSSEC helps you trust the answer. DoT and DoH help hide the question on the first hop.