Every control you deploy — TLS, SSO, segmentation, zero trust policy — sits on top of a system designed in the 1980s and still running largely unauthenticated: name resolution. In the state-linked campaigns Cisco Talos documented as Sea Turtle, attackers compromised registrars and DNS providers rather than target networks; controlling the answers was enough to obtain valid TLS certificates and quietly intercept credentials. DNS security is therefore not a product you buy but a chain of custody to defend: registrar, registry, authoritative zone, resolver path, and the monitoring that notices when any link drifts.
The uncomfortable lesson from public incidents is that victims often had strong perimeters and weak control over their names. Regulators have caught up — NIS2 pulls DNS service providers and TLD registries into scope as essential entities — but most engineering teams still treat DNS as a solved checkbox. Here is the full path, hardened in the order attackers actually work it.
The registrar is the root of your trust
Everything downstream is irrelevant if someone can change your NS records with a phished password.
- ▸Registry lock, not just registrar lock: a registrar lock is a flag your registrar can be socially engineered into clearing. A registry lock requires an out-of-band manual procedure at the registry itself and is the single highest-value control on this list.
- ▸Hardware-backed MFA on a dedicated account: the registrar login should require FIDO2 keys, be held by named individuals, and never share credentials with marketing tooling.
- ▸Break the recovery loop: if the registrar account recovers via an email address on a domain the same registrar controls DNS for, one compromise unlocks both. Recover through a domain held at a different provider.
Sign the zone like it is 2026, not 2010
DNSSEC earned a bad reputation from oversized RSA responses and manual key ceremonies that broke zones at 2 a.m. Modern deployments are different: sign with algorithm 13 (ECDSA P-256) for compact signatures, automate rollovers, and use CDS and CDNSKEY records (RFC 8078) so DS updates at the parent happen without a human pasting hex into a registrar panel. Managed authoritative providers handle all of this now, and validation coverage among the large public resolvers means signatures are actually checked. Sign your zones, monitor DS validity continuously from an external vantage point, and rehearse the emergency-unsign procedure so a mistake costs minutes rather than a day.
Encrypt and control the resolver path
On the resolution side, decide deliberately who answers your fleet's queries. Run internal resolvers — Unbound and Knot Resolver are both excellent — with DNSSEC validation enabled and encrypted transport upstream: DNS over TLS (RFC 7858) or DNS over HTTPS (RFC 8484). Then make them the only path: block outbound ports 53 and 853 from everything that is not a resolver, and treat direct-to-Internet DoH from servers as the policy bypass it is. Centralized resolvers give you response policy zones for known-bad domains and, just as valuable, query logs — one of the cheapest, highest-signal telemetry sources in incident response, mapping directly to techniques like MITRE ATT&CK T1071.004 (DNS-based command and control).
Hunt your own dangling records
Subdomain takeover needs no exploit: a CNAME pointing at a deprovisioned SaaS tenant or a cloud resource someone else can claim hands an attacker a hostname under your brand, often with cookies scoped to your parent domain. The fix is inventory discipline. Reconcile every zone record against live, owned infrastructure on a schedule; alert on CNAME targets that stop resolving or return provider parking pages; make record deletion part of every decommissioning runbook. Pair this with CAA records (RFC 8659) restricting which certificate authorities may issue for your domains, and subscribe to Certificate Transparency log monitoring so an unexpected certificate — the classic first artifact of a DNS hijack — pages you before customers see it.
A DNS hardening checklist
1. Enable registry lock on crown-jewel domains and FIDO2-only login at the registrar; document the unlock procedure and test it once. 2. Sign zones with ECDSA P-256, automate rollovers via CDS and CDNSKEY, and monitor DS validity externally. 3. Publish CAA records and wire Certificate Transparency alerts for all owned domains into your on-call. 4. Deploy validating internal resolvers with encrypted upstreams; block all other outbound DNS at the egress. 5. Reconcile zone contents against live infrastructure weekly and page on dangling CNAME targets. 6. Ship resolver query logs to central storage with retention matching your incident response window.
DNS incidents are rarely contained events — they are brand-level failures where customers see certificate warnings or, worse, see nothing while credentials flow elsewhere. Against that blast radius, the controls above are remarkably cheap: mostly configuration, automation, and a few hours of monitoring setup. Boards ask about AI threats; auditors ask about NIS2 scope. A team that can show a signed zone, a locked registry, and an alert that fires within minutes of a rogue certificate has a credible answer to both — and one less 1980s protocol holding up the entire stack on trust alone.