HTTP and DNS in practice
Name resolution from stub resolver to authoritative server, the record types that matter, and how HTTP/1.1, HTTP/2 and HTTP/3 differ on the wire.
DNS records that matter
| Type | Answers | Notes |
|---|---|---|
A | IPv4 address | The workhorse record |
AAAA | IPv6 address | Often missing on otherwise modern zones |
CNAME | Alias to another name | Not allowed at the zone apex |
MX | Mail exchangers | Has a priority value |
TXT | Arbitrary text | Domain verification, SPF, DKIM |
NS | Authoritative servers | Delegation between zones |
SRV | Host and port for a service | Used by SIP, LDAP, Kubernetes |
dig example.com A +short
dig example.com MX
dig @1.1.1.1 example.com ANY
# follow the whole delegation chain from the root
dig +trace www.example.com
# check how long a resolver may cache the answer
dig example.com | grep -A1 "ANSWER SECTION"How a lookup actually resolves
- The application asks the stub resolver in the OS (which first consults the hosts file and the local cache).
- If unknown, the query goes to a recursive resolver — your ISP, or 1.1.1.1 / 8.8.8.8.
- The resolver asks a root server, which returns the address of the relevant TLD nameserver.
- The resolver asks the TLD server, which points at the domain's authoritative nameservers.
- The authoritative server returns the record; the resolver caches it for the record's TTL and replies.
Three consequences follow directly from that design. Answers are cached for their TTL, so a change is not visible everywhere at once. Negative answers are also cached, which is why a typo can keep failing after you fix it. And the resolver, not your application, does most of the work — latency is usually resolver distance, not authoritative-server distance.
⚠️
Do not use a
CNAME at the zone apex (the bare domain). It collides with the mandatory SOA and NS records; providers that appear to allow it are quietly flattening the record for you, without the standard's semantics.HTTP versions on the wire
| Version | Transport | Concurrency model | Main win |
|---|---|---|---|
| HTTP/1.1 | TCP | One request per connection at a time | Simple, universal |
| HTTP/2 | TCP + TLS | Multiplexed streams over one connection | No head-of-line blocking for parallel requests |
| HTTP/3 | QUIC (UDP) | Multiplexed streams, per-stream loss recovery | No TCP-level head-of-line blocking |
# which protocol did the server actually negotiate?
curl -sS -o /dev/null -w '%{http_version}\n' https://example.com
# HTTP/2 only if the server advertises it over TLS (ALPN)
curl -sSI https://example.com | head -1- HTTP/2 requires TLS in every browser, negotiated through the ALPN extension during the handshake.
- Domain sharding and sprite sheets were workarounds for HTTP/1.1 connection limits; both hurt under HTTP/2.
- HTTP/3 pays off most on lossy mobile links, where TCP treats one lost packet as a stall for the whole connection.
FAQ
Why does a DNS change take so long to take effect?
The old answer stays in caches until its TTL expires, and some resolvers ignore short TTLs. Lower the TTL to 300 seconds a day before a planned cutover, then raise it again.
Should I query 8.8.8.8 when debugging?
Yes — comparing a public resolver against your configured one isolates whether the problem is your resolver, the zone data, or local caching.
Related
Layered models and TCP/IP One page request, end to end
Last refreshed 2026-09-18.