Module 2 · Lesson 7

Best Practices for Securing DNS Infrastructure

⏱ 10 min read

dnssecuritybest-practiceshardeningmonitoringzone-transfer

Best Practices for Securing DNS Infrastructure

This is the checklist. Everything from the previous lessons condensed into actionable items. Run through this for any DNS infrastructure you operate.

1. Lock Down Zone Transfers

Zone transfers (AXFR) are used by secondary nameservers to replicate zone data. They should never be available to arbitrary clients.

# BIND: restrict AXFR to known secondary servers
options {
    allow-transfer { none; };  // Global default: deny
};

zone "example.com" {
    type primary;
    allow-transfer { 198.51.100.2; 198.51.100.3; };  // Named secondaries only
};

Test from outside:

dig @your-nameserver example.com AXFR
# Should return: Transfer failed, REFUSED, or no output

If it returns zone data — fix it now. Zone contents are not secret, but handing an attacker a complete inventory of your infrastructure is pointless operational security debt.

2. Restrict Recursive Resolution

Recursive resolvers should only answer clients who are authorized to use them.

# BIND: recursive resolver
acl "authorized-clients" {
    10.0.0.0/8;
    192.168.0.0/16;
    ::1;
};

options {
    recursion yes;
    allow-recursion { authorized-clients; };
    allow-query-cache { authorized-clients; };
};

Verify from an external IP:

dig @your-resolver-ip google.com A
# Should return REFUSED, not an answer

3. Use Views for Split-Horizon DNS

If you have internal and external DNS (common in enterprise), BIND views let you serve different answers based on client source IP:

view "internal" {
    match-clients { 10.0.0.0/8; };
    zone "example.com" {
        type primary;
        file "/etc/bind/internal/example.com.zone";
    };
};

view "external" {
    match-clients { any; };
    zone "example.com" {
        type primary;
        file "/etc/bind/external/example.com.zone";
    };
};

Internal view can include private IPs and internal hostnames. External view exposes only what should be public.

4. Monitor Query Logs for Anomalies

Query logs are your primary detection tool for DNS tunneling, NXDOMAIN floods, data exfiltration, and compromised endpoints.

# BIND: enable query logging
logging {
    channel query_log {
        file "/var/log/named/query.log" versions 5 size 50m;
        print-time yes;
        print-severity no;
        print-category no;
    };
    category queries { query_log; };
};

Patterns to watch for:

# High NXDOMAIN rate — potential random subdomain attack or malware
grep "NXDOMAIN" /var/log/named/query.log | awk '{print $NF}' | sort | uniq -c | sort -rn | head -20

# Long subdomain labels — potential DNS tunneling
grep -E "query:.*[a-z0-9]{30,}\." /var/log/named/query.log | head -20

# High query rate to single external domain (C2 via tunneling)
grep "query:" /var/log/named/query.log | awk '{print $8}' | sort | uniq -c | sort -rn | head -20

# Unusual record types (TXT, NULL, DNSKEY from internal hosts)
grep -E "query: .*(TXT|NULL|DNSKEY)" /var/log/named/query.log | grep -v "^;" | head -20

For production: pipe logs to ELK, Splunk, or your SIEM. Manual log grep is fine for incident response, not for ongoing monitoring.

5. TTL Strategy for Incident Response

TTL is a weapon in your incident response toolkit. But only if you set it correctly before the incident.

The rule: normal operations use standard TTLs (300-3600 seconds). When you detect an incident or anticipate a change:

  • Lower TTLs 24-48 hours before any planned change
  • For emergency changes, lower TTL to 60-300 seconds, wait one TTL period, make the change

If you discover your DNS is compromised:

  1. Lower TTL on all records immediately (so your fix propagates faster once you regain control)
  2. Fix the underlying compromise
  3. Change NS records back to legitimate nameservers
  4. Update records
  5. Restore normal TTLs after the crisis

Preparatory TTL lowering for critical records (before major infrastructure changes):

# Drop TTL to 5 minutes 24 hours before migration
example.com. 300 IN A 203.0.113.1
# After migration and verification:
example.com. 3600 IN A 203.0.113.50

Don't leave all critical records at 86400 (24 hours). That's a 24-hour recovery delay when something goes wrong.

6. Enable Registrar Lock on All Important Domains

Every domain with revenue or security significance:

  • Enable clientTransferProhibited, clientUpdateProhibited, clientDeleteProhibited
  • For .com/.net: request Registry Lock (server-level) from your registrar
  • Use hardware 2FA on registrar accounts
  • Use a dedicated email for registrar accounts (separate from corporate email)

Check lock status:

whois yourdomain.com | grep -i status
# Should show clientTransferProhibited at minimum
# serverTransferProhibited = registry lock active

7. Secondary DNS Diversity

Don't put all nameservers at the same provider, same datacenter, or same ASN. When Dyn went down in 2016, every customer with DNS solely on Dyn went down. Diversify:

  • Primary: your provider or self-hosted
  • Secondary: different provider, different network path, different ASN
# Check your NS records — they should be at diverse providers
dig NS example.com +short
# Good: ns1.provider-a.com, ns2.provider-b.com
# Bad: ns1.same-provider.com, ns2.same-provider.com

Minimum: two providers. Prefer geographic diversity for global domains.

8. Deploy DNSSEC for High-Value Zones

For domains where DNS integrity matters (banking, critical infrastructure, authentication services):

# Verify DNSSEC chain with Verisign's analyzer
# https://dnssec-analyzer.verisignlabs.com/example.com

# Check DS record in parent zone
dig DS example.com +short

# Validate signed records
dig +dnssec +cd example.com A  # +cd disables validation so you see the RRSIG even if chain is broken
dig +dnssec example.com A      # Without +cd: will SERVFAIL if validation fails

Automate ZSK rollover. Do not manage DNSSEC keys manually in production without tooling.

9. Rate Limiting on Authoritative Servers

Enable Response Rate Limiting (RRL) on your authoritative nameservers to prevent use as amplification infrastructure:

options {
    rate-limit {
        responses-per-second 10;
        referrals-per-second 5;
        nodata-per-second 5;
        nxdomains-per-second 5;
        errors-per-second 5;
        all-per-second 20;
        window 5;
        slip 2;
        exempt-clients { 10.0.0.0/8; };  // Don't rate-limit internal clients
    };
};

10. Certificate Transparency Monitoring

Set up alerts for new certificates issued for your domains. Domain hijacking often reveals itself through unexpected CT entries.

# Manual check
curl -s "https://crt.sh/?q=%.yourdomain.com&output=json" | \
  jq -r '.[] | "\(.not_before) \(.name_value) (\(.issuer_ca_id))"' | \
  sort -r | head -20

For ongoing monitoring: services like sslmate.com/certspotter or Facebook's CT monitoring send alerts when new certificates are issued.

Quick Audit Checklist

Run these against any DNS infrastructure:

# 1. Open resolver?
dig @your-server-ip google.com A

# 2. Zone transfer open?
dig @your-server-ip example.com AXFR

# 3. Port randomization (resolvers)?
dig +short porttest.dns-oarc.net TXT @your-resolver

# 4. DNSSEC validation working?
dig sigfail.verteiltesysteme.net A @your-resolver
# Should be SERVFAIL

# 5. NS record diversity?
dig NS example.com +short | xargs -I{} dig +short {} A

# 6. TTL sanity?
dig SOA example.com +short  # Check minimum TTL field
dig A example.com +short +ttlunits

# 7. Registrar lock?
whois example.com | grep -i "clientTransferProhibited\|serverTransferProhibited"

Key Takeaways

  • Zone transfer restrictions and recursive resolver access controls are the baseline. Check these first, every time.
  • Query log monitoring is your main detection capability. Pipe logs somewhere you'll actually look at them.
  • TTL management is an incident response tool, not just a performance setting. Lower critical record TTLs before incidents happen.
  • Registrar lock and NS diversity are infrastructure decisions that need to be made once and enforced, not reactive measures.
  • DNSSEC and CT monitoring give you integrity verification and hijacking detection.

Further Reading

  • BIND 9 Administrator Reference Manual: https://bind9.readthedocs.io
  • CIS DNS Benchmark (available at cisecurity.org)
  • SANS Reading Room: DNS Security hardening guides
  • NIST SP 800-81-2: Secure Domain Name System (DNS) Deployment Guide

Up Next

Lesson 08 closes the module with four case studies: Dyn 2016, Sea Turtle, the MyEtherWallet BGP+DNS hijack, and the Kaminsky disclosure. Each one analyzed technically, with lessons.