DNS Explained for DevOps (2026): Records, TTLs, DNSSEC and Real Outages

Plenty of the outages I have helped debug in fourteen years began with someone saying "it can't be DNS", and a fair number of them were DNS. DNS was first specified in 1983, its core RFCs date from 1987, and it sits under every deploy, certificate renewal and service call, so DevOps engineers own it whether or not anyone wrote that down. This is DNS explained for DevOps engineers as it stands in October 2026: how a lookup travels from stub to recursive to authoritative servers, the record types that matter (including ALIAS, CAA and the newer HTTPS record), why "propagation" is really caching, what changed for DNSSEC this month when the root zone switched keys, what five recent DNS outages teach, and how all of it reappears inside Kubernetes. Unless I say otherwise, every output below is from the dig that ships with macOS, run today; the companion dig troubleshooting guide is the hands-on version.

How DNS resolution works: stub, recursive and authoritative servers

There are three roles, and most confusion comes from mixing them.

The stub resolver is the library inside your process: glibc's getaddrinfo, musl, systemd-resolved, or mDNSResponder on a Mac. It asks one configured server one question and expects a finished answer.

The recursive resolver does the work: 1.1.1.1, 8.8.8.8, your VPC's built-in resolver, or CoreDNS in a cluster. It starts at the root, follows referrals down the tree, validates DNSSEC if configured, and caches every step.

The authoritative servers hold the zone itself. They answer only for names they own, set the aa (authoritative answer) flag, and refuse everything else. When I asked one of Cloudflare's authoritative servers for google.com, it replied REFUSED, which is exactly what it should do.

At the top sit the root servers: 13 identities, A to M, run by 12 independent organisations from 2,049 operational instances as of today. Here is the chain a recursive resolver walks for example.com, trimmed:

# dig 9.10.6 (macOS), 24 Oct 2026. RRSIG lines and most NS lines removed for length.
$ dig +trace example.com A
.             513462  IN  NS  a.root-servers.net.
;; Received 525 bytes from 1.1.1.1#53(1.1.1.1) in 16 ms
com.          172800  IN  NS  a.gtld-servers.net.
com.          86400   IN  DS  19718 13 2 8ACBB0CD28F4...
;; Received 1171 bytes from 170.247.170.2#53(b.root-servers.net) in 78 ms
example.com.  172800  IN  NS  hera.ns.cloudflare.com.
example.com.  172800  IN  NS  elliott.ns.cloudflare.com.
example.com.  86400   IN  DS  2371 13 2 C988EC423E38...
;; Received 506 bytes from 192.54.112.30#53(h.gtld-servers.net) in 147 ms
example.com.  300     IN  A   172.66.147.243
example.com.  300     IN  A   104.20.23.154
;; Received 179 bytes from 108.162.195.228#53(elliott.ns.cloudflare.com) in 11 ms

The four legs add up to about a quarter of a second; the same question answered from 1.1.1.1's cache took 11 ms. That gap is why DNS has TTLs, and why caching explains most of what people blame on "propagation".

DNS record types DevOps engineers actually use

A platform team touches about eight record types regularly.

Record	What it holds	The gotcha	Source
A / AAAA	IPv4 / IPv6 addresses	Several records give clients a choice, not health-checked load balancing	RFC 1034
CNAME	An alias to another name	No other data may sit at the same name, so never at the zone apex	RFC 1034 s3.6.2
ALIAS / flattening	Provider resolves a target and returns A/AAAA	Not a DNS standard; Route 53 alias targets only AWS resources or same-zone records	Route 53, Cloudflare
TXT	SPF, DKIM, domain verification strings	When DNS fails, mail authentication fails with it	Clerk postmortem
CAA	Which CAs may issue certificates	Lookups follow CNAMEs; CAs must validate DNSSEC on them since 15 March 2026	RFC 8659, SC-085v2
HTTPS / SVCB	Protocols (h3, h2), IP hints, ECH keys, apex aliasing	Old tools print it as opaque TYPE65 hex	RFC 9460
NS / SOA	Delegation and zone metadata	The SOA values set how long "does not exist" is cached	RFC 2308
DS / DNSKEY / RRSIG	The DNSSEC chain of trust	A parent DS that matches no DNSKEY breaks the whole zone	Cloudflare EDE docs

CNAME at the apex is the classic trap. RFC 1034 says that if a CNAME is present at a node, "no other data should be present", and the apex always carries SOA and NS records, so a CNAME there is illegal. Route 53's alias records work around it by answering with the target's addresses; queries to AWS resources are free and you cannot set the TTL, per the Route 53 guide. Cloudflare's CNAME flattening chases the chain and returns the final IP, and warns that a dangling target returns an empty NODATA answer that looks like a propagation problem.

HTTPS records are the standard answer to the apex problem and more. RFC 9460, published November 2023, defines an AliasMode (priority 0) that is allowed at the apex, plus a ServiceMode that advertises protocols and address hints before the client connects. Route 53 added HTTPS and SVCB in October 2024. Decoded through Google's DNS JSON API, cloudflare.com today publishes 1 . alpn=h3,h2 ipv4hint=104.16.132.229,104.16.133.229 plus IPv6 hints, and crypto.cloudflare.com adds an ech= parameter carrying its Encrypted ClientHello key.

CAA decides which certificate authorities may issue for your names; Let's Encrypt documents accounturi and validationmethods parameters that pin issuance to one ACME account and one challenge type.

A zone excerpt that puts these together:

; Zone excerpt in RFC 1035 master-file syntax; HTTPS syntax per RFC 9460.
$TTL 300
@      3600 IN SOA   ns1.example.net. hostmaster.example.com. (
                     2026102401 ; serial
                     7200       ; refresh
                     3600       ; retry
                     1209600    ; expire
                     300 )      ; minimum: with the SOA TTL, caps negative caching
@           IN NS    ns1.example.net.
@           IN NS    ns2.example.org.  ; second, independent provider
@           IN A     192.0.2.10
@           IN AAAA  2001:db8::10
@           IN HTTPS 1 . alpn="h3,h2" ipv4hint=192.0.2.10
www         IN CNAME example.com.      ; fine below the apex, illegal at @
@           IN CAA   0 issue "letsencrypt.org;validationmethods=dns-01"
@           IN CAA   0 iodef "mailto:security@example.com"

How long does DNS propagation take, really?

Nothing pushes your change to the world's resolvers. Your provider updates its authoritative servers, usually within seconds, and every resolver that cached the old answer keeps serving it until the TTL runs out.

The "up to 48 hours" folklore does match one real number. In the trace above, the .com servers hand out the delegation for example.com with a TTL of 172,800 seconds, which is exactly 48 hours, while the zone's own NS records carry 86,400. Changing nameservers at the registrar is therefore the slow case. Changing an A record in a zone you already run is bounded by that record's TTL, 300 seconds here.

Three wrinkles catch people:

1. Negative caching. If anything looked up the name before you created it, the "does not exist" answer is cached too, for the lower of the SOA record's TTL and its MINIMUM field, per RFC 2308. Today that is 1,800 seconds for example.com, 60 for google.com and 3,600 for iana.org.
2. Resolvers clamp TTLs. Unbound's defaults are a cache-max-ttl of 86,400 seconds and a cache-max-negative-ttl of 3,600, per its manual. Runtimes and connection pools can cache on top.
3. Stale answers are allowed. RFC 8767 lets resolvers serve expired data, with a recommended TTL of 30 seconds, for one to three days when authoritative servers are unreachable. RFC 9520 requires them to cache resolution failures for between one second and five minutes.

Also, a public resolver address is many caches. Five back-to-back queries to 1.1.1.1 for example.com returned TTLs of 141, 124, 70, 152 and 139 seconds; the same five against 8.8.8.8 returned 300 each time. The rule has not changed in twenty years: lower the TTL at least one old-TTL before a migration, change, then raise it. Google offers a Flush Cache page and Cloudflare a purge tool.

DNSSEC in 2026: the root key changed, and CAs now check

DNSSEC signs records so a validating resolver can prove an answer came from the zone owner. Each zone publishes keys (DNSKEY) and signatures (RRSIG), and the parent publishes a hash of the child's key-signing key (DS), so trust chains down from the root. It encrypts nothing; that is DNS over HTTPS or TLS.

The root of that chain just changed. ICANN published KSK-2024, key tag 38696, into the root zone on 11 January 2025 and switched signing to it on 11 October 2026, warning that resolvers without it would see total resolution failure and reporting in July that more than 95 percent of reporting resolvers had already adopted it. When I queried a.root-servers.net this morning, the root DNSKEY set held the old KSK (20326), the new one (38696) and a ZSK, and the only signature over it came from 38696. ICANN's DNS-OARC slides schedule the old key's revocation for 11 January 2027 and list the first releases carrying the new key: Unbound 1.21.0, BIND 9.18.33 and 9.20.4, Knot Resolver 5.7.4 and 6.0.8, PowerDNS Recursor 5.2.0. Old resolver images deserve a check.

The second change matters to anyone who renews certificates. CA/Browser Forum ballot SC-085v2 requires CAs to validate DNSSEC, when present, on CAA and domain-validation lookups from 15 March 2026. A broken signature used to hurt only validating users; now it can also block your next certificate, and with certificate lifetimes shrinking you renew more often.

What broken DNSSEC looks like at scale was shown by DENIC on 5 May 2026. Its final report says a bug in an in-house rollover agent generated a separate key pair on each of three HSMs, all sharing key tag 33834, so only about a third of signatures matched the published key. Bogus NSEC3 signatures meant validating resolvers could not resolve even unsigned .de domains for about three hours; some large operators switched off validation for .de meanwhile. The fixes include partial validation of the zone before deployment, more alerting, and a faster switchover to a known-good backup.

One newer behaviour will confuse your scripts. RFC 9824, published September 2025, standardises compact denial of existence: signed zones answer a nonexistent name with NOERROR and an NSEC record whose type bitmap includes the NXNAME marker (type 128), instead of NXDOMAIN. A made-up name under example.com, which Cloudflare serves, returned exactly that (NSEC ... RRSIG NSEC TYPE128), while the same test under google.com and iana.org returned NXDOMAIN. Checks that expect NXDOMAIN need to know.

Five DNS outages from 2025 and 2026, and what each teaches

The last year's postmortems are a better DNS course than most textbooks. Four of them, plus DENIC, sorted by how long the DNS layer itself was broken:

AWS us-east-1, 19 to 20 October 2025. AWS's summary describes a DNS Planner that builds plans and three DNS Enactors that apply them to Route 53. A race let a delayed Enactor overwrite a newer plan, then cleanup deleted it, leaving dynamodb.us-east-1.amazonaws.com with no addresses from 11:48 PM PDT. DNS was restored by 2:25 AM and cached records expired by 2:40 AM, but dependent EC2 and load balancer systems took until 2:20 PM. The record's TTL is 5 seconds today, so caching barely mattered; the 2025 to 2026 outages post has the full chain. Lesson: DNS automation needs the same guard rails as deploy automation.

Cloudflare 1.1.1.1, 14 July 2025. A June configuration change for a pre-production service accidentally included the resolver's prefixes; a July change triggered a global refresh that withdrew them, and the resolver was down for 62 minutes, 21:52 to 22:54 UTC. DNS over HTTPS stayed relatively stable because it uses different addresses. The change was peer-reviewed but not canaried. Lesson: configure resolvers from two different operators.

Cloudflare 1.1.1.1, 8 January 2026. A memory optimisation put CNAME records after the A records instead of before them; glibc's getaddrinfo then returned nothing and three Cisco switch models went into reboot loops, according to Cloudflare's write-up. RFC 1034 only says the answer is "possibly preface by one or more CNAME RRs", without a MUST; Cloudflare reverted by 19:55 UTC and proposed a draft to make ordering explicit. Lesson: old clients encode assumptions the spec never stated.

Clerk, 10 February 2026. Its DNS provider's four nameservers across two networks all failed for 2 hours and 32 minutes. Caching and fallback resolvers kept successful requests above 95 percent of the expected volume, but the registrar and DNS host were coupled, which blocked an emergency nameserver change for one critical domain, and long TTLs hid the failure from uptime checks. The fixes are a second independent provider, separating registrar from DNS host, and monitoring authoritative servers directly.

How Kubernetes DNS works, and why ndots:5 matters

Inside a cluster, CoreDNS is both authoritative for cluster.local and the forwarder for everything else. The kubelet writes each pod's /etc/resolv.conf with the DNS Service IP, a search list of <namespace>.svc.cluster.local svc.cluster.local cluster.local and options ndots:5, as the Kubernetes docs show. Services get names like my-svc.my-namespace.svc.cluster-domain.example.

The ndots:5 line means any name with fewer than five dots is tried against the search list first. A call to api.stripe.com (two dots) becomes api.stripe.com.<namespace>.svc.cluster.local and two more candidates, each queried for A and AAAA, before the real name is tried. That is up to six wasted queries per lookup, in every pod. A trailing dot (api.stripe.com.), a lower ndots in dnsConfig, or NodeLocal DNSCache fixes it; the Kubernetes DNS troubleshooting guide has the commands. CoreDNS v1.15.0, released on 21 October 2026, adds DNS-over-QUIC upstreams and stale-cache fixes. Cluster DNS is the busiest service most teams never monitor.

FAQ

What is the difference between a recursive and an authoritative DNS server?

A recursive resolver (1.1.1.1, your VPC resolver, CoreDNS) answers clients by walking the tree from the root and caching results. An authoritative server holds a zone's records and answers only for that zone, with the aa flag set; ask it about another domain and it should say REFUSED.

Can I use a CNAME record on my root domain?

No. RFC 1034 forbids other data alongside a CNAME, and the apex always has SOA and NS records. Use your provider's ALIAS or flattening feature (Route 53 alias, Cloudflare CNAME flattening), plain A and AAAA records, or an HTTPS record in AliasMode for clients that support it.

How long does DNS propagation take?

As long as the old TTL. Record changes in an existing zone take up to that record's TTL; nameserver changes can take up to the parent's delegation TTL, 48 hours for .com. Negative answers are cached for the lower of the SOA TTL and SOA minimum.

Should I enable DNSSEC in 2026?

For zones you can automate end to end, yes: it stops forged answers, and CAs now validate it when present. Mistakes become outages, as DENIC showed, so use managed signing, monitor signature expiry, and remove the DS record before moving providers.

The quarter's plan for me is short. I would check every validating resolver image for key tag 38696 before the old key is revoked in January, add authoritative-server checks that bypass caches, put the registrar and the DNS host in different companies for anything customer-facing, and write CAA records with accounturi for the domains that matter. None of it is new technology; it is ordinary operational hygiene applied to the layer everything else depends on.

Related: Cloud Outages 2025-2026: What 7 Official Postmortems Actually Teach, How to Troubleshoot Kubernetes DNS and CoreDNS: Step by Step (2026) and How to Build Multi-Region Failover with Route 53 and Cloud DNS (2026).