DNS
DNS is the distributed naming system that resolves hostnames such as `www.example.com` into records clients can use, most often IP addresses. It sits before the transport connection: if resolution returns the wrong answer, no answer, or a stale answer, the browser may never reach TCP, QUIC, or TLS.
The problem DNS solves is that people, certificates, and deployments are organised around names, while networks route to addresses. A browser cannot open an HTTPS connection to `api.example.com` merely because that string exists in a URL. It must first learn where the name currently points. When this step breaks, symptoms often look like a dead service, but the failure is earlier: the client has not found a usable endpoint to connect to.
Resolution is a chain of lookups and caches. A client may check browser state, the operating system, `/etc/hosts`, then ask a recursive resolver. If the resolver lacks a fresh answer, it walks the hierarchy: root servers direct it to a TLD such as `.com`, the TLD directs it to authoritative nameservers, and those return records such as `A`, `AAAA`, `CNAME`, or `MX`. A `CNAME` is not an address, so resolution continues at its target.
DNS trades freshness for scale and resilience through caching. A TTL lets resolvers reuse an answer, which reduces load and latency, but also means changes are not immediate. Lowering a TTL during an incident does not affect clients that already cached the previous value. Negative answers such as `NXDOMAIN` can be cached too, so recreating a deleted record may not repair every client at once.
Engineers meet DNS when deploying domains, load balancers, CDNs, Kubernetes services, and email. Common mistakes include pointing a `CNAME` at a deleted cloud load balancer, publishing only an `AAAA` record when IPv6 is not actually reachable, or trying to place a `CNAME` at a zone apex where `SOA` and `NS` records must exist. In clusters, systems such as CoreDNS provide the same naming function for internal service names.
Common questions
- What actually happens after I type a hostname in a browser?
- The browser and operating system look for a cached answer, then usually ask a recursive resolver. That resolver may query root, TLD, and authoritative nameservers until it gets a usable record. Once an IP address is returned, the browser can open a transport connection, commonly to port `443` for HTTPS.
- Is DNS the same thing as an IP address?
- No. DNS is the lookup system and record database; an IP address is one possible result. An `A` record returns an IPv4 address, an `AAAA` record returns an IPv6 address, and a `CNAME` returns another name that must be resolved. Confusing names with addresses hides many deployment failures.
- Why does a DNS change not take effect immediately?
- Because resolvers and clients cache answers for the record's TTL. Until that cached answer expires, they may keep using the old address or even a cached negative response. The honest answer is that propagation time depends on previous TTLs, resolver behaviour, and client caches, not just the new record you publish.
- Does DNS use UDP or TCP?
- Usually UDP port `53`, because most queries and replies are small. TCP port `53` is used when responses are too large, when a reply is truncated with `TC=1`, and for operations such as zone transfers. Treating DNS as UDP-only is a common misunderstanding that can cause firewall mistakes.