DNS Security and Monitoring Guide

DNS is the single point of failure for every online service. When your DNS records are correct, users reach your servers. When they are wrong, whether through misconfiguration, expiry, or deliberate attack, your entire online presence disappears or, worse, your users get sent somewhere malicious.

The threat landscape for DNS has expanded significantly in recent years. Nation-state actors target DNS infrastructure for espionage. Criminal groups hijack DNS to steal credentials. Even routine operational mistakes, like accidentally deleting an A record, can take a site offline for hours while propagation catches up.

This guide covers the threats you need to understand, the monitoring you need in place, and the processes that keep your DNS secure and reliable.

---

The DNS threat landscape

DNS was designed in the 1980s without security as a consideration. The protocol transmits queries and responses in plaintext, has no built-in authentication, and relies on a chain of trust that is only as strong as its weakest link. [1] Understanding the threats helps you prioritize your defenses.

DNS hijacking

DNS hijacking occurs when an attacker changes your DNS records to point to their infrastructure instead of yours. Users who type your domain name are silently routed to the attacker's server, where they see a convincing replica of your site designed to harvest credentials.

Hijacking can happen at multiple levels:

• Registrar hijacking. The attacker gains access to your domain registrar account through stolen credentials, social engineering, or exploiting weak account security. Once in, they change the nameservers to ones they control. This is the most damaging form because it gives the attacker complete control over all DNS records.
• DNS provider hijacking. The attacker compromises your DNS hosting account and modifies individual records. They might change only the A record or MX record, leaving other records intact to avoid detection.
• Router or ISP hijacking. The attacker modifies DNS settings on a local router or compromises an ISP's DNS resolver to return incorrect responses for specific domains.

For a detailed breakdown, see DNS hijacking explained.

DNS cache poisoning

Cache poisoning (also called DNS spoofing) tricks a DNS resolver into storing incorrect records. When users query that resolver, they get the poisoned response and are sent to the attacker's server. [2]

The classic attack exploits the lack of authentication in DNS responses. An attacker floods a resolver with forged responses, hoping one arrives before the legitimate response. If successful, the forged record is cached and served to all users of that resolver until the TTL expires.

The Kaminsky attack, disclosed in 2008, showed that cache poisoning was far easier than previously thought and led to widespread deployment of source port randomization as a mitigation. [2] DNSSEC provides a more robust defense.

BGP hijacking affecting DNS

Border Gateway Protocol (BGP) hijacking can redirect traffic intended for DNS servers. By announcing false BGP routes, an attacker can intercept traffic to specific IP addresses, including the IP addresses of authoritative DNS servers or popular recursive resolvers. [3]

This was demonstrated in the 2018 attack on Amazon's Route 53 DNS service, where attackers hijacked BGP routes for a subset of Amazon's IP address space and used it to serve false DNS responses for a cryptocurrency wallet service. [3]

Domain expiry and lapsed registration

When a domain expires, an attacker can register it and gain complete control over all DNS records. This is not technically a DNS attack, but the effect is identical: the attacker controls where your domain name resolves.

Expired domains that previously hosted popular services are especially valuable to attackers because they inherit existing traffic, backlinks, and user trust.

DNS tunneling and data exfiltration

Attackers can abuse DNS queries to tunnel data out of compromised networks. Because DNS traffic is rarely blocked by firewalls, it provides a covert channel for command-and-control communication and data exfiltration. [4]

While this threat does not directly compromise your DNS records, monitoring for unusual DNS query patterns can help detect compromised hosts on your network.

DNSSEC: Signing the chain of trust

DNS Security Extensions (DNSSEC) add cryptographic authentication to DNS responses. When DNSSEC is enabled, each DNS response includes a digital signature that resolvers can verify, proving the response has not been tampered with. [5]

How DNSSEC works

DNSSEC creates a chain of trust from the root zone down to your domain:

1. The root zone is signed with a key managed by ICANN and Verisign.
2. Each TLD (.com, .org, .net) has its own signing keys, with a Delegation Signer (DS) record in the root zone pointing to them.
3. Your domain has its own signing keys, with a DS record in the TLD zone pointing to them.
4. Each DNS record in your zone is signed with your domain's key.

When a resolver receives a DNSSEC-signed response, it follows the chain of trust upward, verifying each signature until it reaches the root. If any signature is invalid, the response is rejected.

DNSSEC limitations

DNSSEC provides authentication (the response came from the legitimate source and was not modified) but not confidentiality (the response is still in plaintext). It also:

• Does not protect against registrar compromise. If an attacker gains access to your registrar, they can change your DNSSEC keys.
• Adds complexity to DNS management. Key rotation, signing zone files, and maintaining the chain of trust require operational effort.
• Can cause outages if misconfigured. An invalid DNSSEC signature causes resolvers to reject all responses for your domain, making the domain completely unreachable (worse than no DNSSEC at all).
• Has incomplete deployment. While adoption has grown, many domains still do not implement DNSSEC, and some resolvers do not validate signatures.

Should you enable DNSSEC?

For most domains, yes. The protection against cache poisoning and response tampering is valuable. But implement it carefully:

• Test in a staging environment first
• Use automated DNSSEC management if your DNS provider offers it
• Monitor DNSSEC validation status continuously
• Have a rollback plan for signature failures

See DNS security best practices for implementation guidance.

Monitoring for unauthorized changes

The core of DNS security monitoring is detecting changes to your DNS records that you did not authorize. A change to your A record, MX record, or NS record that was not initiated by your team could indicate a compromise.

What to monitor

Monitor every DNS record type associated with your domains:

• A and AAAA records. Changes to these records redirect your website traffic. This is the most common target for hijacking.
• NS records. A change to your nameserver records gives the attacker control over all other records. NS changes at the registrar level are the highest-severity event.
• MX records. Modified MX records redirect your email to the attacker's mail server, enabling email interception and phishing.
• TXT records. SPF, DKIM, and DMARC records are TXT records. Modifying them can enable email spoofing or disable security policies.
• CNAME records. A modified CNAME can redirect a subdomain to an attacker-controlled server.
• CAA records. Removing or modifying CAA records allows unauthorized SSL certificate issuance for your domain.
• SOA records. Changes to the Start of Authority record can indicate a zone transfer or nameserver change.

For how to inspect records manually, see how to check DNS records.

Monitoring frequency

The right monitoring frequency depends on the record type and your risk profile:

• NS and SOA records: Check at least every hour. Changes to these are the highest severity.
• A, AAAA, and MX records: Check every 1 to 6 hours depending on risk tolerance.
• TXT records (SPF, DKIM, DMARC): Check every 6 to 24 hours.
• All records: Run a comprehensive audit at least weekly. See DNS record audit.

For a deeper understanding of DNS monitoring approaches, see DNS monitoring explained and how to monitor DNS changes.

Baseline and diff

Effective monitoring starts with establishing a baseline: the known-good state of all your DNS records. Every subsequent check compares the current state against this baseline. Any difference triggers an alert.

This requires:

1. Documenting the expected state. Record every DNS record for every domain you manage. Include the record type, value, and TTL.
2. Automated comparison. Regularly query your DNS records and compare them against the documented baseline.
3. Alert on any difference. Even "minor" changes (like a TTL change) can be significant. Alert on everything and triage from there.

DNS change management

Not all DNS changes are attacks. Most are legitimate operations: updating A records during a migration, adding TXT records for email authentication, modifying CNAMEs for new services. The challenge is distinguishing authorized changes from unauthorized ones.

The change management process

1. Request. All DNS changes should start with a documented request that includes the domain, record type, old value, new value, reason, and requester.
2. Review. A second person reviews the change for correctness. Typos in DNS records are a common cause of outages, and a second pair of eyes catches most of them.
3. Approve. For critical domains, require explicit approval from a designated owner before changes are made.
4. Implement. Make the change using your DNS provider's interface or API.
5. Verify. Confirm the change propagated correctly. Check from multiple DNS resolvers. See check DNS propagation.
6. Document. Update your baseline documentation to reflect the new expected state.

For a detailed framework, see DNS change management.

Access control

Limit who can make DNS changes:

• Use multi-factor authentication on all DNS provider and registrar accounts
• Implement the principle of least privilege (not everyone needs full DNS access)
• Use API keys with scoped permissions where possible
• Enable audit logging to track who made what changes and when
• Use registrar lock (also called domain lock) to prevent unauthorized transfers and NS changes

Propagation monitoring

After making an authorized DNS change, monitor DNS propagation to confirm it has reached resolvers globally. Propagation delays can cause confusing behavior where the change works from some locations but not others.

The propagation time depends on the TTL (Time to Live) of the old record. Resolvers cache records for the duration of the TTL, so a record with a 24-hour TTL may take up to 24 hours to propagate fully. For planned changes, lower the TTL in advance (at least one full TTL period before the change) to speed up propagation.

See what happens when DNS changes and DNS caching and TTL for more detail.

Multi-provider DNS strategy

Relying on a single DNS provider creates a single point of failure. If your DNS provider experiences an outage, your domains become unreachable even though your servers are running fine.

Why use multiple providers

The 2016 Dyn DDoS attack took down DNS for hundreds of major websites including Twitter, Netflix, and Reddit. [6] Every site that relied solely on Dyn for DNS was affected. Sites that used multiple DNS providers remained reachable.

Multiple providers protect against:

• Provider outages. Hardware failures, software bugs, and DDoS attacks at your DNS provider
• Network partitions. Connectivity issues that prevent some users from reaching your provider's nameservers
• Targeted attacks. DDoS attacks specifically targeting your DNS provider

For implementation details, see multi-DNS provider strategy.

Implementation approaches

Active-active. Both providers serve your DNS records simultaneously. Your domain's NS records list nameservers from both providers. If one fails, resolvers automatically fail over to the other.

Active-passive. One provider is primary, and the secondary only activates if the primary fails. This is simpler to manage but requires manual or automated failover.

DNS provider with anycast. Using a single provider that operates an anycast network (where the same IP address is announced from multiple geographic locations) provides resilience against regional outages, though not against provider-wide failures.

Keeping providers in sync

The challenge with multiple providers is keeping records synchronized. Options include:

• Zone transfer (AXFR/IXFR). The traditional method where one provider sends zone updates to the other. Not all providers support this as a secondary.
• API-based synchronization. Use automation to push changes to both providers simultaneously via their APIs.
• Infrastructure-as-code. Define your DNS records in code (Terraform, Pulumi, CloudFormation) and deploy to both providers from the same source.

Whichever method you choose, monitor that both providers are serving consistent records. A drift between providers means failover will serve different records, which can be confusing and disruptive.

Incident response for DNS attacks

When you detect an unauthorized DNS change, the response needs to be fast and structured. DNS attacks can enable credential theft, email interception, and malware distribution every minute they remain active.

Confirmation

Before declaring an incident, confirm the change is real and not a monitoring false positive:

1. Query the records from multiple independent resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1, your ISP's resolver). See public DNS providers.
2. Check the authoritative nameservers directly using dig or nslookup. See the nslookup command guide.
3. Verify whether anyone on your team made the change (check your change management log and DNS provider's audit log).

Containment

If the change is confirmed as unauthorized:

1. Lock the domain. Enable registrar lock immediately to prevent further changes.
2. Change all credentials. Reset passwords and API keys for your DNS provider and registrar. Enable MFA if not already active.
3. Revert the DNS changes. Restore records to the known-good baseline from your documentation.
4. Lower TTLs. Set TTLs to their minimum value so the corrected records propagate as quickly as possible.
5. Notify your SSL CA. If NS or A records were changed, the attacker may have used the hijacked domain to issue fraudulent SSL certificates. Check Certificate Transparency logs for any certificates issued during the compromise window.

Recovery

After the immediate threat is contained:

1. Monitor aggressively. Increase monitoring frequency to detect any further unauthorized changes.
2. Investigate the root cause. How did the attacker gain access? Stolen credentials, phished support staff, API key leak, registrar vulnerability?
3. Revoke compromised certificates. If the attacker issued certificates during the hijack, contact the CAs to revoke them.
4. Notify affected users. If the hijack was active long enough for users to interact with the attacker's infrastructure, those users may have had credentials stolen. Notify them to change passwords.
5. Review DNS security best practices. Ensure your defenses address the attack vector that was exploited.

DNS monitoring tools and approaches

Command-line tools

For ad-hoc investigations:

• dig is the standard tool for DNS queries. See how to check DNS records.
• nslookup provides a simpler interface for basic lookups. See the nslookup command guide.
• whois reveals domain registration information including nameservers and registrar. Useful for investigating potential registrar-level compromises.

Automated monitoring

For continuous monitoring, you need automated systems that:

• Check records at regular intervals from multiple geographic locations
• Compare current records against a documented baseline
• Alert on any discrepancy
• Track changes over time for audit and forensic purposes
• Monitor uptime as a secondary indicator of DNS problems (since DNS failures manifest as availability failures)

What good monitoring looks like

A mature DNS monitoring setup includes:

1. Record monitoring. Automated checks of all record types for all domains, at least hourly.
2. Propagation monitoring. After authorized changes, verification that the change has propagated to major resolvers.
3. DNSSEC validation monitoring. If DNSSEC is enabled, continuous verification that signatures are valid and the chain of trust is intact.
4. Certificate monitoring. SSL certificate monitoring for CAA record compliance and unauthorized certificate issuance.
5. Nameserver health monitoring. Verification that your authoritative nameservers are responding correctly.
6. Audit logging. A complete record of all DNS changes, who made them, and when.

Building a DNS security program

Bringing all of these elements together into a coherent program:

Immediate actions

• Enable MFA on all registrar and DNS provider accounts
• Enable registrar lock on all domains
• Document a baseline of all DNS records
• Set up automated DNS monitoring
• Implement a DNS change management process

Short-term improvements

• Evaluate and implement DNSSEC for your most critical domains
• Configure CAA records to restrict certificate issuance
• Set up Certificate Transparency log monitoring
• Review and restrict DNS access permissions
• Run a DNS record audit

Long-term goals

• Evaluate multi-provider DNS for critical domains
• Implement infrastructure-as-code for DNS management
• Integrate DNS monitoring into your incident response playbook
• Conduct tabletop exercises for DNS compromise scenarios
• Review and update your program quarterly

DNS security is not a one-time project. It is an ongoing practice that evolves as threats change and your infrastructure grows. Regular DNS troubleshooting and auditing keep your defenses current.

---

References

[1] P. Mockapetris, "Domain Names - Concepts and Facilities," RFC 1034, IETF, November 1987. https://datatracker.ietf.org/doc/html/rfc1034

[2] D. Kaminsky, "Black Ops of TCP/IP 2008," presented at Black Hat USA, 2008. https://www.blackhat.com/presentations/bh-jp-08/bh-jp-08-Kaminsky/BlackHat-Japan-08-Kaminsky-DNS08-BlackOps.pdf

[3] Cloudflare, "BGP hijacking," Cloudflare Learning Center. https://www.cloudflare.com/learning/security/glossary/bgp-hijacking/

[4] SANS Institute, "Detecting DNS Tunneling," SANS Reading Room. https://www.sans.org/white-papers/detecting-dns-tunneling/

[5] R. Arends et al., "DNS Security Introduction and Requirements," RFC 4033, IETF, March 2005. https://datatracker.ietf.org/doc/html/rfc4033

[6] Dyn, "Dyn Analysis Summary Of Friday October 21 Attack," Oracle Dyn Blog, October 2016. https://dyn.com/blog/dyn-analysis-summary-of-friday-october-21-attack/

[7] ICANN, "KSK Rollover," ICANN.org. https://www.icann.org/resources/pages/ksk-rollover

[8] Google Public DNS, "Introduction to Google Public DNS." https://developers.google.com/speed/public-dns/docs/intro