DNS Security Best Practices — Protecting Your Domain

DNS was designed in an era when trust was assumed. There was no authentication, no encryption, and no verification that the server answering your query was legitimate. Decades later, DNS remains the backbone of the internet — and attackers know it. A compromised DNS record can redirect your users to a phishing site, intercept your email, or take your services offline entirely.

This guide covers 10 actionable security practices that protect your domains from the most common DNS threats, with verification steps you can run from your terminal today.

What You'll Learn

• The DNS attack surface and how different threats exploit it
• How to harden your DNS infrastructure against spoofing, hijacking, and DDoS
• Step-by-step DNSSEC deployment and verification
• How to set up DNS monitoring and alerting to catch issues early

Understanding the DNS Attack Surface

Before hardening your DNS, you need to understand where the threats come from. DNS is vulnerable at multiple layers — from the protocol itself to the accounts that manage it.

DNS is vulnerable across many record types and infrastructure layers:

For a deeper dive into each attack type, see DNS Attacks and Threats. The practices below address these threats systematically.

1. Enable DNSSEC

DNSSEC adds cryptographic signatures to DNS responses, allowing resolvers to verify that the answer they received is authentic and hasn't been tampered with in transit. Without DNSSEC, a resolver has no way to distinguish a legitimate response from a forged one.

What DNSSEC Protects Against

• Cache poisoning attacks
• Man-in-the-middle response tampering
• Forged DNS responses

How to Enable on DNScale

DNScale supports DNSSEC signing with ECDSA (algorithm 13). Enable it through the dashboard or API:

# Create signing keys via the DNScale API
curl -X POST https://api.dnscale.eu/v1/zones/{zone-id}/dnssec/keys \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"key_type": "ksk", "algorithm": 13, "bits": 256}'

After enabling, retrieve the DS record and add it at your registrar to complete the chain of trust.

Verify DNSSEC Is Working

# Check if the zone is signed
dig example.com DNSKEY +short
# Should return DNSKEY records
 
# Verify DNSSEC validation
dig example.com A +dnssec +short
# Look for the 'ad' (authenticated data) flag in the response
 
# Full validation check
dig example.com SOA +dnssec
# The 'ad' flag in the header confirms DNSSEC validation passed

After enabling DNSSEC, allow 24–48 hours for the DS record to propagate through the parent zone. Test validation with dig +dnssec before considering it fully active.

For a comparison of DNSSEC with transport-level encryption, see DNSSEC vs. DNS over HTTPS.

2. Use CAA Records

CAA (Certificate Authority Authorization) records specify which certificate authorities are allowed to issue SSL/TLS certificates for your domain. Without CAA, any CA in the world can issue a certificate for your domain — an attacker who compromises a CA could get a valid cert for your site.

Set Up CAA Records

# Allow only Let's Encrypt to issue certificates
example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
 
# Allow a specific CA for wildcard certificates
example.com.  3600  IN  CAA  0 issuewild "letsencrypt.org"
 
# Send violation reports to your security team
example.com.  3600  IN  CAA  0 iodef "mailto:security@example.com"

Verify CAA Records

dig example.com CAA +short
# 0 issue "letsencrypt.org"
# 0 issuewild "letsencrypt.org"
# 0 iodef "mailto:security@example.com"

If you use multiple CAs (e.g., Let's Encrypt for automated certs and DigiCert for EV certs), add a separate CAA record for each. An empty CAA record set means any CA can issue — always set explicit entries.

3. Implement SPF, DKIM, and DMARC

Email spoofing is one of the most common attacks that exploits DNS. An attacker can send emails that appear to come from your domain — phishing your employees, customers, or partners. Three DNS-based standards work together to prevent this.

For a full implementation guide, see SPF, DKIM, and DMARC.

SPF (Sender Policy Framework)

SPF declares which mail servers are authorized to send email for your domain via a TXT record:

# Only allow your mail server and Google Workspace
example.com.  3600  IN  TXT  "v=spf1 mx include:_spf.google.com -all"

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to outgoing emails. The public key is published as a TXT record:

selector._domainkey.example.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjAN..."

DMARC (Domain-based Message Authentication)

DMARC ties SPF and DKIM together and tells receivers what to do with failing messages:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Verify All Three

# Check SPF
dig example.com TXT +short | grep spf
# "v=spf1 mx include:_spf.google.com -all"
 
# Check DKIM (replace 'selector' with your actual selector)
dig selector._domainkey.example.com TXT +short
# "v=DKIM1; k=rsa; p=MIIBIjAN..."
 
# Check DMARC
dig _dmarc.example.com TXT +short
# "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

4. Use Anycast DNS

A DNS server at a single location is an easy DDoS target. Anycast DNS distributes your DNS across multiple global locations using the same IP addresses. When a resolver queries your domain, the response comes from the nearest node — and if one node is under attack, traffic routes to the next closest.

Why Anycast Matters for Security

• DDoS absorption — Attack traffic is spread across all nodes, not concentrated on one
• Geographic redundancy — No single point of failure
• Reduced latency — Faster responses mean shorter windows for spoofing attacks

DNScale's anycast network spans multiple points of presence across Europe and North America. Your zones are automatically served from all nodes — no configuration needed.

Verify Anycast Distribution

# Query from different resolvers to see responses from different nodes
dig @ns1.dnscale.eu example.com A +short
 
# Check response times from multiple locations
dig @ns1.dnscale.eu example.com A | grep "Query time"

5. Monitor DNS Changes

Unauthorized DNS changes can go unnoticed for days or weeks. An attacker who gains access to your DNS provider could add a new A record pointing your mail subdomain to their server, intercept email, and remove the record before anyone notices.

What to Monitor

• Record additions — New records that weren't part of a planned change
• Record modifications — Changes to existing A, MX, or NS records
• Record deletions — Removed records that could cause service outages
• Nameserver changes — Modifications to NS records or registrar delegation

Automated Monitoring

Set up periodic checks that compare your live DNS against your expected state:

#!/bin/bash
# dns-audit.sh — Compare live DNS against expected records
DOMAIN="example.com"
EXPECTED_IP="203.0.113.10"
 
ACTUAL_IP=$(dig +short $DOMAIN A)
if [ "$ACTUAL_IP" != "$EXPECTED_IP" ]; then
  echo "ALERT: $DOMAIN A record changed!"
  echo "Expected: $EXPECTED_IP"
  echo "Actual: $ACTUAL_IP"
  # Send alert via your preferred channel
fi

IaC Drift Detection

If you manage DNS with Terraform, drift detection is built in:

terraform plan -detailed-exitcode
# Exit code 0: no changes
# Exit code 2: drift detected — investigate immediately

DNScale's activity logging tracks every change to your zones, providing an audit trail of who changed what and when. See the Terraform provider guide for setting up automated management.

6. Lock Your Domain at the Registrar

Domain hijacking at the registrar level is one of the most damaging DNS attacks. If an attacker gains control of your domain, they can change nameservers, transfer the domain away, or point it anywhere they want. Two locks prevent this.

Transfer Lock (Client Transfer Prohibited)

Most registrars enable this by default. It prevents the domain from being transferred to another registrar without explicit authorization.

# Verify transfer lock is active
dig example.com ANY +short @whois.example.com
# Or check via WHOIS
whois example.com | grep -i "status"
# Should show: clientTransferProhibited

Registry Lock

Registry lock is a stronger protection available for many TLDs. It requires out-of-band verification (phone call, signed request) before any changes to NS records, DS records, or contact information. Contact your registrar to enable it.

Registry lock costs extra at most registrars, but for production domains that generate revenue, it is cheap insurance against domain hijacking.

7. Use Strong Authentication

Your DNS is only as secure as the accounts that manage it. A compromised registrar or DNS provider account gives an attacker full control of your domains.

Enable Two-Factor Authentication

Enable 2FA on every account that touches your DNS:

• Domain registrar — Where NS records and domain ownership live
• DNS provider (DNScale dashboard) — Where your zone records are managed
• Email account for the domain contact — Used for domain verification and transfer approvals

API Key Security

If you use the DNScale API, treat API keys like passwords:

• Store them in a secrets manager (AWS Secrets Manager, HashiCorp Vault), never in source code
• Rotate keys periodically
• Use separate keys for production and development
• Monitor API key usage for unusual patterns

8. Implement Rate Limiting

Rate limiting protects your authoritative DNS servers from query floods and DDoS attacks. Without it, an attacker can overwhelm your DNS with millions of queries per second.

Response Rate Limiting (RRL)

RRL limits the rate of identical responses to the same IP address, which directly counters DNS amplification attacks:

# Typical RRL configuration on authoritative servers
responses-per-second 10
window 15
slip 2

This means the server sends at most 10 identical responses per second to the same source. Additional queries receive truncated responses (forcing TCP) or are silently dropped.

Query Rate Limiting

Separate from RRL, query rate limiting caps the total queries from a single source:

# Verify your server handles rate limiting correctly
# This should NOT overwhelm the server
for i in $(seq 1 100); do dig @ns1.dnscale.eu example.com A +short; done

DNScale applies rate limiting at the edge automatically, so your zones are protected without any configuration on your part.

9. Conduct Regular DNS Audits

DNS records accumulate over time. Old records pointing to decommissioned servers, forgotten test subdomains, and stale CNAME records are all security risks.

Check for Stale Records

Records pointing to IPs or hostnames you no longer control are attack vectors. An attacker can claim the old IP or cloud resource and receive traffic intended for your domain.

# List all A records and verify each IP is still yours
dig example.com A +short
dig www.example.com A +short
dig api.example.com A +short
dig staging.example.com A +short
 
# For each IP, verify ownership
whois 203.0.113.10 | grep -i "org"

Detect Dangling CNAMEs

A dangling CNAME points to a hostname that no longer exists — typically a decommissioned cloud resource. An attacker can register that resource and take over your subdomain:

# Check if CNAME targets resolve
dig blog.example.com CNAME +short
# Returns: example.github.io.
 
# Verify the target still exists
dig example.github.io A +short
# If this returns NXDOMAIN, the CNAME is dangling — remove it immediately

Audit Checklist

Run these checks quarterly:

• All A/AAAA records point to IPs you control
• All CNAME records resolve to valid targets
• MX records point to active mail servers
• SPF, DKIM, and DMARC records are current
• CAA records reflect your current CA policy
• No unauthorized TXT records have been added
• DNSSEC signatures are valid and not near expiry
• Unused subdomains have been removed

10. Set Up DNS Monitoring and Alerting

Monitoring catches what prevention misses. Even with all the practices above in place, you need visibility into your DNS health.

External Monitoring

Monitor DNS resolution from multiple geographic locations to catch outages and performance issues:

# Check resolution from different public resolvers
dig @8.8.8.8 example.com A +short      # Google
dig @1.1.1.1 example.com A +short      # Cloudflare
dig @9.9.9.9 example.com A +short      # Quad9
 
# All should return the same result

DNSSEC Monitoring

If you use DNSSEC, monitor for signature validity and expiry:

# Check DNSSEC signature expiry
dig example.com RRSIG +short
# Look at the expiry date in the RRSIG record
 
# Validate the full chain
dig example.com A +dnssec +cd
# The 'ad' flag confirms validation passes

Alert on These Events

• DNS resolution failure from any monitoring location
• Record value changes that don't match your IaC configuration
• DNSSEC validation failures
• RRSIG expiry within 7 days
• Nameserver delegation changes
• New records added outside your IaC pipeline

Combine DNS monitoring with your existing alerting infrastructure (PagerDuty, Opsgenie, Slack). DNS failures are often the first symptom of a larger infrastructure issue.

How DNScale Helps

DNScale incorporates many of these practices by default or makes them easy to implement:

For managed DNS trade-offs, see Managed DNS vs. Self-Hosted DNS.

Quick Reference: Verification Commands

Keep these commands handy for verifying your DNS security posture:

# DNSSEC status
dig example.com DNSKEY +short
 
# CAA records
dig example.com CAA +short
 
# SPF record
dig example.com TXT +short | grep spf
 
# DMARC policy
dig _dmarc.example.com TXT +short
 
# Nameserver delegation
dig example.com NS +short
 
# Check for open zone transfer (should fail)
dig @ns1.dnscale.eu example.com AXFR
# Expected: "Transfer failed"
 
# Full DNS record audit
dig example.com ANY +noall +answer

Conclusion

DNS security is not a single action but a layered defense. No single practice protects against every threat — DNSSEC stops cache poisoning but not DDoS; anycast absorbs DDoS but not domain hijacking; registry lock prevents hijacking but not dangling CNAMEs. Implement all ten practices to cover the full attack surface. Start with the highest-impact items — enable DNSSEC, set CAA records, configure SPF/DKIM/DMARC — and work through the rest systematically. Review your DNS security posture quarterly, because the threat landscape evolves and so should your defenses.