Every request to a service like api.example.com starts with a simple question: what network address should this name use?

DNS (Domain Name System) answers that question. It turns human-friendly names into the records clients need before they can connect.

DNS is also one of the first places engineers make production traffic changes. When you point a domain at a load balancer, move traffic between regions, or publish mail and security settings, DNS is usually involved.

DNS matters in system design because it sits before almost every network connection. If DNS is slow, wrong, blocked, or misconfigured, the application may never receive the request at all.

DNS is also cached by design. That makes it fast and scalable, but it also means changes are not instant everywhere. This chapter explains how DNS lookups work, how caching and TTLs behave, and where DNS fits into routing and failover.

DNS maps a domain name to one or more resource records.

A resource record is just a typed DNS answer. One record might say "this name points to this IPv4 address." Another might say "mail for this domain goes to this mail server."

Examples:

Each record has:

DNS is organized like a tree.

The root points resolvers to top-level domains such as .com. The .com registry points resolvers to the name servers for example.com. Those name servers hold the actual DNS records for example.com.

That handoff is called delegation. It simply means, "ask these name servers for the next part of the answer."

There are 13 logical root server names, labeled A through M. They are not just 13 physical machines. Each name is served by many machines around the world, usually using anycast so clients reach a nearby instance.

Most applications do not talk to the final DNS server directly.

They ask a local stub resolver, usually part of the operating system or runtime. The stub resolver forwards the question to a recursive resolver, which does the lookup work.

Common recursive resolvers include:

If the recursive resolver already has a cached answer, it returns it immediately. If not, it follows the DNS tree until it finds the right authoritative name server.

Step by step:

This caching is why authoritative DNS providers do not see every user lookup. They usually see cache misses from recursive resolvers, not every request from every browser, phone, or backend service.

Traditional DNS usually uses UDP port 53 for normal lookups. It can also use TCP port 53, especially when a response is too large for UDP or when name servers transfer zone data to each other.

Encrypted DNS uses different transports. DoT (DNS over TLS) commonly uses TLS on port 853. DoH (DNS over HTTPS) sends DNS queries over HTTPS on port 443.

DNS uses two query patterns. The names sound formal, but the idea is simple.

Recursive query: The client asks a resolver, "Please find the final answer for me." The resolver does the work.

Iterative query: A server says, "I do not have the final answer, but here is the next server to ask." The requester continues from there.

In normal use, your laptop or application sends a recursive query to its configured resolver. That recursive resolver then uses iterative queries against root, TLD, and authoritative servers.

This difference matters when debugging. If dig @8.8.8.8 api.example.com works but dig @ns1.example-dns.com api.example.com fails, the public resolver may simply be returning an old cached answer while the authoritative server is broken.

A DNS lookup passes through several systems. They are often owned by different teams or companies, and each one has a different job. Knowing the pieces makes it much easier to understand who controls a DNS answer and where things can break.

Domain Registrar

The registrar is where a domain is registered, such as example.com. It controls which name servers are listed for the domain at the registry.

Changing DNS records and changing name server delegation are different operations. Updating an A record changes an answer inside your DNS zone. Changing delegation changes which name servers are responsible for the whole domain.

Registry and TLD Servers

A registry operates a top-level domain such as .com, .org, or a country-code TLD.

TLD servers do not store every record like api.example.com. They store the handoff information that tells resolvers which name servers answer for example.com.

Authoritative Name Servers

Authoritative name servers hold the official DNS records for a zone, such as example.com.

If you run api.example.com on a cloud load balancer, the authoritative DNS record might point to that load balancer. If you move to a CDN, the authoritative record might become a CNAME to the CDN provider.

Recursive Resolvers

Recursive resolvers do the lookup work for clients and cache results. They matter a lot for reliability. A slow or broken recursive resolver can make healthy services look unavailable.

Stub Resolvers

The stub resolver is the small client-side DNS component in the operating system, runtime, or library. It usually forwards DNS questions to a recursive resolver configured by DHCP, VPN settings, a container runtime, /etc/resolv.conf, or platform settings.

Stub resolver behavior varies. Some cache answers. Some do not. Some application runtimes cache DNS longer than expected. Java, browsers, mobile SDKs, service meshes, and libc implementations can all behave differently.

DNS stores different kinds of records. These are the ones engineers see most often in production.

Two practical notes:

A CNAME points to another name, not directly to an IP address. After seeing a CNAME, the resolver still has to resolve the target name.

Standard DNS also does not allow a CNAME at the root of a domain, such as example.com, when required records like SOA and NS already exist there. This is why many providers offer ALIAS, ANAME, or CNAME flattening. Those are provider-specific ways to get CNAME-like behavior at the domain root.

DNS caching is controlled by TTL (Time To Live). A TTL tells resolvers how long they may reuse an answer before asking again.

Any resolver that receives this answer may cache it for up to 60 seconds.

TTL is a tradeoff:

Low TTL does not mean instant change. Existing caches may keep old answers until they expire. Some resolvers enforce their own minimum TTLs. Some clients cache answers on their own. Some applications resolve a name once at startup and never refresh it until the process restarts.

Negative Caching

DNS also caches failures. If a resolver receives NXDOMAIN, meaning "this name does not exist," it may cache that failure for a while.

This matters during rollouts. If clients look up new-api.example.com before you create the record, they may cache the failure and keep failing for a while even after the record exists.

CNAME Chains

CNAME chains add extra lookup steps:

Short chains are normal. Long chains add latency, create more places to fail, and make migrations harder to reason about.

DNS can steer traffic by returning different answers for the same hostname.

Common policies include:

DNS steering is useful, but it is a broad tool. It happens when the name is resolved, not when each request is handled.

A resolver may cache one answer and reuse it for many clients. DNS also does not know the current CPU load, open connection count, queue depth, user identity, or HTTP path.

Use DNS to choose a global or regional entry point. Use load balancers, gateways, service meshes, or application routing for decisions that must happen per request.

Example:

DNS helps pick the region. The load balancer behind that address decides which server actually handles the request.

DNS has several security concerns. The right protection depends on what you are trying to prevent.

DNSSEC

DNSSEC signs DNS records so resolvers can check that answers came from the domain owner and were not changed on the way.

DNSSEC does not encrypt DNS queries. Someone watching the network may still see which name is being queried unless another privacy tool is used.

Operationally, DNSSEC adds key management. Broken signatures, expired keys, or bad DS records can make a domain fail DNS validation even when the application itself is healthy.

DoT and DoH

DNS over TLS (DoT) and DNS over HTTPS (DoH) encrypt DNS traffic between the client and recursive resolver.

They protect the path between the client and resolver from snooping or tampering. They do not hide queries from the recursive resolver itself, and they do not replace DNSSEC.

Cache Poisoning and Spoofing

DNS cache poisoning tries to trick a resolver into caching a fake answer. Modern resolvers have many defenses, including random IDs, random source ports, strict checks on which servers are allowed to answer, DNSSEC validation, and hardened resolver behavior.

For application teams, the main lesson is simple: use reputable DNS providers, enable DNSSEC when you can operate it correctly, protect registrar access, and monitor domain and certificate changes.

DNS is not only for the public internet.

Private DNS is common in:

Examples:

Private DNS introduces its own failure modes:

Split-horizon DNS simply means the same name can return one answer inside a private network and a different answer outside it.

ndots is a resolver setting that controls when a name is treated as complete versus when search domains are appended. A surprising ndots value can turn one lookup into several lookups.

In Kubernetes, DNS is the common service discovery interface, but high-traffic systems still need to understand caching, connection reuse, and service mesh behavior. Resolving a name on every request is usually a bad design.

DNS failures often look like application failures until you check resolution explicitly.

Useful debugging commands:

When debugging production DNS, compare answers from different places:

Use DNS deliberately. It is simple to edit, but mistakes can take time to unwind because old answers may be cached.

Use Stable Names

Applications should depend on stable names, not hard-coded IP addresses.

Good:

Bad:

Names let you move services, replace infrastructure, change providers, and issue certificates without changing application configuration.

Plan TTLs Before Migrations

Lower TTLs before a planned migration, wait for old caches to expire, then change records. After the migration is stable, raise TTLs again if the record does not need to change often.

Do not lower a TTL at the same moment you need the change. Resolvers that already cached the old longer TTL can keep using the old answer until it expires.

Separate DNS From Request Routing

DNS is a good place to choose a region or entry point. It is not a good place to choose the exact backend for each request.

For example, an AI inference platform might use:

Each layer has a different job. DNS gets the client to the right front door. The layers behind that door handle the request-level decisions.

DNS is a distributed, cached system for looking up names. It maps names to typed records, not just IP addresses.

Clients usually ask recursive resolvers, not authoritative servers directly. Root and TLD servers point resolvers to the next place to ask. Authoritative servers give the final answers for their zones.

TTLs control how long answers stay cached, including failed lookups. That is why DNS changes are never truly instant. DNS can steer traffic, but only broadly and only when a name is resolved.

Security and privacy are easy to mix up. DNSSEC helps prove DNS answers are genuine, but it does not encrypt queries. DoH and DoT encrypt traffic between the client and resolver, but they do not replace DNSSEC.

Private DNS is essential in cloud and Kubernetes systems, and it brings its own failure modes. When DNS works, no one thinks about it. When it breaks, the symptoms look like slow first requests, failed migrations, broken certificates, intermittent outages, and unreachable services.