When a website suddenly redirects visitors to a scam page, or email starts vanishing into thin air, how often does anyone suspect the domain name system? Almost never, and that is exactly the problem. DNS is the internet’s phone book, quietly translating names like example.com into the numeric addresses machines use. It was built for speed and reliability, not for security. Attackers know this, which is why DNS hijacking, cache poisoning, and domain takeover keep showing up in breach reports year after year.
The good news is that most DNS attacks are preventable with a handful of well-understood controls. The bad news is that many organizations deploy only one or two of them and assume they are covered. This guide walks through the practices that genuinely reduce risk, the mistakes that quietly undo them, and how to prioritize when budgets and time are tight.
Why DNS Is Such a Tempting Target
DNS sits at the center of nearly every connection. If an attacker controls how a name resolves, they control where traffic goes, even when the destination server itself is perfectly secure. A single tampered record can redirect a bank’s customers, intercept password reset emails, or let someone pass a domain validation check and obtain a legitimate TLS certificate.
The 2019 wave of DNS infrastructure tampering that the U.S. Cybersecurity and Infrastructure Security Agency warned about followed a recognizable pattern: attackers gained access to DNS accounts, changed records, and harvested credentials. Nothing about the underlying servers was broken. The control plane was.
That is the mental model worth keeping. DNS security is less about patching a server and more about protecting the accounts, records, and resolution paths that decide where users end up.
Lock Down the Control Plane First
Before touching protocol-level defenses, secure the accounts that can change DNS records. In practice, this is where most incidents begin.
Enforce multi-factor authentication everywhere
Every registrar, DNS provider, and hosting panel account that can edit records needs multi-factor authentication, preferably a hardware security key rather than SMS codes. SIM swapping is a real and routine attack, and text-message codes fall to it.
Use registrar locks
A registrar lock (sometimes called a client transfer lock) prevents unauthorized domain transfers. Turn it on for every domain. It costs nothing and blocks a whole category of takeover attempts.
Limit who can edit records
Most organizations have far more people with DNS edit rights than they realize. Audit the list quarterly. Apply least privilege so a compromised marketing contractor account cannot rewrite the MX records.
Monitor certificate transparency logs
When someone changes DNS records to pass a domain validation challenge, a new certificate often appears. Watching certificate transparency logs for unexpected issuance tied to your domains gives early warning. Free monitoring services exist, and the signal-to-noise ratio is manageable once tuned.
A practical tip from teams that handle this well: keep a documented “known good” snapshot of your zone file and alert on any diff. Unexpected record changes should page someone, not sit in a log.
Deploy DNSSEC, but Understand Its Limits
DNSSEC adds cryptographic signatures to DNS data. Resolvers can then verify that a response actually came from the zone owner and was not altered in transit. The root zone has been signed since 2010, and many top-level domains support it.
DNSSEC stops cache poisoning and record forgery. It does not encrypt queries, and it does not stop a hijacker who legitimately controls your DNS account from signing malicious records. It is one layer, not a complete answer.
The operational trap is key management. Signing a zone and then letting signatures expire causes outages, sometimes total ones. Before enabling DNSSEC:
- Confirm the registrar supports DS record publication.
- Automate key rollover and signature refresh.
- Test resolution through multiple public resolvers before and after.
- Have a documented rollback path.
Organizations that skip the testing step frequently discover problems only when customers report that the site is unreachable. That is an expensive way to learn.
Encrypt Resolution with DoH and DoT
Traditional DNS queries travel in plaintext. Anyone on the path, from a coffee shop router to an internet provider, can read them and tamper with them. Two standards fix that:
- DNS over TLS (DoT), standardized as RFC 7858 in May 2016, wraps queries in a TLS tunnel on a dedicated port.
- DNS over HTTPS (DoH), standardized as RFC 8484 in October 2018, sends queries over HTTPS, blending them with ordinary web traffic.
A third option, DNS over QUIC (DoQ), was standardized as RFC 9250 in June 2022. Adoption remains limited compared with DoH and DoT, but it is worth watching.
For enterprises, DoT is often the easier choice because it can be enforced at the network edge on a known port. For remote workers and browsers, DoH is usually already active by default. The practical guidance is to pick one, enforce it consistently, and make sure your internal resolvers support it. Mixed configurations create blind spots where some queries are encrypted and others are not.
If you are evaluating broader network protection alongside DNS controls, resources on the best internet security australia options cover how DNS filtering fits into a layered defense.
Segment Internal DNS from External DNS
A recurring design mistake is running one DNS infrastructure for both public-facing and internal names. When an attacker compromises the external zone, they gain a foothold next to internal records.
Split the roles:
| Layer | Purpose | Key controls |
|---|---|---|
| Authoritative external | Public records for your domains | DNSSEC, registrar lock, change alerts, minimal edit access |
| Recursive internal | Resolving queries for staff and systems | DoT or DoH, query logging, response policy zones |
| Authoritative internal | Private namespace records | Network isolation, no internet exposure |
Response policy zones (RPZ) deserve a mention here. Originally a BIND feature, RPZ lets you override resolution for known-bad domains at the resolver level. It is a fast way to block phishing infrastructure across an entire organization without touching every endpoint.
Monitor, Log, and Hunt for Anomalies
DNS logs are among the most underused security telemetry available. Every malware family that beacons home needs to resolve a name first. Query logs, retained and analyzed, catch command-and-control traffic that endpoint tools miss.
What actually works in practice:
- Enable query logging on internal resolvers and ship it to your SIEM.
- Baseline normal query volume per host and alert on spikes.
- Watch for high-entropy subdomains, a hallmark of DNS tunneling.
- Monitor for lookups of newly registered domains, which feature heavily in phishing.
- Review authoritative zone changes daily, not monthly.
The common mistake is collecting logs and never querying them. Retention without analysis is storage cost, not security. Start with three or four high-value detections rather than a hundred noisy ones.
Remember That Routing Can Undo Everything
Here is a subtle point that trips up even experienced teams. DNSSEC protects the integrity of DNS data, but if an attacker hijacks the network route to your authoritative servers, resolution can still go wrong. BGP hijacking can redirect DNS traffic before DNSSEC validation ever happens. (DNSSEC: What Is It and Why Is It Important?)
The relevant control is RPKI, which lets networks cryptographically attest which address blocks they are authorized to originate. Publishing ROAs for your address space and monitoring for unauthorized announcements closes part of that gap. It is not a complete fix, but it raises the cost of the attack considerably.
This is also why organizations should treat DNS security as part of a wider resilience program. If you are mapping out physical and digital protection together, the guidance on home security systems offers a useful parallel on layering defenses rather than relying on one control.
Build a Practical Prioritization Plan
Not every team can do everything at once. A sensible sequence looks like this:
- Week one: Enable MFA on every registrar and DNS account. Turn on registrar locks.
- Month one: Audit edit permissions. Set up change alerting and a known-good zone snapshot.
- Quarter one: Enable DNSSEC with automated signing and tested rollback. Enforce DoT or DoH on internal resolvers.
- Quarter two: Stand up query logging with a small set of tuned detections. Publish ROAs.
- Ongoing: Review certificate transparency alerts, run tabletop exercises for domain takeover, and re-audit access quarterly.
If your organization is also formalizing oversight for automated systems, the principles in this guide to AI governance principles, risks, and best practices translate well to DNS change management: clear ownership, auditable decisions, and defined escalation paths.
Common Mistakes That Quietly Undo Good Work
A few patterns show up again and again in post-incident reviews:
- Signing a zone and forgetting the keys. Expired signatures cause outages that look like attacks.
- Leaving a legacy registrar account active. Old accounts with edit rights are a favorite entry point.
- Trusting a single resolver. If your only resolver is compromised or misconfigured, everything downstream fails.
- Skipping the rollback test. DNSSEC deployments that were never rolled back in a lab tend to fail in production.
- Assuming the cloud provider handles it. Shared responsibility means you still own record integrity and account security.
None of these require exotic tools to fix. They require someone to own the checklist and actually run it.
Conclusion
DNS security is unglamorous work, and that is precisely why it gets neglected until something breaks. The controls that matter most are not advanced: multi-factor authentication on registrar accounts, registrar locks, least-privilege record access, DNSSEC with disciplined key management, encrypted resolution through DoT or DoH, and query logging that someone actually reads.
Layer them. Test them. Write down what “normal” looks like so you can spot when it changes. Attackers target DNS because it is central and often soft. A team that locks the control plane, signs its zones, encrypts resolution, and watches the logs has closed most of the realistic attack paths. The rest is maintenance, and maintenance is far cheaper than a hijacked domain.
Frequently Asked Questions
What is DNSSEC and do I really need it?
DNSSEC adds cryptographic signatures to DNS records so resolvers can verify that responses are authentic and unaltered. It defends against cache poisoning and record forgery. Most public-facing domains benefit from it, but only if key rollover and signature refresh are automated. A misconfigured DNSSEC deployment can take a domain completely offline, so test thoroughly before enabling it.
Is DNS over HTTPS better than DNS over TLS?
Neither is strictly better. DoT uses a dedicated port, which makes it easier for network administrators to enforce and monitor. DoH blends queries with regular HTTPS traffic, which improves privacy but can bypass network-level controls. Enterprises often standardize on DoT internally and accept DoH on managed browsers. The important thing is consistency, not picking a winner.
Can DNSSEC stop a domain hijacking?
Not on its own. DNSSEC protects the integrity of records once they are published, but if an attacker gains access to your registrar or DNS account, they can publish and sign malicious records legitimately. Preventing hijacking requires account-level controls: multi-factor authentication, registrar locks, least-privilege access, and alerting on unexpected record changes.
How often should DNS records be reviewed?
High-value records such as MX, SPF, DMARC, and any host handling authentication should be reviewed at least monthly, with automated alerting on every change. A full zone audit quarterly is reasonable for most organizations. The key practice is maintaining a known-good snapshot and diffing against it, so unexpected changes surface immediately rather than at the next scheduled review.
What is DNS tunneling and how is it detected?
DNS tunneling hides data inside DNS queries and responses, letting malware communicate with attackers even when other outbound traffic is blocked. Detection relies on spotting patterns: unusually long or high-entropy subdomains, abnormal query volume from a single host, and repeated lookups of the same unusual domain. Query logging shipped to a SIEM is the foundation for catching it.
Does moving to a cloud DNS provider make DNSSEC unnecessary?
No. Cloud providers handle availability and infrastructure, but the shared responsibility model still leaves record integrity and account security with you. A compromised administrator account at any provider can redirect traffic. DNSSEC, multi-factor authentication, and change monitoring remain necessary regardless of where the zone is hosted.
