How DNS resolution works in practice

DNS (Domain Name System) is a distributed, hierarchical, cached naming system. The vocabulary this module uses comes from RFC 9499, published as BCP 219 in March 2024, which obsoletes RFC 8499 and is now the canonical definition of terms such as stub resolver, recursive resolver and authoritative server. If a runbook or a vendor document you inherit still cites 8499, the definitions have moved. Understanding where each role sits is essential for diagnosing DNS failures correctly.

The stub resolver runs on your machine. It is not a full DNS implementation. It takes a question from the application (what is the IP for example.com?), forwards it to a configured recursive resolver, and returns the answer. Most operating systems have a stub resolver built into their networking stack.

The recursive resolver (also called a full-service resolver or caching resolver) does the actual work. It either answers from its cache or walks the DNS hierarchy to find the authoritative answer. ISP resolvers, Google's 8.8.8.8, and Cloudflare's 1.1.1.1 are all recursive resolvers.

Authoritative nameservers hold the final, definitive records for a zone. When you update your domain's A record, you update it at the authoritative server. The recursive resolver fetches the answer from there and caches it for the duration of the TTL (time to live).

The resolution path for `api.example.com` works like this. The stub resolver asks the recursive resolver. If the recursive resolver has no cache entry, it asks a root server which TLD server handles `.com`. The root server responds. The recursive resolver asks the `.com` TLD server which nameserver handles `example.com`. The TLD server responds. The recursive resolver asks the `example.com` authoritative server for the IP of `api.example.com`. It gets an A record back, caches it for the TTL, and returns it to the stub resolver.

Every one of those steps returned a record, and they were not all the same kind of record. The root and the TLD server answered with delegations rather than addresses, and only the last answer was the A record the application wanted. Reading a resolution trace therefore depends on knowing which record type belongs at which tier.

DNS records are not just IP address lookups. Each record type has a specific purpose. Confusing them is one of the most common sources of DNS misconfiguration.

A record. Maps a hostname to an IPv4 address. Example: `api.example.com` resolves to `93.184.216.34`.

AAAA record. Maps a hostname to an IPv6 address. The name comes from IPv6 being four times larger than IPv4.

CNAME (canonical name) record. Creates an alias pointing to another hostname. `www.example.com CNAME example.com` means "look up example.com and use that answer for www.example.com." CNAME chains are valid but add resolution steps and latency.

MX (mail exchanger) record. Specifies the mail server for a domain. Points to a hostname (not an IP), with a priority number. Lower priority numbers are tried first.

NS (nameserver) record. Identifies the authoritative nameservers for a zone. These are the servers the TLD delegate queries to.

SOA (start of authority) record. Contains zone metadata: the primary nameserver, the zone administrator's email address, zone serial number, and timing parameters for secondary nameserver synchronisation.

TXT (text) record. Stores arbitrary text. Used for SPF (Sender Policy Framework) email anti-spoofing, DKIM (DomainKeys Identified Mail) public keys, domain ownership verification, and various application tokens.

SVCB and HTTPS records. RFC 9460 defines service binding records that publish connection information before the client opens a transport connection. For web origins, HTTPS records can advertise alternative endpoints, supported application protocols, and parameters that help clients choose HTTP/3 or encrypted client hello paths.

Each of those record types is published once at the authoritative server and then read millions of times somewhere else. What decides how long an A record keeps answering after you have changed it, or how long a stale MX record keeps sending mail to a decommissioned host, is a single number carried alongside the record.

Every DNS record has a TTL value measured in seconds. When a recursive resolver caches an answer, it keeps it until the TTL expires. This is why a change you made to your DNS record may not be immediately visible to everyone on the internet.

A user whose resolver cached the old A record an hour ago with a 24-hour TTL will continue seeing the old IP for up to 23 more hours. A user whose resolver just looked up the record will get the new one. This is not a bug; it is the design. Caching is what makes DNS scale to billions of queries per day without the authoritative servers handling every single request.

If you are preparing for a DNS migration, reduce the TTL to 300 seconds (five minutes) a day or two before the change. After the change, you can increase it again. This limits how long stale records persist while keeping normal load on the authoritative servers manageable.

Caching also means most answers a client accepts were never spoken by the authoritative server that owns the name. They came out of a resolver's memory, and the client has no way to tell a genuine cached answer from one an attacker injected into that cache, or from one an on-path observer read on its way past. Both halves of that problem have their own mechanism, and they are not the same mechanism.

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records. It allows resolvers to verify that a response was actually signed by the zone owner and has not been tampered with in transit. DNSSEC prevents cache poisoning attacks where a malicious actor injects false DNS answers.

DNSSEC does not encrypt DNS traffic. Queries and responses are still visible to network observers. What it adds is integrity: you know the answer came from the real zone and has not been modified.

That split leaves half the problem open. A signed answer is a correct answer, but the question that produced it still crosses the network in the clear, so anyone on the path can read every name a device looks up. Closing that half took three separate transports, each of which arrived with a different set of operational consequences.

Three standards now carry DNS over an encrypted channel, and the difference between them is which existing traffic they resemble. DNS over TLS (DoT), defined in RFC 7858, puts ordinary DNS messages inside a TLS session on TCP port 853. The port is dedicated to DNS, so a network operator can see that a device is doing encrypted DNS and can permit or block it as a category, without reading the names inside.

DNS over HTTPS (DoH), defined in RFC 8484, carries the same messages inside HTTPS requests on port 443. Because it shares a port and a TLS profile with the rest of the web, it is far harder to single out, which is exactly what makes it popular with browser vendors and awkward for network teams that filter by name.

DNS over QUIC (DoQ), defined in RFC 9250, runs DNS over QUIC on UDP port 853. It keeps DoT's dedicated-port honesty while taking QUIC's faster connection setup and its freedom from head-of-line blocking, which matters most for resolver-to-authoritative traffic where many queries share one connection.

None of this helps if the client never discovers that an encrypted option exists. Discovery of Designated Resolvers, defined in RFC 9462, is the mechanism that closes that gap: a client asks its configured resolver for designated resolver records, learns the encrypted endpoint that resolver operates, verifies it, and upgrades from plaintext DNS to DoT, DoH or DoQ without a human changing a setting.

The standard friction in enterprise deployment is UDP 853. Many corporate firewalls permit outbound TCP 443 and little else, so DoQ is blocked by default and DoT is blocked wherever the site closes TCP 853 to keep DNS on its own inspecting resolvers. DoH survives because blocking it means blocking the web. The practical result is that the transport a device ends up using is usually decided by the firewall, not by the design document.

Encryption moved the trust question. It did not remove it. DoT, DoH and DoQ stop an observer on the path between you and your resolver from reading your queries. They give the resolver itself a complete, attributable log of every name you ask for, which is more than the on-path observer had before. Choosing an encrypted resolver is choosing whom to trust with that log.

The traffic that follows the lookup leaks the answer anyway. Once the name has resolved, the connection carries the destination IP address in the clear, and for most sites that address is enough to identify the service. Where a large shared host serves thousands of names from one address, the Server Name Indication field in the TLS ClientHello names the site in plain text at the start of the handshake, so an observer who cannot read your DNS can simply read your connections instead.

Encrypted Client Hello, specified in RFC 9849, is what closes the SNI gap, and it closes it only partially. It requires the client, the DNS records for the origin and the server deployment to support it, and it hides the inner name behind a public one shared by everything on that fronting deployment. Where all three parts are in place, an observer learns that you connected to the fronting service and not which tenant of it you wanted. Where any part is missing, the name is visible as before.

So the honest description of encrypted DNS is narrow and worth stating to anyone who asks for it by name: it protects the confidentiality of your queries against the network between you and the resolver, and it does nothing about the resolver, the destination address, the TLS handshake without ECH, or anything the application does after the connection opens.