DNS

Computers route traffic using IP addresses, but people remember names. DNS bridges that gap. When you type github.com, something has to turn that name into an address like 140.82.121.4 before any packet can be sent. DNS is the system that does the lookup, and it runs every time you open a page, send mail, or load an app.

DNS is not one giant table. It is a distributed database split into a tree of zones, where each part of the internet runs the servers responsible for its own names. Google runs the authoritative servers for google.com, your registrar or DNS provider runs yours, and a small set of root and top-level-domain servers tie the whole tree together.

DNS also stores more than addresses. A records hold IPv4 addresses, AAAA records hold IPv6 addresses, CNAME records point one name at another, MX records say which servers receive a domain's email, TXT records hold verification and SPF strings, and NS records say which name servers are authoritative for a zone. One domain often has dozens of records of different types.

The work is done by a recursive resolver, usually run by your ISP or a public service like 1.1.1.1 or 8.8.8.8. Your machine asks the resolver for an address and the resolver does the legwork on your behalf.

If the answer is not already cached, the resolver walks the hierarchy. It asks a root server, which does not know github.com but knows who handles the .com zone. It asks one of those TLD servers, which points it at GitHub's authoritative name servers. It asks those, which return the actual A record. The resolver hands the address back to your machine, which can finally open a connection.

That whole chain is why DNS leans hard on caching. Every answer carries a TTL, a time-to-live in seconds, that says how long it may be reused. Your operating system, your browser, your router, and the resolver all cache results, so the second and later lookups for a popular name are answered in under a millisecond instead of going back to the authoritative server. The cost of caching is that record changes take time to spread: lower the TTL before a migration and raise it afterward.

The hierarchy and caching make DNS fast and resilient, but the same caching makes changes slow to propagate. If you change a record while the old one still has a TTL of 86400 seconds, some users keep hitting the old address for up to a day. Teams plan migrations by dropping TTLs to 60 or 300 seconds in advance.

DNS is also a single point of failure that people forget is there. When the records for an entire domain vanish or the authoritative servers are unreachable, every service behind that name goes dark even though the servers themselves are fine. Facebook's six-hour outage in October 2021 took down Facebook, Instagram, and WhatsApp at once because a configuration change withdrew the routes to its DNS servers, and staff could not even badge into the building because the door system depended on the same internal DNS.

Plain DNS sends queries in clear text over UDP, which lets networks snoop on or spoof them. DNS over HTTPS and DNS over TLS encrypt the query, and DNSSEC adds signatures so a resolver can verify an answer was not tampered with. None of these are on by default everywhere, so security is a deliberate choice.

Because the resolver returns an address from a set of records, DNS is also a coarse load balancer and failover mechanism. Round-robin DNS hands out several A records in rotation so traffic spreads across servers. Latency-based or geo routing returns the address of the nearest data center, which is how a single name like netflix.com sends a viewer in Mumbai to a different IP than a viewer in London.

Managed services build on this. Amazon Route 53 supports health checks that stop handing out the address of a server that has failed, so DNS quietly steers users away from an outage within a TTL window. This is why content delivery networks like Cloudflare and Akamai put so much engineering into their authoritative DNS: the lookup is the first decision about where your request goes.