When did anyone on your team last look at a DNS server log? If the answer is “never,” that gap is the problem. DNS turns names into addresses for every click, login, and API call your organization makes. It is also one of the few services that must stay reachable from the public internet, which makes it a favorite target for cache poisoning, amplification attacks, and quiet data exfiltration. A practical DNS security checklist turns that risk into a short list of verifiable tasks.
This guide walks through what to check, why each item matters, and the mistakes that show up again and again in real environments. It stays practical: no vendor pitch, no magic product, just the controls that professionals actually audit.
Start With an Inventory Before Touching a Single Setting
You cannot harden what you cannot see. Before changing configuration, list every place DNS runs in your environment: authoritative servers, internal recursive resolvers, forwarders at the network edge, cloud-hosted zones, and the stub resolvers on laptops and phones.
A common failure is hardening the data center resolvers while a forgotten branch office router still runs open recursion. Attackers scan for that. Inventory first, then prioritize.
| Asset type | What to record | Why it matters |
|---|---|---|
| Authoritative servers | Software, version, zone list, admin contact | Primary target for zone tampering |
| Recursive resolvers | Who can query them, forwarder chain | Open recursion fuels amplification attacks |
| Cloud DNS zones | Provider, registrar lock status, API keys | Weak registrar controls enable hijacking |
| Endpoint resolvers | OS settings, DoH/DoT status | Bypasses your filtering if unmanaged |
The Core DNS Security Checklist
1. Close Open Recursion
A resolver that answers queries from anyone on the internet is a gift to attackers. Restrict recursive queries to known client networks using access control lists in BIND or the equivalent setting in your platform. Then test from outside your network to confirm the restriction holds. This single step removes a large share of DNS amplification exposure.
2. Deploy DNSSEC Validation and Signing
DNSSEC adds cryptographic signatures to DNS records so a resolver can detect forged answers. Sign your own zones and enable validation on your resolvers. The underlying protocol is defined in RFC 1035, and DNSSEC builds on that foundation. Validation is the half most organizations skip, and it is the half that actually protects users from cache poisoning.
Practical tip: enable validation in a monitoring-only mode first. Broken signatures in third-party zones will surface, and you want to see them before users do.
3. Lock Down Zone Transfers
Zone transfers should only reach secondary servers you control. Use TSIG keys or strict IP allowlists, and disable transfers entirely on servers that do not need them. An unrestricted transfer hands an attacker a complete map of your internal naming, including hosts you thought were hidden.
4. Encrypt Client Queries With DoT or DoH
DNS over TLS and DNS over HTTPS protect the path between a client and its resolver from eavesdropping and tampering. The standards are stable and well documented: RFC 7858 covers DoT and RFC 8484 covers DoH. On managed networks, decide deliberately whether to allow third-party DoH resolvers or force traffic through your own encrypted resolver. Unmanaged DoH silently defeats content filtering, which is a governance problem as much as a technical one.
5. Patch and Track Server Software
BIND and Unbound are the two most widely deployed open-source DNS servers, and both ship security fixes regularly. Subscribe to vendor advisories, track versions in your inventory, and patch on a defined schedule. If you run home or small-office gear alongside work devices, the same discipline applies to consumer routers; the guidance in this roundup of the best internet security tools in Australia covers the network side of that equation.
6. Log Queries and Watch for Anomalies
Query logging is cheap and revealing. Look for sudden spikes in NXDOMAIN responses, long random subdomains (a hallmark of DNS tunneling), and query bursts to a single domain. Retain logs long enough to investigate incidents, and ship them somewhere an attacker cannot delete them locally. (Domain Name System)
7. Harden the Registrar and Zone Management Layer
Many DNS incidents never touch a server. They start at the registrar account. Enable registrar lock, require multi-factor authentication, restrict who can change nameservers, and monitor certificate transparency logs for unexpected issuance against your domains. Domain hijacking is a business continuity event, not an IT annoyance.
8. Separate Internal and External Namespaces
Split-horizon DNS keeps internal names off the public internet. Pair it with clear naming conventions so a hostname never accidentally reveals architecture. If you manage a home network or a small office, the same principle applies at a smaller scale; the picks in this guide to home security systems show how consumer gear increasingly exposes network settings that deserve a review.
Common Mistakes That Undermine a DNS Security Program
Even teams with a checklist in hand stumble on the same handful of issues. Watch for these:
- Hardening one layer and ignoring the rest. A signed zone means little if the registrar account uses a shared password.
- Assuming the cloud provider handles everything. Providers secure the platform, not your zone contents or your access keys.
- Skipping the outside-in test. Confirm recursion restrictions and transfer rules from an external vantage point, not from a laptop inside the firewall.
- Treating DNSSEC as a one-time project. Key rollovers and algorithm updates need an owner and a calendar.
- Forgetting endpoints. A single misconfigured device using an unapproved DoH resolver can bypass your entire filtering strategy.
How to Roll This Out Without Breaking Production
A DNS change can take down email, VPN, and authentication in minutes, so sequence matters. A workable order looks like this:
- Complete the inventory and document current behavior.
- Restrict recursion and zone transfers, then verify from outside.
- Enable query logging and establish a baseline.
- Turn on DNSSEC validation in monitoring mode, fix what breaks, then enforce.
- Sign your own zones, starting with low-risk ones.
- Standardize encrypted client queries and document the policy.
- Lock down registrar access and review it quarterly.
Each step is reversible, which keeps the change advisory board friendly. The verification step after each change is not optional; it is where most surprises get caught.
Where DNS Fits in a Broader Security Stack
DNS is one control among many, and it interacts with everything else. Identity systems, endpoint protection, and network monitoring all depend on accurate name resolution. If your organization is tightening its overall posture, the comparison of non-human identity security platforms is worth reading, because service accounts and API keys often have DNS-level access that nobody audits. Similarly, teams building out physical and network monitoring should look at outdoor security cameras without a subscription, since camera firmware frequently phones home through DNS and deserves the same scrutiny as any other endpoint. (Secure Domain Name System (DNS) Deployment Guide)
The through-line is visibility. DNS logs are one of the few data sources that see nearly every connection attempt, which makes them valuable well beyond the DNS team.
FAQ
What is the single most important item on a DNS security checklist?
Restricting recursion to trusted clients. It is quick to implement, easy to verify, and removes a major attack surface. DNSSEC validation is a close second, but it takes longer to roll out safely.
Is DNSSEC mandatory for every organization?
No, but it is strongly recommended for any organization with a public-facing domain. Validation protects your users from forged answers, and signing protects your brand from impersonation. The main barrier is operational discipline around key management, not the technology itself.
How often should DNS configurations be reviewed?
At least quarterly, plus after any major infrastructure change. Registrar access, DNSSEC key status, and recursion rules are the three areas most likely to drift between reviews.
Does DNS over HTTPS make a network less secure?
It can, if unmanaged. DoH protects queries in transit, but it also bypasses local filtering and logging. The fix is policy: either route DoH through your own resolver or explicitly block third-party DoH endpoints on managed devices.
Can small businesses skip most of this checklist?
They can skip the complexity, not the basics. Closing open recursion, patching servers, locking the registrar account, and enabling logging are all achievable with modest effort. DNSSEC signing can wait until the fundamentals are stable.
How do I know if my DNS is being abused for amplification attacks?
Watch for large volumes of responses to spoofed source addresses, unusually high query rates, and complaints from external parties about traffic originating from your network. Restricting recursion and enabling response rate limiting are the standard mitigations.
Conclusion
DNS security is unglamorous work. There is no dramatic dashboard moment, no single product that solves it, and the reward for doing it well is that nothing happens. That is precisely why it gets neglected until an incident forces the issue. A DNS security checklist works best when it is short enough to finish and specific enough to verify: close recursion, validate DNSSEC, lock transfers, encrypt client queries, patch promptly, log everything, and guard the registrar account like the keys to the building.
Start with the inventory. Pick two items you can complete this month. Test each change from outside your network, and write down what you verified. Six months of steady, boring progress beats a frantic weekend after a hijacking. The attackers are already scanning; the checklist is how you make sure they find nothing worth taking.
The final item on that list deserves a standing calendar entry rather than a one-off check. Registrar credentials age badly, staff turnover erodes who holds access, and renewal dates slip past unnoticed. Automate expiry reminders and access reviews wherever your registrar allows it, and keep a documented recovery path in case the account is locked during an attack.
Measuring Whether the Checklist Actually Works
A checklist you never test is just a document. Define a few measurable signals and review them on a fixed cadence: the percentage of zones signed, the number of resolvers accepting queries from outside your networks, mean time to patch after a DNS advisory, and the count of devices bypassing your resolver. Trend lines matter more than absolute numbers, because they show whether drift is creeping back in. After any incident, add a line item to the checklist rather than a note in a wiki nobody reads.
Final Word
None of these controls is exotic. Every one of them is documented in an RFC, supported by mainstream software, and achievable by a small team working steadily. What separates organizations that survive a DNS incident from those that do not is rarely sophistication; it is the habit of verifying that yesterday’s configuration is still in place today. Build the inventory, close the obvious holes, test from the outside, and repeat. That discipline, applied consistently, is the whole of DNS security in practice.
Automate the reminder emails and access reviews, and store the recovery codes somewhere offline that survives a ransomware event. Treat the registrar like the root of trust it is, because every other control on this list assumes you still own the domain. ## Measuring Whether the Checklist Actually Works A checklist you never test is just a document. Define a few measurable signals and review them on a fixed cadence: the percentage of zones signed, the number of resolvers accepting queries from outside your networks, mean time to patch after a DNS advisory, and the count of devices bypassing your resolver. Trend lines matter more than absolute numbers, because they show whether drift is creeping back in. After any incident, add a line item to the checklist rather than a note in a wiki nobody reads. ## Final Word None of these controls is exotic. Every one of them is documented in an RFC, supported by mainstream software, and achievable by a small team working steadily. What separates organizations that survive a DNS incident from those that do not is rarely sophistication; it is the habit of verifying that yesterday’s configuration is still in place today. Build the inventory, close the obvious holes, test from the outside, and repeat. That discipline, applied consistently, is the whole of DNS security in practice.
