DNS security and zero-trust networking

DNS is a trust decision, not a lookup

Treat DNS as plumbing and you’ll defend the wrong layer. The name-to-address resolution is the moment your system chooses who to trust, and classic DNS makes that choice over an unauthenticated, plaintext UDP exchange. Two failure modes dominate in production.

Cache poisoning. A resolver that caches answers can be tricked into caching a forged one. The 2008 Kaminsky attack made this brutal: by spraying forged responses for many random subdomains, an attacker only needs to win one race against the legitimate reply, and because the early DNS protocol had just a 16-bit transaction ID (65,536 values) and a known source port, that race was winnable in seconds on a fast link. The poisoned record then serves every downstream client until the TTL expires. The patch — randomizing the source port to add ~16 more bits of entropy — turned a seconds-long attack into a statistically impractical one, but it was a mitigation, not a fix: nothing in the protocol authenticated the answer.

On-path and the resolver’s privilege. Anyone between you and your resolver — a malicious Wi-Fi AP, a compromised router, a hostile ISP — can read every name you look up (a privacy leak) and rewrite the answer (an integrity attack). Your resolver is one of the most privileged hosts in your stack: it silently decides the destination of every connection you make.

DNSSEC and DoH protect different things

These two get conflated constantly, and conflating them produces a false sense of safety. They solve orthogonal problems.

DNSSEC signs DNS records with public-key cryptography, building a chain of trust from the root zone down to the answer. It guarantees integrity and authenticity: the record you got is the record the zone owner published, unmodified. It does not encrypt anything — a DNSSEC query and its signed reply are still visible on the wire — and it solves cache poisoning at the root, since a forged answer fails signature validation. Its cost is real: deployment is operationally heavy (key rollovers, chain-of-trust breakage takes a zone offline), and adoption has stalled for years well under half of zones, so you usually can’t rely on it end-to-end.

DoH / DoT (DNS over HTTPS / over TLS) wrap the query in an encrypted transport. They guarantee confidentiality and transport integrity against an on-path observer: the coffee-shop attacker can no longer see or rewrite your lookups. They do not authenticate the record itself — your resolver could still return a poisoned or censored answer; you’ve simply moved your trust to whoever runs the resolver. DoH’s tunnelling DNS inside ordinary HTTPS (port 443) is also why it’s contentious: it bypasses the network-level DNS monitoring that enterprises and parental filters rely on.

The senior reading: DNSSEC + an encrypted transport is the complete answer — sign the record so it can’t be forged, encrypt the query so it can’t be read or rewritten in flight. Either alone leaves a real gap. And neither answers the deeper question this lesson is really about: even with a perfectly resolved, perfectly encrypted connection to the right host, should this caller be allowed to reach it at all? That’s where the perimeter model breaks.

Why the perimeter died: zero-trust

The classic model was a castle: a hard network perimeter (firewall, VPN) around a soft, trusted interior. Get inside the VPN and you were “on the corporate network,” which implicitly meant trusted — flat east-west access to internal services. That model has a single catastrophic failure mode: once an attacker is inside, they own everything. A phished laptop, a compromised contractor VPN credential, one exploited edge device, and the flat interior becomes a free-roaming lateral-movement playground. The 2020 SolarWinds intrusion is the canonical example — trusted internal position turned one supply-chain foothold into wide reach.

Zero-trust, codified in NIST SP 800-207, inverts the assumption: never trust, always verify. There is no trusted network. The location of a request — inside the VPN or on hotel Wi-Fi — confers zero implicit authorization. Every single request to a resource is authenticated and authorized on its own merits, evaluated against the identity of the user and the device, not the IP it came from. Trust is never granted by network position and is continuously re-evaluated, not handed out once at login.

What zero-trust looks like in practice: BeyondCorp and the IAP

Google’s BeyondCorp is the reference implementation, born from the 2009 Aurora attack that walked straight through their perimeter. The keystone component is the identity-aware proxy (IAP): instead of a VPN that drops you onto the network, every request to an internal app passes through a proxy that, per request, checks the authenticated user identity, the device’s posture (is it managed, patched, healthy?), and an authorization policy for that specific resource — then allows or denies. There is no network to be “on.” An engineer reaches an internal dashboard from a café exactly the way they reach it from the office: through the proxy, proving who they are and what device they’re on, every time.

This collapses the attack surface in a way the VPN never could. A stolen session or a phished credential no longer yields the network; it yields, at most, the narrow set of resources that one identity-plus-device is authorized for, re-checked on every request — and device posture can revoke access the moment a machine falls out of compliance. The TLS 1.3 handshake (RFC 8446) that authenticates each of these connections is the cryptographic floor zero-trust stands on: mutual identity, forward secrecy, and a faster handshake make per-request verification cheap enough to do everywhere.