title: How to secure your DNS configuration description: A practical DNS hardening checklist: DNSSEC, DNS over HTTPS, registrar locks, redundant nameservers, rate limiting, and a quarterly audit routine. heroImageAlt: "Green padlock with a key over chained DNS record panels, topped by a checkmark shield, on a dark grid" date: 2026-06-10 tags: [dns, security] author: Trace Warrior Team
DNS is the part of your stack that everything else trusts implicitly. Your TLS certificates are issued based on DNS. Your email deliverability is decided by DNS. Every user session starts with a DNS answer nobody verifies. Which means a weak DNS configuration quietly undermines every other security control you've paid for, and most zones run for years on whatever settings were defaults at setup time.
This guide is the hardening pass. It covers both sides of the problem: securing the zones you publish (so nobody can forge or take over your names) and securing the resolution path your own machines use (so nobody can lie to you). Work through it once; it holds for years with a light audit cadence.
Step 1. Lock down the registrar, the actual root of trust
DNSSEC, monitoring, redundancy: all of it is moot if someone logs into your registrar account and repoints your nameservers. Registrar compromise is how most high-profile "DNS attacks" actually happen, and the defences are boring and fast:
- MFA on the registrar account, hardware key if supported. This is the single highest-leverage item in this guide.
- Transfer lock enabled. Run a WHOIS lookup on your domain and confirm
clientTransferProhibitedappears in the status field. While you're there, sanity-check the listed nameservers and registrant contacts; WHOIS is the public record of who controls your zone, and it should never surprise you. - Registry lock for domains where downtime is unacceptable. It requires out-of-band verification for any change: slower for you, far slower for an attacker.
- Minimal account access. The registrar login list should be short, named, and audited. No shared credentials in a wiki.
Step 2. Enable DNSSEC on your zones
DNSSEC cryptographically signs your records so validating resolvers can reject forged answers; it's the structural defence against cache poisoning and on-path spoofing.
Most managed DNS providers (Cloudflare, Route 53, Google Cloud DNS) reduce this to: enable signing on the zone, then publish the DS record they give you at your registrar. The DS record is the step people skip: without it, the chain of trust from the parent zone never forms and your signatures validate nothing.
Verify the chain end to end:
dig +dnssec example.com A @8.8.8.8
A validated answer carries the ad (authenticated data) flag in the header flags line. For a full trace of the trust chain, delv example.com A shows each delegation step and where it breaks, if it breaks.
Two operational cautions: keep key rollovers automated (provider-managed signing handles this; hand-rolled BIND signing is where DNSSEC outages come from), and remember that an expired signature takes your domain down for validating resolvers; DNSSEC fails closed.
Step 3. Encrypt the resolution path with DoH or DoT
Classic DNS travels as plaintext UDP, readable and forgeable by anyone on the path. DNS over HTTPS (DoH) and DNS over TLS (DoT) close that hole for the queries your machines send.
For infrastructure, point your stub resolvers at an encrypted upstream. With systemd-resolved:
# /etc/systemd/resolved.conf [Resolve] DNS=9.9.9.9#dns.quad9.net DNSOverTLS=yes
For fleets of laptops, set DoH policy in the browser/OS (Chrome, Firefox, Windows 11, and macOS all support it natively) rather than leaving each machine on whatever the coffee-shop DHCP hands out. Picking a filtering upstream like Quad9 or Cloudflare's 1.1.1.2 gets you step 6's malware-domain blocking for free.
One trade-off to decide consciously: DoH bypasses network-level DNS visibility. If your security team relies on resolver logs for detection, standardise on a corporate DoH endpoint instead of letting clients pick their own.
Step 4. Build in redundancy
DNS outages are total outages: nothing resolves, nothing works. Cheap insurance:
- Multiple nameservers on separate networks. Your NS set should span at least two topologically independent networks (any serious managed provider does this with anycast by default). For critical zones, a secondary provider on different infrastructure protects you from a provider-wide incident.
- Sane TTLs. 300-3600 seconds for records you might need to change in a hurry; longer for genuinely static records. Very low TTLs hammer your nameservers and amplify any resolver problem into a user-facing one.
- Test reachability of each nameserver individually. A ping test against each NS host confirms they're all actually answering, not just listed.
dig @ns2.example.com example.com SOAconfirms each one serves the zone.
Step 5. Rate-limit and reduce the attack surface
If you run your own authoritative or recursive servers:
- Response Rate Limiting (RRL) stops your authoritative servers from being used as DDoS amplifiers. In BIND:
rate-limit { responses-per-second 10; }; - Never run an open recursive resolver. Recursion should be off on authoritative servers and restricted to known networks on recursive ones:
allow-recursion { 10.0.0.0/8; }; - Disable zone transfers except to your own secondaries:
allow-transfer { secondaries; };(an open AXFR hands an attacker your complete internal naming map). - Prune stale records. Old CNAMEs pointing at deprovisioned cloud resources are subdomain-takeover bait. If
dev.example.compoints at an S3 bucket or Heroku app that no longer exists, anyone can claim it and serve content under your name.
Step 6. Filter known-malicious domains
On the resolution side, a protective resolver blocks lookups of known phishing and malware domains before a connection ever happens: cheap, broad coverage against the most common attack delivery path. Options by scale: Quad9 (9.9.9.9) or Cloudflare 1.1.1.2 as a zero-effort upstream, Pi-hole or a blocklist-fed Unbound for network-level control, or a commercial protective-DNS product when you need reporting and policy.
Step 7. Monitor for unauthorised changes
Every control above can be silently undone, by an attacker or by a teammate with a ticket and good intentions. Detection is the layer that makes the rest trustworthy:
- Continuous record monitoring. A DNS record drift monitor captures your record set as a baseline and alerts with a diff the moment NS, MX, TXT, or A records change. NS and MX changes in particular are rare and serious; an alert there is nearly always worth a look. The drift-monitoring guide covers choosing record types that produce signal instead of noise.
- Provider audit logs. Make sure DNS-change events from your provider land somewhere a human or SIEM will see them.
- Query logging on resolvers you run, for incident reconstruction.
Step 8. Put the audit on a schedule
Quarterly, 30 minutes:
- WHOIS check: locks present, nameservers and contacts correct.
dig +dnssecspot-check:adflag still present, no signature-expiry drift.- Full record review via the DNS Lookup tool; every record should map to something you still run. Delete the rest.
- Walk TXT records specifically: stale SPF includes and abandoned verification records accumulate fast, and SPF has a hard 10-DNS-lookup limit that stale includes silently burn.
- Confirm monitor baselines still match intended state.
- Review who holds registrar and DNS-provider access; remove leavers.
TL;DR
- MFA + transfer lock at the registrar; verify with WHOIS. This outranks everything else.
- Sign zones with DNSSEC, publish the DS record, verify the
adflag withdig +dnssec. - Encrypt the resolution path with DoH/DoT; pick a filtering upstream to block malicious domains too.
- Redundant nameservers on independent networks; sane TTLs; test each NS host.
- On self-hosted servers: RRL, no open recursion, no open zone transfers, prune takeover-bait records.
- Watch for drift with a DNS record monitor and audit quarterly.
Related
- How to detect DNS hijacking: what to do when the controls above fire
- How to recover from DNS poisoning: the incident-response counterpart
- How to monitor DNS records for drift: setting up the detection layer