What if the biggest hole in your security setup is the one service you never think about? Domain Name System (DNS) is the internet’s phone book, quietly translating names like example.com into the numeric addresses computers use. It is also one of the most overlooked attack surfaces in modern IT. When DNS goes wrong, it rarely makes noise. There is no dramatic alert, no flashing red dashboard. Instead, an attacker quietly redirects traffic, poisons a cache, or hijacks a domain, and the damage surfaces weeks later.
The uncomfortable truth is that most DNS incidents trace back to a short list of repeatable mistakes. None of them require advanced hacking skills to exploit. This article walks through the most common DNS security mistakes, why each one matters, and what actually works in practice. If you run a website, manage a corporate network, or just care about your home setup, these lessons apply to you.
Mistake 1: Leaving a Recursive Resolver Open to the World
An open resolver is a DNS server that answers recursive queries from anyone on the internet. It sounds helpful. It is actually a gift to attackers.
Open resolvers are the fuel behind DNS amplification attacks, a type of distributed denial-of-service (DDoS) technique. An attacker sends a small query with a spoofed source address, and the server fires a much larger response at the victim. Multiply that by thousands of servers and you have a flood that can knock a target offline. The Wikipedia entry on DNS amplification attacks explains the mechanics in plain terms.
The fix is straightforward but often skipped: restrict recursion to trusted internal clients only. On BIND, that means an explicit `allow-recursion` list. On Windows DNS, it means limiting recursion scope. Many administrators deploy a resolver, confirm it “works,” and never revisit the access controls. That is the mistake.
A quick practical check: query your own server from an external network and see whether it answers a recursive lookup for a domain it does not host. If it does, you have work to do.
Mistake 2: Treating DNSSEC as Optional
DNSSEC adds cryptographic signatures to DNS records so resolvers can verify that an answer is authentic and untampered. It has been standardized since 2005, yet adoption remains patchy, and many organizations that do sign their zones never validate responses on the resolver side.
That gap matters because cache poisoning attacks exploit the trust a resolver places in unverified answers. If an attacker can inject a forged record into a resolver’s cache, users get sent to the wrong place, sometimes for hours. DNSSEC validation is the control designed to stop that. (DNSSEC: What Is It and Why Is It Important?)
There is a second, subtler mistake here: signing a zone and then letting the signatures expire because nobody monitors them. An expired signature is worse than no signature at all, because validating resolvers will refuse to resolve the domain entirely. Set up expiry alerts. Test with public validation tools. And remember that DNSSEC protects integrity, not confidentiality, which brings us to the next point.
Mistake 3: Sending DNS Queries in Plain Text
Traditional DNS queries travel unencrypted over UDP port 53. Anyone on the path, whether a coffee shop Wi-Fi operator or an ISP, can see every domain you look up. That is a privacy leak, and it is also an attack vector: an on-path attacker can tamper with responses.
DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt queries in transit. They are not perfect, and enterprise teams sometimes resist them because they bypass local filtering. But ignoring encryption entirely on untrusted networks is a mistake. For individuals, enabling encrypted DNS in the browser or operating system is a five-minute change with real benefits. For organizations, the answer is usually a managed encrypted resolver rather than letting every device pick its own.
If you are comparing consumer-grade protection options, our guide to the best internet security in Australia covers how DNS filtering fits into a broader defense stack.
Mistake 4: Forgetting About Zone Transfers
A zone transfer (AXFR) copies an entire DNS zone from one server to another. It is essential for legitimate secondary servers. It is also a goldmine for reconnaissance when exposed to the public internet.
An attacker who can pull your zone learns every subdomain you own, including internal-sounding names like `vpn`, `staging`, `jenkins`, or `admin`. That is a ready-made target list. The mistake is leaving AXFR open to any source rather than restricting it to known secondary server IP addresses.
Test it yourself with a simple `dig AXFR` against your authoritative server from an outside network. If it dumps the zone, lock it down today. This is one of the few DNS mistakes that takes minutes to fix and removes a whole category of risk.
Mistake 5: Dangling DNS Records and Subdomain Takeover
Here is a scenario that plays out constantly. A team spins up a marketing microsite on a cloud provider, points `promo.example.com` at it with a CNAME record, then decommissions the cloud resource months later. The DNS record stays. The cloud host reassigns that resource name to someone else. Now a stranger controls content served from your domain.
This is called subdomain takeover, and it is one of the most common DNS security mistakes because it happens through normal business activity. Nobody does anything wrong on purpose. The record simply outlives the service.
What works in practice:
- Inventory every DNS record and tag each one with an owner.
- Audit records quarterly against live infrastructure.
- Delete stale records as part of every decommissioning checklist.
- Monitor for CNAMEs pointing at unclaimed cloud resources.
The lesson generalizes: DNS hygiene is a lifecycle problem, not a one-time setup task.
Mistake 6: Weak Registrar and Domain Account Security
Your DNS records are only as safe as the account that controls them. Yet plenty of organizations apply strict controls to their cloud consoles while leaving the domain registrar account protected by a shared password and no multi-factor authentication.
Domain hijacking through a compromised registrar account is devastating. An attacker changes nameservers, and your entire domain points wherever they choose. Recovery can take days and may involve legal processes.
Practical safeguards that actually hold up:
| Control | Why it matters |
|---|---|
| Multi-factor authentication on registrar accounts | Blocks credential-stuffing and phishing takeovers |
| Registry lock | Adds an out-of-band verification step for nameserver changes |
| Dedicated, monitored contact email | Prevents missed transfer or change notices |
| Least-privilege access | Limits blast radius if one account is compromised |
The pattern here mirrors general account security. If you want a broader frame for protecting connected devices and accounts at home, the picks in our roundup of home security systems show how layered controls reduce single points of failure.
Mistake 7: No DNS Logging or Monitoring
You cannot investigate what you never recorded. Many networks log firewall events and authentication attempts in detail but keep almost no DNS query logs. That blind spot is exactly where attackers like to operate.
DNS is a favorite channel for data exfiltration and command-and-control traffic because it is almost always allowed outbound. Malware can encode stolen data in query names and receive instructions in responses, all while looking like ordinary lookups. Without query logging and anomaly detection, this traffic blends into the noise.
What to monitor in practice:
- Sudden spikes in queries to a single domain
- Unusually long or high-entropy query names
- Lookups for newly registered domains
- Repeated NXDOMAIN responses from one host
Enable query logging on resolvers, ship the logs to a central system, and set a retention window long enough to support investigations. Then actually review alerts. Logging without monitoring is just expensive storage.
Mistake 8: Ignoring CAA and Email Authentication Records
Two record types get skipped constantly, and both create real exposure.
CAA records tell certificate authorities which CAs are allowed to issue certificates for your domain. Without them, any CA can issue a certificate for your name if it can pass validation. CAA does not stop a determined attacker, but it narrows the path considerably and catches mis-issuance.
SPF, DKIM, and DMARC records protect your domain’s email reputation. The most common mistake is publishing a DMARC record with a policy of `p=none`, which monitors but does not enforce. That is a reasonable starting point, but organizations often leave it there for years. Moving to `p=quarantine` and eventually `p=reject` is what actually stops spoofing.
A related trap: SPF records with too many DNS lookups, which fail silently and break legitimate mail. Audit them regularly rather than setting and forgetting.
Mistake 9: Default Credentials and Unauthenticated DNS Updates
DNS update requests let clients register their own records, which helps on networks with roaming devices. Those updates are dangerous when left unauthenticated. An attacker on the network can register records, overwrite existing entries, or impersonate internal hosts.
The fix is to require authenticated updates, typically through TSIG keys or Kerberos-based security. And if you use TSIG, do not leave the default or shared key in place across every server. Rotate keys, scope them to specific operations, and store them properly.
Default credentials on DNS management interfaces are their own category of mistake. Change them. Restrict management access to a dedicated network. This is basic, and it is still missed.
Mistake 10: Skipping the Basics of Redundancy and Change Control
A DNS outage is a security event in its own right. When resolution fails, users lose access to services, and teams under pressure make hasty changes that introduce new errors.
Common operational mistakes include running a single authoritative server, making unreviewed changes during incidents, and having no rollback plan. Change control for DNS is not bureaucracy; it is how you avoid a typo taking down your entire domain.
If your team manages connected devices and access controls alongside DNS, the principles in our guide to smart locks for home security are a useful reminder: convenience features are only safe when paired with deliberate access rules.
A Practical Checklist
Rather than trying to fix everything at once, work through these in order of impact:
- Close open resolvers to external queries.
- Restrict zone transfers to known secondaries.
- Enable DNSSEC signing and validation, with expiry monitoring.
- Audit and delete dangling DNS records.
- Add MFA and registry lock to registrar accounts.
- Turn on query logging and build at least three anomaly alerts.
- Publish CAA records and move DMARC toward enforcement.
- Require authentication for DNS updates.
- Document a change and rollback process.
Most organizations find two or three of these gaps in the first afternoon. That is normal. The point is to start.
Conclusion
DNS security mistakes share a common thread: they are invisible until they are exploited. An open resolver, an expired signature, a forgotten CNAME, a registrar account without MFA. None of these look dramatic on a dashboard. All of them give attackers a foothold that is difficult to detect after the fact.
The good news is that the fixes are well understood, mostly inexpensive, and often quick. Start with the highest-impact items, close the obvious gaps, and build monitoring so the next mistake gets caught early. Treat DNS as a lifecycle you manage, not a service you configure once. That shift in mindset is what separates resilient networks from lucky ones.
Frequently Asked Questions
What is the most dangerous common DNS security mistake?
An open recursive resolver is arguably the most dangerous because it can be weaponized immediately in amplification attacks. Close second is a compromised registrar account, since it can redirect your entire domain. Both are high impact and both are fixable in under an hour.
How do I check if my DNS server is an open resolver?
Query your server from an external network for a domain it does not host. If it returns a full recursive answer, recursion is open. Repeat the test from a few different networks to be sure, then restrict `allow-recursion` to trusted internal ranges.
Does DNSSEC actually prevent attacks?
DNSSEC prevents cache poisoning and tampering by letting resolvers verify signatures. It does not encrypt queries, so it does not stop eavesdropping. It also creates a new operational risk: expired signatures cause outages. Sign, validate, and monitor expiry.
What is subdomain takeover and how do I prevent it?
It happens when a DNS record points at a cloud resource that has been deprovisioned and later claimed by someone else. Prevent it by inventorying records, auditing them against live infrastructure quarterly, and deleting stale entries during decommissioning.
Is encrypted DNS worth enabling?
For most people, yes. DoH and DoT hide queries from on-path observers and reduce tampering risk on untrusted networks. Organizations should use a managed encrypted resolver rather than letting every device choose independently, so filtering and logging stay intact.
How often should DNS records be reviewed?
At minimum quarterly, plus every time a service is retired. High-change environments benefit from monthly reviews. The key is tying record cleanup to your decommissioning checklist so stale entries never accumulate in the first place.
