DNS in Practice
The previous page covered how a lookup walks the DNS hierarchy. This one covers what actually lives in the zone, and the operational patterns built on top of it: routing traffic by geography, failing over automatically, keeping resolution private, and serving different answers to different audiences.
Record types
A zone file is a list of records, each mapping a name to some data. The record type determines what that data means:
| Type | Holds | Example use |
|---|---|---|
| A | An IPv4 address | api.example.com -> 203.0.113.10 |
| AAAA | An IPv6 address | api.example.com -> 2001:db8::10 |
| CNAME | An alias to another name | www.example.com -> example.com |
| MX | A mail server, with priority | example.com -> 10 mail.example.com |
| TXT | Arbitrary text | SPF/DKIM policy, domain ownership proof |
| NS | The nameservers authoritative for a zone | example.com -> ns1.example.com |
| SOA | Zone metadata: primary NS, serial, refresh/retry/expire, minimum TTL | one per zone |
A CNAME cannot coexist with other records at the same name (you cannot put
a CNAME and an MX on example.com itself), which is why bare "apex" domains
usually resolve via A/AAAA (or a provider-specific "ALIAS"/"flattened CNAME")
rather than a real CNAME.
TTL: how long an answer is trusted
Every record carries a TTL (time to live), in seconds. A recursive resolver caches the answer and will not ask again until the TTL expires - that is the caching behavior from the previous page, but the TTL is also a knob you control:
- Long TTL (hours) - fewer lookups, cheaper, but a change takes that long to propagate everywhere.
- Short TTL (30-60s) - changes roll out fast, at the cost of far more queries hitting your authoritative servers.
Drop the TTL before a planned change (a migration, a failover cutover) so the old, long-cached value has already expired everywhere by the time you flip the record. Raise it again once the new value has stuck.
Anycast and GeoDNS: routing by location
Two different techniques both get lumped under "DNS load balancing," and it is worth keeping them apart:
- Anycast - the same IP address is announced from many physical locations
over BGP, and the network routes each client to the topologically nearest
one. This is how
8.8.8.8and1.1.1.1answer instantly worldwide - it is not one server, it is one address advertised everywhere. The DNS answer never changes; the network decides where the packet actually lands. - GeoDNS - the resolver itself returns a different A/AAAA record depending on the resolver's (or client's) location. A user in Tokyo gets the IP of the Tokyo data center; a user in Frankfurt gets Frankfurt's. This is a DNS-layer decision, made per query, based on geo-IP lookup of who is asking.
Anycast pushes the routing decision down into the network layer and is invisible to DNS; GeoDNS pushes it up into the DNS answer itself. A CDN typically uses both: anycast to reach the nearest edge PoP, GeoDNS-style logic to pick which origin or region backs that PoP.
DNS-based failover
Because every DNS answer already carries a TTL, the same mechanism used for geo-routing doubles as failover: an authoritative server (or a managed DNS provider) runs health checks against each candidate IP and stops returning addresses that fail them. With a short TTL, clients converge onto healthy endpoints within roughly one TTL interval after an outage starts.
DNS failover is not instant. Some resolvers and OS stub caches ignore or extend TTLs, and clients that already resolved and cached an address won't recheck until their own cache expires. For sub-second failover you need something in front of DNS - a load balancer or anycast VIP - not DNS alone.
Split-horizon DNS
Split-horizon (or "split-brain") DNS serves different answers for the
same name depending on who is asking - typically, an internal answer for
requests arriving from inside the corporate network, and a public answer for
everyone else. internal.example.com might resolve to a private 10.x.x.x
address on the office network and to nothing (or a VPN gateway) from the
public internet. It is how organizations expose internal service names
without leaking internal topology or IPs to the public DNS.
DoH and DoT: encrypting the query itself
Plain DNS (port 53, UDP) is unencrypted - anyone on the path (an ISP, a coffee-shop Wi-Fi, a nation-state) can see every name you look up, and can tamper with the answer. Two standards fix this by wrapping DNS in an encrypted channel:
- DoT (DNS over TLS) - DNS queries run inside a TLS session on its own dedicated port (853). Easy for network operators to identify and block (or allow) as DNS traffic, since it stays on a distinct port.
- DoH (DNS over HTTPS) - DNS queries are wrapped in ordinary HTTPS requests on port 443, indistinguishable on the wire from any other HTTPS traffic to that server. This makes DNS censorship/blocking much harder to apply selectively, which is exactly why it is more controversial with network operators than DoT.
Choose DoT: it stays on a dedicated port, so corporate/ISP filtering, monitoring, and split-horizon behavior keep working unmodified.
Choose DoH: bundling queries into ordinary HTTPS traffic means they can't be singled out and blocked or logged separately from the rest of the user's web traffic.