DNS: The Internet’s Distributed Key-Value Store

Hi there! I'm Maneshwar. Right now, I’m building LiveAPI, a first-of-its-kind tool for helping you automatically index API endpoints across all your repositories. LiveAPI helps you discover, understand, and use APIs in large tech infrastructures with ease.

DNS (Domain Name System) is essentially the Internet’s “phonebook” – a distributed directory that maps human-readable names to machine addresses.

In practice, when you visit example.com or call an API by name, DNS translates that name into an IP (e.g. 93.184.216.34) so your computer can connect.

This global, hierarchical system is everywhere under the hood of web apps: it’s how your browser finds servers, how microservices talk to each other by name, and how clouds (like AWS Route 53 or Cloudflare DNS) steer traffic.

If DNS isn’t working or is misconfigured, even healthy servers become unreachable, so developers need to understand it to debug outages and configure domains correctly.

How DNS Resolution Works

When your app or browser looks up a domain, the DNS resolution follows a multi-step path through the system. A typical flow is:

1. Query the Resolver: Your machine asks a recursive DNS resolver (often provided by your ISP, company network, or a public service like 8.8.8.8) for the domain’s IP.
2. Root & TLD Lookup: If the resolver doesn’t already have the answer cached, it first asks a root DNS server for the top-level domain (TLD) authority. For example, for www.example.com, it would ask the “root” servers for .com.
3. Authoritative Server: The resolver then asks the authoritative DNS server for the domain (e.g. the nameserver hosting “example.com” – in AWS this might be a Route 53 name server). That server looks up the record and returns the IP address (for instance, 192.0.2.44).
4. Answer & Cache: The IP address is passed back to your resolver, which returns it to your browser or app. The resolver also caches the answer for the record’s TTL period so that subsequent queries can be answered locally without repeating all the upstream steps.

In AWS’s documentation example, the Route 53 nameserver finds the www.example.com A-record, returns the IP (e.g. 192.0.2.44) back to the resolver, and the resolver caches it. Finally, your browser connects to that IP to fetch the web page.

This whole lookup chain happens “behind the scenes” in milliseconds. Developers can peek under the hood using tools like dig or nslookup. For example:

$ dig example.com A +short  
93.184.216.34
$ dig example.com AAAA +short  
2606:2800:0220:1:248:1893:25c8:1946

These commands show the IPv4 and IPv6 addresses for example.com, respectively – the values stored in its DNS A and AAAA records.

DNS Records: Keys and Values

DNS stores its data in records, which you can think of as key–value pairs in a giant distributed map.

The domain or subdomain is the key, and the record type plus data is the value.

Cloudflare describes zone files (DNS records) as instructions that include what IP address is associated with a domain.

Each record also has a TTL (time-to-live) that tells resolvers how long they can cache the answer.

Common record types include:

• A – Maps a name to an IPv4 address (e.g. example.com → 93.184.216.34).
• AAAA – Maps a name to an IPv6 address.
• CNAME – Canonical Name (alias): forwards one name to another name (e.g. www → example.com); it does not itself provide an IP.
• MX – Mail exchanger record: directs email to a mail server for the domain.
• TXT – Arbitrary text data: often used for domain ownership verification or SPF/DKIM email info.
• NS – Nameserver record: delegates a domain to a set of authoritative DNS servers. (Every domain has NS records listing its DNS servers.)
• SOA – Start of Authority: holds admin info and metadata about the DNS zone (one per zone).

Each of these records plays a role in directing traffic.

For example, in a web deployment you might create an A record to point api.myapp.com to your cloud load balancer’s IP, and a CNAME so that cdn.myapp.com aliases to a hosted service.

Figuring out which record holds the right value is key when something breaks.

DNS: A Distributed Key-Value Store

It helps to think of DNS as a huge, distributed key-value database.

The “key” is the domain name (like foo.example.com) and the “value” is whatever the record holds (often an IP address). Unlike a single database server, this KV store is global and hierarchical.

Root servers, TLD servers, and authoritative servers are all part of the storage system.

A query traverses this hierarchy to look up the key.

In AWS’s words, DNS is “globally distributed” and works much like a phone book managing mappings between names and numbers.

When you update a record (changing the value for a key), it propagates through this distributed store (subject to caching).

This analogy helps when debugging: changing a DNS record is like updating a database entry.

If you write a new value (e.g. change the IP), it won’t be visible everywhere instantly due to caching (TTL).

But once the old entries expire, clients will eventually read the new value from the store.

Caching and TTL: Performance Optimization

To improve speed, DNS heavily relies on caching.

Every DNS record comes with a TTL (“time to live”) – a duration in seconds that tells resolvers how long they can reuse the answer.

Once a resolver (or your OS or browser) looks up example.com and gets an IP, it keeps that record cached for the TTL before querying again.

Cloudflare explains that caching “short-circuits” the lookup process and significantly improves performance and reliability.

Indeed, a cached entry means your system doesn’t have to traverse root or TLD servers again – it just returns the stored IP immediately.

For example, modern browsers and OSes typically cache DNS answers for a bit.

Chrome even provides chrome://net-internals/#dns to inspect its cache.

The resolver at your ISP also caches results.

If a record’s TTL is 3600 seconds (1 hour), anyone who looked up that domain in the past hour will use the cached address.

This means repeated lookups of the same domain are very fast, but it also means DNS changes propagate only after the old TTL expires.

In short, a long TTL can make DNS lookups faster (fewer queries) but slower to update, whereas a short TTL makes changes propagate faster but increases lookup traffic.

Troubleshooting DNS Issues: Tips

• Check the records: Use tools like dig or nslookup to query DNS directly. For example, dig example.com A +short should return your server’s IP. No answer or the wrong IP means the DNS record may be missing or incorrect.
• Verify TTL effects: If you recently changed a record but clients still hit the old IP, it could be due to TTL. You might temporarily lower the TTL before making a switch (e.g. to 60 seconds) so caches expire quickly.
• Test different resolvers: Sometimes ISP caches can be stale. Try a public DNS (like Google’s 8.8.8.8 or Cloudflare’s 1.1.1.1) to see the global status.
• Inspect NS records: Ensure your domain’s NS records are set to the correct provider (Route 53, Cloudflare, etc.). If NS records point to the wrong DNS host, your updates won’t have any effect.
• Use logging and tools: Some services (Cloudflare, Route 53) offer DNS query logs or dashboards. These can show you if lookups are happening or failing. Also check for typos in domain names.

By understanding the path a DNS query takes, the role of each record, and how caching/TLLs work, you can usually pinpoint most domain-related issues.

Remember that DNS is fundamental infrastructure – it’s the wireframe of the Internet’s addressing system – so getting it right is key to making your applications reachable and fast.

LiveAPI helps you get all your backend APIs documented in a few minutes

With LiveAPI, you can quickly generate interactive API documentation that allows users to search and execute APIs directly from the browser.

If you’re tired of manually creating docs for your APIs, this tool might just make your life easier.