How fast is a DNS lookup?

A cache hit on your local resolver is typically 1-5 milliseconds. A fresh lookup that has to walk root → TLD → authoritative is 50-150 milliseconds depending on how far apart the servers are. Repeat visits within the TTL window are almost always cache hits and effectively free.

What happens if a DNS server is down?

Each layer of the system has redundancy. The root zone has 13 logical servers, each implemented as hundreds of anycast instances. Every TLD has multiple authoritative servers. Most domains have at least two name servers listed in their NS records, typically on different physical networks. A single server going down is invisible to users; an entire authoritative provider going down (which has happened — Route 53 in 2019, Akamai in 2021) takes down every domain hosted there until they switch to a backup.

What is the difference between DoH and DoT?

Both encrypt DNS queries between your client and the resolver. DoH (DNS over HTTPS) tunnels DNS inside an HTTPS connection on port 443 — it looks like normal web traffic and is hard to block selectively. DoT (DNS over TLS) uses a dedicated port 853 — easier for network operators to identify and either permit or block at the policy level. From a privacy perspective they're equivalent; from a network-policy perspective DoT is friendlier.

Why does DNS sometimes take a long time to propagate?

DNS doesn't really "propagate" — each resolver caches whatever it last fetched until the TTL on that record expires. If you set a 24-hour TTL and then change the A record, every resolver in the world will keep serving the old answer until its cache expires, which can take up to 24 hours from when each one fetched. Operators with imminent migrations drop the TTL to 60 seconds a day before the change, then raise it back after — that way the cache window during the cutover is minimal.

Can my ISP see my DNS queries even with DoH?

With DoH (or DoT), the resolver you talk to cannot be observed by your ISP — they see HTTPS traffic to Cloudflare or Google, not which domains you queried. The resolver itself, however, still sees every query you make. The trade-off is whether you trust your ISP or your DoH provider more. For most people the DoH provider (Cloudflare, Google, Quad9, NextDNS) has better privacy commitments than the home ISP.

How DNS works — from URL bar to answer in 50 milliseconds

The directory that holds the internet together

Computers talk to each other using numeric IP addresses. People remember names — example.com, github.com, your bank's hostname. The Domain Name System is the global translation layer between the two, and almost every interaction with the internet starts with a DNS lookup.

DNS was designed by Paul Mockapetris in 1983 (RFC 882 / 883, later refined as RFC 1034 / 1035), replacing a flat HOSTS.TXT file that ARPANET sites had been downloading periodically from SRI. The original design — a tree of authority rooted at "." with delegations downward — has aged extraordinarily well. The same structure handles 14 trillion queries a day across hundreds of millions of domains in 2026.

The cast of characters

Stub resolver. Built into your operating system. When an application — a browser, a curl command, an email client — wants to talk toexample.com, it asks the stub. The stub does very little work itself; it just forwards the question to the recursive resolver listed in its configuration, then caches the answer briefly.
Recursive resolver. The component that actually does the hierarchy walk. Your ISP usually runs one; alternatives are Cloudflare's1.1.1.1, Google's 8.8.8.8, Quad9's 9.9.9.9, NextDNS, AdGuard DNS. A recursive resolver knows the addresses of the root servers and walks downward from there until it has the authoritative answer.
Root name servers. Thirteen logical servers — A.root-servers.net through M.root-servers.net — actually implemented as hundreds of physical instances via anycast (see BGP). Their job is to know who operates each top-level domain. The root zone is published by ICANN and IANA and is roughly 25 KB of cryptographically-signed data.
TLD name servers. Separate name servers for .com, .org, country TLDs like .uk and .jp, and the long tail of newer generic TLDs. Each TLD's operator (the "registry") runs them; the largest is Verisign for .com (~160 million names). Their job is to know which authoritative server owns each domain inside their TLD.
Authoritative name servers. The actual source of truth for a given domain — usually run by the domain's registrar, by a managed DNS provider (Cloudflare, Route 53, NS1, dnsimple), or by the domain owner themselves on their own infrastructure. The authoritative server holds the zone file with the records you care about: A, AAAA, MX, TXT, and so on.

The walk, step by step

You type example.com in your address bar. Here's what happens in sequence, assuming nothing is cached anywhere:

Browser asks the stub resolver. The stub probably hasexample.com cached already; assume it doesn't this time.
Stub asks the configured recursive resolver. This is the1.1.1.1 / 8.8.8.8 / ISP resolver. Same — probably cached; assume not.
Recursive resolver asks a root server: "Who handles .com?" The root server replies with the addresses of the .com TLD name servers (these are cached for hours anyway, but in principle this is where it starts).
Recursive resolver asks a .com TLD server: "Who is authoritative for example.com?" The TLD server replies with the NS records — typically two to four name-server hostnames, plus their IPs (the "glue" records).
Recursive resolver asks an authoritative server: "What's the A record for example.com?" The authoritative server consults its zone file and replies with the IP address (and a TTL).
Recursive resolver caches the answer for the TTL the authoritative server set and returns it to the stub. The stub returns it to the browser.
The browser finally opens a TCP connection to the IP.

In practice, steps 3–5 happen on a cold lookup once a day at most. Steps 3 and 4 have answers cached for hours; step 5's TTL is the most variable but typically minutes to hours. After the first lookup in a cache window, subsequent users get step 6 results from cache in single-digit milliseconds.

Order of magnitude: a fully cold lookup across continents takes 150–250 ms (mostly round-trip time); a typical lookup with intermediate caching takes 10–30 ms; a stub-cache hit is under 1 ms.

The record types you actually care about

The same hierarchy serves dozens of record types. The ones worth knowing:

A — an IPv4 address. The original. Most lookups end here.
AAAA ("quad-A") — an IPv6 address.
CNAME — alias to another name. "Don't look here, look at something-else.example.com instead." Cannot coexist with other records at the same name.
MX — mail-server routing for the domain. Lists the hostnames of mail servers in priority order. Without an MX record, mail to your domain has nowhere to go.
TXT — free-form text. Hosts SPF policies (sender authentication), DKIM public keys, DMARC policies, domain-verification tokens for Google Search Console / Microsoft / many SaaS providers.
NS — name-server delegation. Specifies which authoritative servers are responsible for the zone.
SOA — Start of Authority. Administrative metadata: primary name server, contact email, serial number, refresh timers. One per zone.
CAA — Certification Authority Authorization. Lists which TLS certificate authorities are permitted to issue certs for this domain. Important defense-in-depth against CA-side misissuance.
PTR — reverse DNS (IP → name). Lives in the in-addr.arpa tree for IPv4 or ip6.arpa for IPv6. Used for mail-server reputation and for traceroute hostnames.
SRV — service discovery. Tells you which host runs SIP, XMPP, or other services on which port. Pre-HTTP-everything way of finding services.
HTTPS / SVCB — newer record types (RFC 9460, 2023) that combine an address record with service-binding metadata like ALPN and ECH key. Increasingly used by browsers to discover HTTP/3 endpoints in a single lookup.

IPFerret's DNS lookup tool queries any of these against Cloudflare's DoH endpoint, so you get the authoritative-side answer without going through your ISP's resolver.

Caching, TTLs, and the bite that comes with them

Every DNS answer carries a TTL — the number of seconds a downstream resolver should consider it valid before re-querying. Low TTLs (60–300 seconds) let you flip records fast for blue-green deployments. High TTLs (hours to days) reduce upstream load and speed up repeat lookups. The trade-offs:

Low TTL: nimble cutovers, more authoritative-server load, visibility into ongoing query volume. Used by Cloudflare, by CDN-fronted services, and by anyone doing geo-IP-based routing.
High TTL: snappy repeat lookups, lower DNS bill if you pay per query, slow recovery from misconfiguration. The classic mistake is setting a 24-hour TTL on a record you might need to change in an emergency.

The mitigation for the high-TTL trap is to drop the TTL before you make a change: 24 hours before a planned migration, drop to 300 seconds. During the migration, all resolvers stay within 5 minutes of the truth. After the dust settles, raise the TTL back to whatever you want.

Modern privacy and security: DoH, DoT, DNSSEC, ECH

DNSSEC — cryptographic signatures on records. Lets a resolver verify "this answer was published by the authoritative owner and was not forged in transit." Doesn't encrypt anything; it just attests authenticity. Deployment is uneven — root and TLDs are fully signed; the long tail of zones is mostly not.
DNS over HTTPS (DoH) — DNS queries wrapped in an HTTPS connection on port 443. Hides queries from local network observers — your coffee shop's router can no longer see which sites you're looking up. Modern browsers can do DoH directly, bypassing the OS resolver entirely.
DNS over TLS (DoT) — DNS wrapped in TLS on a dedicated port 853. Same privacy goal as DoH, easier for network operators to identify and permit/block at the policy level. Often preferred by enterprise networks that want visibility into "is anyone using non-corporate DNS."
Encrypted Client Hello (ECH) — a TLS extension, not a DNS feature directly. Encrypts the SNI hostname so even an observer watching DoH-protected traffic can't see which specific site you're reaching at a multi-tenant edge IP. Detailed in our TLS / HTTPS guide.

When DNS quietly misbehaves

Stale cache. You changed an A record yesterday and one ISP's resolver is still serving the old value. The fix is to wait the TTL; there is no invalidation command in DNS.
DNS leak. You're on a VPN but your OS is sending DNS queries outside the tunnel — your ISP still sees every domain you visit. Test on the DNS leak test page.
ISP NXDOMAIN hijacking. Some ISPs rewrite "domain doesn't exist" responses to point at their own search-or-ad pages. Annoying when an app expects NXDOMAIN to mean what it says. Switching to a third-party resolver fixes it.
CNAME-at-apex edge cases. The DNS spec forbids CNAME at the zone apex (the bare domain). Some providers offer "flattening" — they resolve the CNAME and synthesize an A record — but behaviour varies across resolvers and sometimes breaks SPF / DKIM / DMARC alignment for the same name.
Negative caching. Resolvers cache "this name doesn't exist" too, with a TTL set by the parent zone's SOA. If you create a brand-new record and users had recently queried for it (and got NXDOMAIN), they'll keep seeing the "doesn't exist" answer until the negative cache expires.

How DNS works