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 data, allowing validating resolvers to verify that an answer came from the signed zone and has not been tampered with. Without DNSSEC, a resolver has no cryptographic way to distinguish a legitimate response from a forged one.

What DNSSEC Protects Against

• Cache poisoning against signed records when resolvers validate DNSSEC
• On-path tampering with signed DNS data
• Forged DNS responses for signed zones with an intact chain of trust

How to Enable on DNScale

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

# Enable DNSSEC signing via the DNScale API
curl -X PATCH https://api.dnscale.eu/v1/zones/{zone_id}/dnssec/status \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"enable": true}'

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

curl https://api.dnscale.eu/v1/zones/{zone_id}/dnssec/ds \
  -H "Authorization: Bearer YOUR_API_KEY"

Verify DNSSEC Is Working

# Check if the zone is signed
dig example.com DNSKEY +short
# Should return DNSKEY records
 
# Verify DNSSEC validation through a validating resolver
dig @1.1.1.1 example.com A +dnssec
# Look for the 'ad' (authenticated data) flag in the response header
 
# Full validation check
delv @1.1.1.1 example.com SOA
# The output should report that the answer is fully validated

After enabling DNSSEC, allow 24–48 hours for the DS record to propagate through the parent zone. Test through a validating resolver and confirm the ad flag 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 authorized to issue public TLS certificates for your domain. Without an applicable CAA policy, any publicly trusted CA that completes normal domain validation can issue a certificate for your domain. CAA narrows that set and gives you a DNS-published issuance policy.

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. If no applicable CAA RRset exists for the name or its ancestors, public CAs treat issuance as unrestricted by CAA. Set explicit entries for production domains.

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 authenticate legitimate senders and tell receivers how to handle mail that fails alignment. They reduce domain spoofing, but receiver enforcement and forwarding behavior still matter.

For a full implementation guide, see SPF, DKIM, and DMARC, plus the dedicated SPF, DKIM, and DMARC pages.

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 to the visible From: domain and tells receivers your preferred handling for messages that fail DMARC validation:

_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 locations using the same IP addresses. When a resolver queries your domain, routing usually sends it to a topologically close node. If a node fails or is withdrawn from routing, traffic can move to another reachable node.

Why Anycast Matters for Security

• DDoS dilution — Attack traffic can be spread across multiple nodes instead of concentrated on one site
• Geographic redundancy — Less dependency on a single physical location
• Reduced latency — Faster responses reduce exposure to some race-style spoofing attempts, but DNSSEC is still the integrity control

DNScale's anycast network spans multiple points of presence across Europe and North America. Your zones are served from the nodes in the selected network footprint without per-node configuration.

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 zone changes made through the platform, 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, alter DS records, transfer the domain away, or point it anywhere they want. Two locks reduce this risk.

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
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 (for example, a phone call or signed request) before covered changes such as NS records, DS records, or contact information are applied. 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 Multi-Factor Authentication

Enable MFA on every account that touches your DNS. Prefer phishing-resistant methods such as FIDO2/WebAuthn security keys for registrar and DNS provider access:

• 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

For larger teams, SSO can centralize login policy through an identity provider, but it still needs MFA, least-privilege roles, scoped API keys, and audit logs around it.

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 helps protect authoritative DNS servers from abusive traffic patterns and reduces their usefulness in DDoS attacks. It is one layer; large floods still require anycast capacity, upstream filtering, and provider-level DDoS controls.

Response Rate Limiting (RRL)

RRL limits the rate of similar responses to the same source range, which reduces the value of your authoritative servers as DNS amplification reflectors:

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

This example tells the server to limit repeated response patterns from the same source bucket. Additional responses may be slipped, truncated to encourage TCP retry, or dropped depending on the server implementation and configuration.

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 provider-level protections are in place without per-zone configuration.

9. Conduct Regular DNS Audits

DNS records accumulate over time. Old records pointing to decommissioned servers, forgotten test subdomains, and stale CNAME records can become 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 and you no longer control the target, the CNAME is dangling

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
 
# Static records should match; geo or load-balanced records may differ by resolver path

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 @1.1.1.1 example.com A +dnssec
# The 'ad' flag confirms that this validating resolver accepted the answer

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"
 
# DNS answer sample, not a complete zone inventory
dig example.com ANY +noall +answer
# For a complete audit, export records from your DNS provider or query its API

Conclusion

DNS security is not a single action but a layered defense. No single practice protects against every threat — DNSSEC mitigates cache poisoning for signed zones through validating resolvers but not DDoS; anycast helps absorb and route around some DDoS pressure but not domain hijacking; registry lock reduces registrar-side hijacking risk but not dangling CNAMEs. Implement all ten practices to cover more of the attack surface. Start with the highest-impact items — enable DNSSEC, lock down registrar access with MFA and registry lock, 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.

If the abuse is happening after users reach your web application, add application-layer controls as a separate layer. A CAPTCHA challenge-response can reduce automated signup abuse, credential stuffing, scraping, and spam, but it does not replace DNSSEC, registrar lock, CAA records, authoritative DNS rate limiting, or MFA on DNS-provider accounts.