DNS Security Measures:… — DNS Security: Protecting… | OneNoughtOne

0/121

Computer NetworksDNS Security

DNS Security: Protecting Domain Name Resolution

LevelAdvanced

Duration75 mins

TopicDNS Security

5 / 5

DNS Security Measures: Defense in Depth

Building a Comprehensive DNS Security Strategy

Throughout this module, we've explored DNSSEC for authentication, DoH and DoT for encryption, and the threat landscape DNS faces. This final page synthesizes these elements into a practical, comprehensive security framework. Effective DNS security isn't about deploying a single technology—it's about layered defenses that protect against different attack vectors at different points in the infrastructure. No single measure provides complete protection. DNSSEC doesn't encrypt queries. DoH doesn't validate record authenticity. Rate limiting doesn't prevent cache poisoning. A robust DNS security posture requires understanding which threats each measure addresses and how they complement each other.

What You Will Learn

By the end of this page, you will understand: (1) DNS security architecture for different deployment scales, (2) Implementation priorities based on threat models, (3) Monitoring and alerting strategies for DNS, (4) Incident response procedures for DNS attacks, (5) Client-side security configurations, (6) Server-side hardening best practices, and (7) Organizational policies for DNS security governance.

Defense in Depth Framework

Defense in depth applies the principle that multiple overlapping security layers provide better protection than any single measure. For DNS, this means implementing controls at every level: authoritative servers, resolvers, network infrastructure, and clients. The DNS security stack: Each layer addresses specific threats: Transport security (DoH/DoT) — Prevents eavesdropping and manipulation between clients and resolvers Data authenticity (DNSSEC) — Validates that records come from authorized sources Access control — Limits who can query resolvers and modify zones Rate limiting — Prevents resource exhaustion and amplification abuse Monitoring — Detects anomalies indicating attacks or compromise Redundancy — Ensures availability despite failures or attacks

DNS Security Measures by Attack Type
Attack Type	Primary Defense	Secondary Defense	Monitoring Indicator
Cache Poisoning	DNSSEC validation	Source port randomization, 0x20 encoding	Validation failures, query floods
Amplification DDoS	BCP38, disable open resolvers	Response Rate Limiting, DNS cookies	Unusual query patterns, large response counts
Eavesdropping	DoH/DoT encryption	Query minimization, private resolver	N/A (prevention only)
DNS Hijacking	DNSSEC, registry lock	CAA records, CT monitoring	Unexpected record changes, NS modifications
DNS Tunneling	Query inspection, blocklists	Machine learning detection	Long subdomains, high entropy, TXT queries
Rebinding	Private IP blocking	Host header validation	Internal requests to external domains
Infrastructure DDoS	Anycast, overprovision	Multiple providers, DDoS mitigation	Query volume spikes, latency increases

Converting Mermaid diagram...

Prioritize by Threat Model

Not all organizations face the same threats. A small business may prioritize DoH for privacy. A financial institution prioritizes DNSSEC for integrity. An ISP prioritizes amplification prevention. Identify your most likely threats and implement corresponding defenses first.

Client-Side Security Configuration

End-user devices represent both the initiation point for DNS queries and a critical security boundary. Properly configured clients resist many DNS attacks regardless of network security. Key client-side security measures:

Client DNS Security Checklist

•Enable encrypted DNS (DoH/DoT) — Configure system or browser to use DoH/DoT resolver. Prevents local network eavesdropping and manipulation.
•Enable DNSSEC validation — Use validating resolver or local validating stub. Protects against poisoned records from any source.
•Lock DNS settings — Prevent malware from changing resolver configuration. Use MDM policies or local lockdown.
•Monitor hosts file — Detect unauthorized modifications. Malware often edits hosts file for local hijacking.
•Use per-application DNS where appropriate — Some apps (browsers) can use different DNS than system; ensure consistency.
•VPN DNS handling — Ensure VPN properly captures and encrypts DNS. Avoid DNS leaks revealing browsing to ISP.

client-security-config.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
# Comprehensive Client DNS Security Configuration
 
# ============================================
# Windows 11 - DoH + DNSSEC
# ============================================
 
# Enable DoH via PowerShell (Administrator)
Add-DnsClientDohServerAddress -ServerAddress "1.1.1.1" `
    -DohTemplate "https://cloudflare-dns.com/dns-query" `
    -AutoUpgrade $True
 
Add-DnsClientDohServerAddress -ServerAddress "8.8.8.8" `
    -DohTemplate "https://dns.google/dns-query" `
    -AutoUpgrade $True
 
# Set DNS servers with DoH
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" `
    -ServerAddresses 1.1.1.1, 8.8.8.8
 
# ============================================
# Linux - Systemd-resolved with DoT + DNSSEC
# ============================================
 
# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net
FallbackDNS=8.8.8.8#dns.google
DNSSEC=yes
DNSOverTLS=yes
Domains=~.
 
# Restart and verify
$ sudo systemctl restart systemd-resolved
$ resolvectl status
 
# ============================================
# macOS - DNS Profile with DNSSEC validation
# ============================================
 
# Install local validating resolver (Unbound)
$ brew install unbound
 
# /usr/local/etc/unbound/unbound.conf
server:
    interface: 127.0.0.1
    access-control: 127.0.0.0/8 allow
    auto-trust-anchor-file: "/usr/local/etc/unbound/root.key"
    tls-cert-bundle: "/etc/ssl/cert.pem"
    
forward-zone:
    name: "."
    forward-tls-upstream: yes
    forward-addr: 1.1.1.1@853#cloudflare-dns.com
    forward-addr: 9.9.9.9@853#dns.quad9.net
 
# Set system DNS to localhost
$ sudo networksetup -setdnsservers "Wi-Fi" 127.0.0.1
 
# ============================================  
# Browser Configuration (Firefox example)
# ============================================
 
# about:config settings
network.trr.mode = 3              # DoH only (no fallback)
network.trr.uri = https://cloudflare-dns.com/dns-query
network.trr.bootstrapAddress = 1.1.1.1
network.trr.custom_uri = https://cloudflare-dns.com/dns-query
network.security.esni.enabled = true  # Encrypted SNI if available

Mobile device configuration: Android 9+: Settings \to Network \to Private DNS \to "dns.google" or "one.one.one.one" Uses DoT automatically for all apps Note: Hostname only, not full URL iOS 14+: Configuration Profile with DNS Settings payload Supports DoH and DoT Can be deployed via MDM for enterprise Enterprise considerations: In enterprise environments, client DNS configuration should be managed centrally: Use MDM (Mobile Device Management) to push DNS profiles Group Policy for Windows domain-joined machines Configuration management (Ansible/Puppet) for Linux Deploy internal DoH/DoT servers to maintain visibility while providing encryption

Testing Your Configuration

After configuration, verify your setup: (1) Use dnsleaktest.com to check for leaks, (2) Query dnssec-failed.org—should fail if DNSSEC is properly validating, (3) Use Cloudflare's 1.1.1.1/help page to verify DoH is working, (4) Check resolver with dig +short resolver.hostname or browser network panel.

Resolver Security Hardening

Resolvers are high-value targets—they serve many clients and cache responses that affect all users. Properly hardening resolvers is critical for organizational DNS security. Resolver security fundamentals:

Resolver Hardening Measures
Category	Measure	Purpose	Implementation
Access Control	Restrict recursive service	Prevent open resolver abuse	ACLs by client subnet
Access Control	Separate interfaces	Internal vs management access	Bind to specific IPs
Validation	Enable DNSSEC	Verify response authenticity	trust-anchor configuration
Validation	QNAME minimization	Privacy for upstream queries	RFC 7816 implementation
Rate Limiting	Response Rate Limiting	Prevent amplification abuse	RRL configuration
Rate Limiting	Query rate limiting	Prevent resource exhaustion	Per-client limits
Filtering	Threat intelligence feeds	Block malware/phishing domains	RPZ or blocklist integration
Filtering	Private IP response blocking	Prevent rebinding attacks	Rebind protection config
Monitoring	Query logging	Security analysis, troubleshooting	Named querylog or dnstap
Encryption	DoH/DoT frontend	Client privacy	TLS termination

resolver-hardening-bind.conf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
// BIND 9 Security-Hardened Configuration
// /etc/named.conf
 
options {
    directory "/var/named";
    
    // ==========================================
    // ACCESS CONTROL - Critical for preventing open resolver
    // ==========================================
    
    // Only allow recursion for internal clients
    allow-recursion { 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; localhost; };
    allow-query { 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; localhost; };
    allow-query-cache { 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; localhost; };
    
    // Disable zone transfers (unless specifically needed)
    allow-transfer { none; };
    
    // ==========================================
    // DNSSEC VALIDATION
    // ==========================================
    
    dnssec-validation auto;  // Automatically uses root trust anchor
    // For explicit anchor: dnssec-validation yes; + managed-keys/trust-anchors
    
    // ==========================================
    // RESPONSE RATE LIMITING (Anti-amplification)
    // ==========================================
    
    rate-limit {
        responses-per-second 10;     // Limit identical responses
        errors-per-second 5;          // Limit error responses
        nxdomains-per-second 5;       // Limit NXDOMAIN floods
        slip 2;                       // Truncate rather than drop (occasionally)
        window 15;                    // 15-second tracking window
        log-only no;                  // Enforce limits
    };
    
    // ==========================================
    // PRIVACY AND SECURITY OPTIONS
    // ==========================================
    
    // Minimize information leakage
    version "not disclosed";
    hostname none;
    server-id none;
    
    // Query name minimization for upstream privacy
    qname-minimization relaxed;
    
    // Fetch DNSSEC signatures for negative responses
    dnssec-must-be-secure . yes;
    
    // ==========================================
    // CACHE SECURITY
    // ==========================================
    
    // Limit cache size to prevent memory exhaustion
    max-cache-size 256M;
    
    // Minimum cache TTL (prevents very short TTL abuse)
    min-cache-ttl 60;
    
    // Maximum cache TTL
    max-cache-ttl 86400;
    
    // ==========================================
    // REBINDING ATTACK PREVENTION
    // ==========================================
    
    // Block private IP addresses in responses (custom ACL needed)
    // Use Response Policy Zones for flexible blocking
};
 
// ==========================================
// LOGGING FOR SECURITY MONITORING
// ==========================================
 
logging {
    channel security_log {
        file "/var/log/named/security.log" versions 5 size 50M;
        severity info;
        print-time yes;
        print-category yes;
    };
    
    channel query_log {
        file "/var/log/named/queries.log" versions 10 size 100M;
        severity info;
        print-time yes;
    };
    
    category security { security_log; };
    category queries { query_log; };
    category dnssec { security_log; };
};

Response Policy Zones (RPZ) for threat blocking: RPZ allows resolvers to override DNS responses based on policy, enabling: Malware domain blocking (feed from threat intelligence) Phishing site blocking DNS rebinding prevention (block private IPs in responses) Internal policy enforcement Implementation: Subscribe to threat intelligence feeds (e.g., Spamhaus, SURBL) Configure RPZ zones in resolver Update feeds regularly (hourly or more frequently) Monitor false positives and whitelist as needed QNAME minimization (RFC 7816): Traditionally, resolvers send the full query name to each server in the resolution chain. QNAME minimization only sends the minimum necessary: Query for www.example.com : Root: Ask for "com" (not full name) TLD: Ask for "example.com" Authoritative: Ask for " www.example.com " This improves privacy by not revealing full queries to servers that don't need them.

Unbound Alternative

Unbound is a popular alternative to BIND for validating resolvers. It's designed with security in mind, enables DNSSEC by default, supports DoT/DoH out of the box, and has a simpler configuration. For new deployments, consider Unbound for its security-focused design.

Authoritative DNS Security

Authoritative DNS servers are the source of truth for domain records. Their security directly impacts all users querying your domains. Compromise of authoritative servers can redirect your entire domain traffic. Key authoritative server security measures:

Authoritative Server Hardening

•DNSSEC signing — Sign zones with appropriate algorithm (ECDSA P-256 recommended). Automate signing and key rotation. Monitor signature expiration.
•Hide master servers — Publish only secondary (slave) servers in NS records. Master should only be accessible for zone transfers.
•Restrict zone transfers — Allow AXFR/IXFR only from known secondary IPs. Use TSIG authentication for transfer authentication.
•Separation of roles — Run authoritative-only servers; don't combine with recursion. Reduces attack surface.
•Geographic distribution — Deploy in multiple regions with anycast. Single location creates availability risk.
•Rate limiting — Limit query rates per source. Prevents resource exhaustion from query floods.
•Minimal zone exposure — Only publish necessary records. Internal infrastructure shouldn't be in public DNS.

Essential Authoritative DNS Records for Security
Record Type	Purpose	Security Benefit	Example
CAA	Certificate Authority Authorization	Prevents unauthorized certificate issuance	example.com. CAA 0 issue "letsencrypt.org"
SPF (TXT)	Email sender policy	Prevents email spoofing	v=spf1 include:_spf.google.com -all
DKIM (TXT)	Email signing public key	Validates email authenticity	selector._domainkey.example.com TXT "v=DKIM1;..."
DMARC (TXT)	Email policy and reporting	Instructs receivers on SPF/DKIM failures	_dmarc.example.com TXT "v=DMARC1; p=reject;..."
TLSA	TLS certificate pinning via DNS	Enables DANE for certificate validation	_443._tcp.example.com TLSA 3 1 1 [hash]
MTA-STS (TXT)	Email TLS enforcement policy	Mandates TLS for email delivery	_mta-sts.example.com TXT "v=STSv1; id=..."

authoritative-zone-security.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
# Secure Zone Configuration Example
# example.com zone with security records
 
$TTL 3600
$ORIGIN example.com.
 
; SOA with security-conscious settings
@   IN  SOA ns1.example.com. hostmaster.example.com. (
        2024011701  ; Serial (YYYYMMDDNN format)
        3600        ; Refresh (1 hour)
        600         ; Retry (10 minutes)
        604800      ; Expire (1 week)
        300         ; Minimum TTL (5 minutes for NXDOMAIN caching)
    )
 
; Nameservers (secondaries only; master is hidden)
        IN  NS      ns1.example.com.
        IN  NS      ns2.example.com.
        IN  NS      ns3.example.net.  ; Different provider for redundancy
 
; Main records
        IN  A       93.184.216.34
        IN  AAAA    2606:2800:220:1:248:1893:25c8:1946
www     IN  CNAME   example.com.
mail    IN  A       93.184.216.35
 
; ==========================================
; SECURITY RECORDS
; ==========================================
 
; CAA - Only these CAs can issue certificates
        IN  CAA     0 issue "letsencrypt.org"
        IN  CAA     0 issue "digicert.com"
        IN  CAA     0 issuewild "letsencrypt.org"
        IN  CAA     0 iodef "mailto:security@example.com"
 
; SPF - Email sender policy
        IN  TXT     "v=spf1 ip4:93.184.216.0/24 include:_spf.google.com -all"
 
; DMARC - Email authentication policy
_dmarc  IN  TXT     "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-failures@example.com; sp=reject; adkim=s; aspf=s"
 
; DKIM - Email signing (selector: google)
google._domainkey IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."
 
; MTA-STS - Enforce TLS for email
_mta-sts IN TXT    "v=STSv1; id=20240117T000000Z"
 
; SMTP TLS Reporting
_smtp._tls IN TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"
 
; ==========================================
; DNSSEC NOTE
; ==========================================
; DNSSEC records (DNSKEY, RRSIG, NSEC/NSEC3) are 
; automatically generated by the signing process.
; DS record must be published in parent zone (.com).
; 
; Generation: dnssec-keygen -a ECDSAP256SHA256 example.com
; Signing: dnssec-signzone -o example.com example.com.zone

Zone Transfer Security

Unrestricted zone transfers (AXFR) expose your entire DNS zone, revealing internal hostnames, IP addresses, and infrastructure details. Always restrict zone transfers to known secondary server IPs and use TSIG authentication. Test with 'dig axfr @your-ns example.com'—if it works from an external IP, you have a configuration problem.

Monitoring and Threat Detection

Security monitoring for DNS involves detecting anomalies that indicate attacks, misconfigurations, or compromise. Effective monitoring covers both infrastructure health and security-specific indicators. What to monitor:

DNS Security Monitoring Dimensions
Category	Metrics	Alert Threshold	Indicates
Volume	Queries per second	2-3× normal baseline	DDoS, amplification abuse, potential compromise
Error Rates	NXDOMAIN percentage	10% of traffic	Random subdomain attack, misconfiguration
DNSSEC	Validation failures	Any significant increase	Cache poisoning attempt, zone signing issue
Query Types	TXT, ANY, NULL proportion	Unusual increase	DNS tunneling, data exfiltration
Query Patterns	Entropy of query names	High entropy subdomains	Tunneling, DGA malware
Source Distribution	Queries from single source	1000/min from one IP	Attack in progress, misconfigured client
Response Size	Average response bytes	Significant increase	Amplification preparation, zone changes
Latency	Resolution time	2× baseline	Upstream issues, under attack, path problems

DNS security monitoring architecture: Query logging — Capture all DNS queries with timestamps, source IPs, query types, and response codes. Use dnstap for efficient structured logging. Log aggregation — Centralize logs in SIEM or log management platform (Splunk, Elastic, etc.) Baseline establishment — Understand normal patterns before alerting on anomalies Alerting rules — Configure alerts for security-relevant conditions Dashboards — Visualize DNS metrics for operational awareness Threat intelligence integration — Correlate queries against known malicious domains

dns-monitoring.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
# DNS Security Monitoring with Zeek (Bro) and Elastic
 
# ============================================
# Zeek DNS Log Fields for Security Analysis
# ============================================
# Zeek produces dns.log with:
# - ts (timestamp)
# - uid (connection ID)
# - id.orig_h (source IP)
# - id.orig_p (source port)
# - query (domain queried)
# - qtype_name (A, AAAA, TXT, etc.)
# - rcode_name (NOERROR, NXDOMAIN, etc.)
# - answers (response data)
 
# ============================================
# Elasticsearch Queries for DNS Threats
# ============================================
 
# High-entropy domain detection (tunneling/DGA)
GET dns-*/_search
{
  "query": {
    "script_score": {
      "query": { "match_all": {} },
      "script": {
        "source": "doc['query.keyword'].value.length() > 50 ? 1 : 0"
      }
    }
  }
}
 
# TXT record query spike
GET dns-*/_search
{
  "query": {
    "bool": {
      "must": [
        { "term": { "qtype_name": "TXT" } },
        { "range": { "@timestamp": { "gte": "now-1h" } } }
      ]
    }
  },
  "aggs": {
    "by_source": {
      "terms": { "field": "id.orig_h", "size": 20 }
    }
  }
}
 
# NXDOMAIN flood detection
GET dns-*/_search
{
  "query": {
    "bool": {
      "must": [
        { "term": { "rcode_name": "NXDOMAIN" } }
      ]
    }
  },
  "aggs": {
    "nxdomain_rate": {
      "date_histogram": {
        "field": "@timestamp",
        "interval": "1m"
      }
    }
  }
}
 
# ============================================
# Sample Alerting Rules
# ============================================
 
alerts:
  - name: "DNS Tunneling Suspected"
    condition: "
      count(query where len(subdomain) > 50) > 100
      within 5 minutes from same source"
    action: "notify security team"
    
  - name: "DNSSEC Validation Failures"
    condition: "validation_failure_count > 10 in 1 minute"
    action: "page on-call, investigate immediately"
    
  - name: "Query Volume Anomaly"
    condition: "qps > 3 * 24h_average"
    action: "notify network team"

Passive DNS (pDNS)

Passive DNS captures DNS responses seen on the network, creating a historical database of domain-to-IP mappings. This enables: (1) Identifying all domains a malware sample queried, (2) Finding related infrastructure (shared IPs), (3) Historical analysis of domain changes. Services like Farsight DNSDB, VirusTotal, and SecurityTrails provide commercial pDNS data.

DNS Security Incident Response

When DNS security incidents occur, rapid response is critical—DNS issues can affect all services depending on name resolution. Having prepared runbooks and clear escalation paths minimizes impact. Common DNS security incidents:

DNS Incident Response Playbooks
Incident Type	Detection	Immediate Response	Investigation Steps
Cache Poisoning	DNSSEC validation failures, user reports of wrong sites	Flush resolver cache, verify authoritative responses	Check for attack indicators, review resolver logs
Domain Hijacking	NS record changes, certificate warnings, CT alerts	Contact registrar immediately, verify account security	Review registrar logs, check for unauthorized access
DDoS on DNS	High latency, query failures, alert triggers	Engage DDoS mitigation, scale infrastructure, communicate status	Analyze attack patterns, identify mitigation gaps
Tunneling Detection	Security alerts, anomalous query patterns	Block suspicious domains/sources, investigate affected hosts	Examine host for malware, trace data exfiltration
Zone Compromise	Unexpected record changes, signature issues	Rotate keys, restore from backup, increase monitoring	Analyze access logs, determine attack vector

Domain Hijacking Response

•Immediate: Contact registrar security team (phone, not email)
•Lock: Request emergency registry lock on all changes
•Verify: Check NS, A, MX records at authoritative servers
•Restore: Revert unauthorized changes
•Secure: Enable MFA, change passwords, review access logs
•Monitor: Watch Certificate Transparency logs
•Communicate: Notify users if credentials may be compromised

DNS DDoS Response

•Assess: Determine attack type and volume
•Mitigate: Engage DDoS protection (if available)
•Scale: Add capacity if possible (anycast helps)
•Filter: Block obvious attack traffic at network edge
•Communicate: Update status page, notify affected parties
•Document: Collect logs and traffic samples
•Review: Post-incident analysis for prevention

Incident preparation checklist: Before incidents occur: Documentation — Maintain current runbooks for each incident type Contact list — Registrar security team, DNS provider NOC, upstream providers Access credentials — Ensure multiple team members have registrar/DNS console access Backup procedures — Regularly export zone files; maintain version history Monitoring — Alerts configured for key metrics with on-call rotation Recovery testing — Periodically test restoration from backup Communication templates — Pre-drafted user notifications for common scenarios During incidents: Preserve evidence before making changes Document timeline of actions taken Coordinate communication through incident commander Avoid panic changes that might worsen situation After incidents: Conduct blameless post-mortem Update runbooks with lessons learned Implement preventive measures identified Share findings with relevant communities (if appropriate)

Registrar Lock Is Critical

For critical domains, enable registry lock (also called 'registrar lock' or 'domain lock'). This requires out-of-band verification (phone call, notarized letter) before any changes. Major TLDs support locks that make unauthorized changes nearly impossible. Cost is minimal compared to hijacking impact.

DNS Security Governance and Policies

Technical controls are only effective when supported by organizational policies and governance. DNS security policies ensure consistent implementation and provide accountability frameworks. Key policy areas:

DNS Security Policy Framework

•Domain Registration Policy — Who can register domains on behalf of the organization? Approval workflow for new domains. Centralized registrar account with MFA. Prohibition on personal accounts for corporate domains.
•DNS Change Management — All DNS changes through change management process. Peer review for production zone changes. Testing in staging environment when possible. Rollback procedures documented.
•Access Control Policy — Role-based access to DNS management. Principle of least privilege. Regular access reviews. Logging of all administrative actions.
•DNSSEC Key Management — Key generation procedures. Secure key storage requirements. Rollover schedules and procedures. Emergency key revocation process.
•Resolver Configuration Standards — Mandatory DoH/DoT for client devices. Approved resolver list (internal or vetted external). DNSSEC validation requirements.
•Monitoring Requirements — Mandatory logging of DNS queries on resolvers. Alert thresholds and responsible parties. Retention period for DNS logs. Integration with SIEM.
•Third-Party DNS Services — Approved vendors for external DNS hosting. Security requirements for DNS providers. SLA requirements for availability. Data handling requirements.

Compliance considerations: Various regulations and frameworks have DNS-relevant requirements: NIST Cybersecurity Framework: PR.DS-2: Data-in-transit protection (DoH/DoT) PR.IP-1: Baseline configurations (resolver hardening) DE.CM-1: Network monitoring (DNS logging) CIS Controls: Control 9: Email and Web Browser Protections (DNS filtering) Control 12: Network Infrastructure Management (DNS security) Control 13: Network Monitoring and Defense (DNS monitoring) PCI DSS: Requirement 1: Network segmentation (DNS access control) Requirement 10: Logging (DNS query logging) Requirement 11: Security testing (DNS vulnerability assessment) GDPR/Privacy: DNS logs may contain personal data (query patterns) DoH/DoT supports data protection requirements Retention policies must comply with data minimization

DNS Security Maturity Model
Level	Characteristics	Key Capabilities	Typical Organization
1 - Initial	Ad-hoc DNS management; no dedicated security	Basic resolvers; manual zone management	Small business, startups
2 - Developing	Documented procedures; some monitoring	DoH/DoT enabled; basic alerting; registrar MFA	Growing companies; some IT staff
3 - Defined	Formal policies; consistent implementation	DNSSEC signed; threat feed integration; logging	Mid-size enterprises; regulated industries
4 - Managed	Metrics-driven; continuous improvement	Automated key rotation; ML-based detection; multiple providers	Large enterprises; security-focused orgs
5 - Optimizing	Industry-leading practices; innovation	Custom threat intelligence; formal verification; research contribution	Tech leaders; critical infrastructure

Start Where You Are

Organizations should assess their current maturity level and set realistic improvement goals. Moving from Level 1 to Level 3 typically provides the most security value for investment. Focus on quick wins like enabling DoH/DoT and registrar MFA before tackling complex DNSSEC deployments.

Computer NetworksDNS Security

DNS Security: Protecting Domain Name Resolution

LevelAdvanced

Duration75 mins

TopicDNS Security

5 / 5

DNS Security Measures: Defense in Depth

Building a Comprehensive DNS Security Strategy

Throughout this module, we've explored DNSSEC for authentication, DoH and DoT for encryption, and the threat landscape DNS faces. This final page synthesizes these elements into a practical, comprehensive security framework. Effective DNS security isn't about deploying a single technology—it's about layered defenses that protect against different attack vectors at different points in the infrastructure. No single measure provides complete protection. DNSSEC doesn't encrypt queries. DoH doesn't validate record authenticity. Rate limiting doesn't prevent cache poisoning. A robust DNS security posture requires understanding which threats each measure addresses and how they complement each other.

What You Will Learn

By the end of this page, you will understand: (1) DNS security architecture for different deployment scales, (2) Implementation priorities based on threat models, (3) Monitoring and alerting strategies for DNS, (4) Incident response procedures for DNS attacks, (5) Client-side security configurations, (6) Server-side hardening best practices, and (7) Organizational policies for DNS security governance.

Defense in Depth Framework

Defense in depth applies the principle that multiple overlapping security layers provide better protection than any single measure. For DNS, this means implementing controls at every level: authoritative servers, resolvers, network infrastructure, and clients. The DNS security stack: Each layer addresses specific threats: Transport security (DoH/DoT) — Prevents eavesdropping and manipulation between clients and resolvers Data authenticity (DNSSEC) — Validates that records come from authorized sources Access control — Limits who can query resolvers and modify zones Rate limiting — Prevents resource exhaustion and amplification abuse Monitoring — Detects anomalies indicating attacks or compromise Redundancy — Ensures availability despite failures or attacks

DNS Security Measures by Attack Type
Attack Type	Primary Defense	Secondary Defense	Monitoring Indicator
Cache Poisoning	DNSSEC validation	Source port randomization, 0x20 encoding	Validation failures, query floods
Amplification DDoS	BCP38, disable open resolvers	Response Rate Limiting, DNS cookies	Unusual query patterns, large response counts
Eavesdropping	DoH/DoT encryption	Query minimization, private resolver	N/A (prevention only)
DNS Hijacking	DNSSEC, registry lock	CAA records, CT monitoring	Unexpected record changes, NS modifications
DNS Tunneling	Query inspection, blocklists	Machine learning detection	Long subdomains, high entropy, TXT queries
Rebinding	Private IP blocking	Host header validation	Internal requests to external domains
Infrastructure DDoS	Anycast, overprovision	Multiple providers, DDoS mitigation	Query volume spikes, latency increases

Converting Mermaid diagram...

Prioritize by Threat Model

Not all organizations face the same threats. A small business may prioritize DoH for privacy. A financial institution prioritizes DNSSEC for integrity. An ISP prioritizes amplification prevention. Identify your most likely threats and implement corresponding defenses first.

Client-Side Security Configuration

End-user devices represent both the initiation point for DNS queries and a critical security boundary. Properly configured clients resist many DNS attacks regardless of network security. Key client-side security measures:

Client DNS Security Checklist

•Enable encrypted DNS (DoH/DoT) — Configure system or browser to use DoH/DoT resolver. Prevents local network eavesdropping and manipulation.
•Enable DNSSEC validation — Use validating resolver or local validating stub. Protects against poisoned records from any source.
•Lock DNS settings — Prevent malware from changing resolver configuration. Use MDM policies or local lockdown.
•Monitor hosts file — Detect unauthorized modifications. Malware often edits hosts file for local hijacking.
•Use per-application DNS where appropriate — Some apps (browsers) can use different DNS than system; ensure consistency.
•VPN DNS handling — Ensure VPN properly captures and encrypts DNS. Avoid DNS leaks revealing browsing to ISP.

client-security-config.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
# Comprehensive Client DNS Security Configuration
 
# ============================================
# Windows 11 - DoH + DNSSEC
# ============================================
 
# Enable DoH via PowerShell (Administrator)
Add-DnsClientDohServerAddress -ServerAddress "1.1.1.1" `
    -DohTemplate "https://cloudflare-dns.com/dns-query" `
    -AutoUpgrade $True
 
Add-DnsClientDohServerAddress -ServerAddress "8.8.8.8" `
    -DohTemplate "https://dns.google/dns-query" `
    -AutoUpgrade $True
 
# Set DNS servers with DoH
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" `
    -ServerAddresses 1.1.1.1, 8.8.8.8
 
# ============================================
# Linux - Systemd-resolved with DoT + DNSSEC
# ============================================
 
# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net
FallbackDNS=8.8.8.8#dns.google
DNSSEC=yes
DNSOverTLS=yes
Domains=~.
 
# Restart and verify
$ sudo systemctl restart systemd-resolved
$ resolvectl status
 
# ============================================
# macOS - DNS Profile with DNSSEC validation
# ============================================
 
# Install local validating resolver (Unbound)
$ brew install unbound
 
# /usr/local/etc/unbound/unbound.conf
server:
    interface: 127.0.0.1
    access-control: 127.0.0.0/8 allow
    auto-trust-anchor-file: "/usr/local/etc/unbound/root.key"
    tls-cert-bundle: "/etc/ssl/cert.pem"
    
forward-zone:
    name: "."
    forward-tls-upstream: yes
    forward-addr: 1.1.1.1@853#cloudflare-dns.com
    forward-addr: 9.9.9.9@853#dns.quad9.net
 
# Set system DNS to localhost
$ sudo networksetup -setdnsservers "Wi-Fi" 127.0.0.1
 
# ============================================  
# Browser Configuration (Firefox example)
# ============================================
 
# about:config settings
network.trr.mode = 3              # DoH only (no fallback)
network.trr.uri = https://cloudflare-dns.com/dns-query
network.trr.bootstrapAddress = 1.1.1.1
network.trr.custom_uri = https://cloudflare-dns.com/dns-query
network.security.esni.enabled = true  # Encrypted SNI if available

Mobile device configuration: Android 9+: Settings \to Network \to Private DNS \to "dns.google" or "one.one.one.one" Uses DoT automatically for all apps Note: Hostname only, not full URL iOS 14+: Configuration Profile with DNS Settings payload Supports DoH and DoT Can be deployed via MDM for enterprise Enterprise considerations: In enterprise environments, client DNS configuration should be managed centrally: Use MDM (Mobile Device Management) to push DNS profiles Group Policy for Windows domain-joined machines Configuration management (Ansible/Puppet) for Linux Deploy internal DoH/DoT servers to maintain visibility while providing encryption

Testing Your Configuration

After configuration, verify your setup: (1) Use dnsleaktest.com to check for leaks, (2) Query dnssec-failed.org—should fail if DNSSEC is properly validating, (3) Use Cloudflare's 1.1.1.1/help page to verify DoH is working, (4) Check resolver with dig +short resolver.hostname or browser network panel.

Resolver Security Hardening

Resolvers are high-value targets—they serve many clients and cache responses that affect all users. Properly hardening resolvers is critical for organizational DNS security. Resolver security fundamentals:

Resolver Hardening Measures
Category	Measure	Purpose	Implementation
Access Control	Restrict recursive service	Prevent open resolver abuse	ACLs by client subnet
Access Control	Separate interfaces	Internal vs management access	Bind to specific IPs
Validation	Enable DNSSEC	Verify response authenticity	trust-anchor configuration
Validation	QNAME minimization	Privacy for upstream queries	RFC 7816 implementation
Rate Limiting	Response Rate Limiting	Prevent amplification abuse	RRL configuration
Rate Limiting	Query rate limiting	Prevent resource exhaustion	Per-client limits
Filtering	Threat intelligence feeds	Block malware/phishing domains	RPZ or blocklist integration
Filtering	Private IP response blocking	Prevent rebinding attacks	Rebind protection config
Monitoring	Query logging	Security analysis, troubleshooting	Named querylog or dnstap
Encryption	DoH/DoT frontend	Client privacy	TLS termination

resolver-hardening-bind.conf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
// BIND 9 Security-Hardened Configuration
// /etc/named.conf
 
options {
    directory "/var/named";
    
    // ==========================================
    // ACCESS CONTROL - Critical for preventing open resolver
    // ==========================================
    
    // Only allow recursion for internal clients
    allow-recursion { 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; localhost; };
    allow-query { 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; localhost; };
    allow-query-cache { 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; localhost; };
    
    // Disable zone transfers (unless specifically needed)
    allow-transfer { none; };
    
    // ==========================================
    // DNSSEC VALIDATION
    // ==========================================
    
    dnssec-validation auto;  // Automatically uses root trust anchor
    // For explicit anchor: dnssec-validation yes; + managed-keys/trust-anchors
    
    // ==========================================
    // RESPONSE RATE LIMITING (Anti-amplification)
    // ==========================================
    
    rate-limit {
        responses-per-second 10;     // Limit identical responses
        errors-per-second 5;          // Limit error responses
        nxdomains-per-second 5;       // Limit NXDOMAIN floods
        slip 2;                       // Truncate rather than drop (occasionally)
        window 15;                    // 15-second tracking window
        log-only no;                  // Enforce limits
    };
    
    // ==========================================
    // PRIVACY AND SECURITY OPTIONS
    // ==========================================
    
    // Minimize information leakage
    version "not disclosed";
    hostname none;
    server-id none;
    
    // Query name minimization for upstream privacy
    qname-minimization relaxed;
    
    // Fetch DNSSEC signatures for negative responses
    dnssec-must-be-secure . yes;
    
    // ==========================================
    // CACHE SECURITY
    // ==========================================
    
    // Limit cache size to prevent memory exhaustion
    max-cache-size 256M;
    
    // Minimum cache TTL (prevents very short TTL abuse)
    min-cache-ttl 60;
    
    // Maximum cache TTL
    max-cache-ttl 86400;
    
    // ==========================================
    // REBINDING ATTACK PREVENTION
    // ==========================================
    
    // Block private IP addresses in responses (custom ACL needed)
    // Use Response Policy Zones for flexible blocking
};
 
// ==========================================
// LOGGING FOR SECURITY MONITORING
// ==========================================
 
logging {
    channel security_log {
        file "/var/log/named/security.log" versions 5 size 50M;
        severity info;
        print-time yes;
        print-category yes;
    };
    
    channel query_log {
        file "/var/log/named/queries.log" versions 10 size 100M;
        severity info;
        print-time yes;
    };
    
    category security { security_log; };
    category queries { query_log; };
    category dnssec { security_log; };
};

Response Policy Zones (RPZ) for threat blocking: RPZ allows resolvers to override DNS responses based on policy, enabling: Malware domain blocking (feed from threat intelligence) Phishing site blocking DNS rebinding prevention (block private IPs in responses) Internal policy enforcement Implementation: Subscribe to threat intelligence feeds (e.g., Spamhaus, SURBL) Configure RPZ zones in resolver Update feeds regularly (hourly or more frequently) Monitor false positives and whitelist as needed QNAME minimization (RFC 7816): Traditionally, resolvers send the full query name to each server in the resolution chain. QNAME minimization only sends the minimum necessary: Query for www.example.com : Root: Ask for "com" (not full name) TLD: Ask for "example.com" Authoritative: Ask for " www.example.com " This improves privacy by not revealing full queries to servers that don't need them.

Unbound Alternative

Unbound is a popular alternative to BIND for validating resolvers. It's designed with security in mind, enables DNSSEC by default, supports DoT/DoH out of the box, and has a simpler configuration. For new deployments, consider Unbound for its security-focused design.

Authoritative DNS Security

Authoritative DNS servers are the source of truth for domain records. Their security directly impacts all users querying your domains. Compromise of authoritative servers can redirect your entire domain traffic. Key authoritative server security measures:

Authoritative Server Hardening

•DNSSEC signing — Sign zones with appropriate algorithm (ECDSA P-256 recommended). Automate signing and key rotation. Monitor signature expiration.
•Hide master servers — Publish only secondary (slave) servers in NS records. Master should only be accessible for zone transfers.
•Restrict zone transfers — Allow AXFR/IXFR only from known secondary IPs. Use TSIG authentication for transfer authentication.
•Separation of roles — Run authoritative-only servers; don't combine with recursion. Reduces attack surface.
•Geographic distribution — Deploy in multiple regions with anycast. Single location creates availability risk.
•Rate limiting — Limit query rates per source. Prevents resource exhaustion from query floods.
•Minimal zone exposure — Only publish necessary records. Internal infrastructure shouldn't be in public DNS.

Essential Authoritative DNS Records for Security
Record Type	Purpose	Security Benefit	Example
CAA	Certificate Authority Authorization	Prevents unauthorized certificate issuance	example.com. CAA 0 issue "letsencrypt.org"
SPF (TXT)	Email sender policy	Prevents email spoofing	v=spf1 include:_spf.google.com -all
DKIM (TXT)	Email signing public key	Validates email authenticity	selector._domainkey.example.com TXT "v=DKIM1;..."
DMARC (TXT)	Email policy and reporting	Instructs receivers on SPF/DKIM failures	_dmarc.example.com TXT "v=DMARC1; p=reject;..."
TLSA	TLS certificate pinning via DNS	Enables DANE for certificate validation	_443._tcp.example.com TLSA 3 1 1 [hash]
MTA-STS (TXT)	Email TLS enforcement policy	Mandates TLS for email delivery	_mta-sts.example.com TXT "v=STSv1; id=..."

authoritative-zone-security.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
# Secure Zone Configuration Example
# example.com zone with security records
 
$TTL 3600
$ORIGIN example.com.
 
; SOA with security-conscious settings
@   IN  SOA ns1.example.com. hostmaster.example.com. (
        2024011701  ; Serial (YYYYMMDDNN format)
        3600        ; Refresh (1 hour)
        600         ; Retry (10 minutes)
        604800      ; Expire (1 week)
        300         ; Minimum TTL (5 minutes for NXDOMAIN caching)
    )
 
; Nameservers (secondaries only; master is hidden)
        IN  NS      ns1.example.com.
        IN  NS      ns2.example.com.
        IN  NS      ns3.example.net.  ; Different provider for redundancy
 
; Main records
        IN  A       93.184.216.34
        IN  AAAA    2606:2800:220:1:248:1893:25c8:1946
www     IN  CNAME   example.com.
mail    IN  A       93.184.216.35
 
; ==========================================
; SECURITY RECORDS
; ==========================================
 
; CAA - Only these CAs can issue certificates
        IN  CAA     0 issue "letsencrypt.org"
        IN  CAA     0 issue "digicert.com"
        IN  CAA     0 issuewild "letsencrypt.org"
        IN  CAA     0 iodef "mailto:security@example.com"
 
; SPF - Email sender policy
        IN  TXT     "v=spf1 ip4:93.184.216.0/24 include:_spf.google.com -all"
 
; DMARC - Email authentication policy
_dmarc  IN  TXT     "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-failures@example.com; sp=reject; adkim=s; aspf=s"
 
; DKIM - Email signing (selector: google)
google._domainkey IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."
 
; MTA-STS - Enforce TLS for email
_mta-sts IN TXT    "v=STSv1; id=20240117T000000Z"
 
; SMTP TLS Reporting
_smtp._tls IN TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"
 
; ==========================================
; DNSSEC NOTE
; ==========================================
; DNSSEC records (DNSKEY, RRSIG, NSEC/NSEC3) are 
; automatically generated by the signing process.
; DS record must be published in parent zone (.com).
; 
; Generation: dnssec-keygen -a ECDSAP256SHA256 example.com
; Signing: dnssec-signzone -o example.com example.com.zone

Zone Transfer Security

Unrestricted zone transfers (AXFR) expose your entire DNS zone, revealing internal hostnames, IP addresses, and infrastructure details. Always restrict zone transfers to known secondary server IPs and use TSIG authentication. Test with 'dig axfr @your-ns example.com'—if it works from an external IP, you have a configuration problem.

Monitoring and Threat Detection

Security monitoring for DNS involves detecting anomalies that indicate attacks, misconfigurations, or compromise. Effective monitoring covers both infrastructure health and security-specific indicators. What to monitor:

DNS Security Monitoring Dimensions
Category	Metrics	Alert Threshold	Indicates
Volume	Queries per second	2-3× normal baseline	DDoS, amplification abuse, potential compromise
Error Rates	NXDOMAIN percentage	10% of traffic	Random subdomain attack, misconfiguration
DNSSEC	Validation failures	Any significant increase	Cache poisoning attempt, zone signing issue
Query Types	TXT, ANY, NULL proportion	Unusual increase	DNS tunneling, data exfiltration
Query Patterns	Entropy of query names	High entropy subdomains	Tunneling, DGA malware
Source Distribution	Queries from single source	1000/min from one IP	Attack in progress, misconfigured client
Response Size	Average response bytes	Significant increase	Amplification preparation, zone changes
Latency	Resolution time	2× baseline	Upstream issues, under attack, path problems

DNS security monitoring architecture: Query logging — Capture all DNS queries with timestamps, source IPs, query types, and response codes. Use dnstap for efficient structured logging. Log aggregation — Centralize logs in SIEM or log management platform (Splunk, Elastic, etc.) Baseline establishment — Understand normal patterns before alerting on anomalies Alerting rules — Configure alerts for security-relevant conditions Dashboards — Visualize DNS metrics for operational awareness Threat intelligence integration — Correlate queries against known malicious domains

dns-monitoring.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
# DNS Security Monitoring with Zeek (Bro) and Elastic
 
# ============================================
# Zeek DNS Log Fields for Security Analysis
# ============================================
# Zeek produces dns.log with:
# - ts (timestamp)
# - uid (connection ID)
# - id.orig_h (source IP)
# - id.orig_p (source port)
# - query (domain queried)
# - qtype_name (A, AAAA, TXT, etc.)
# - rcode_name (NOERROR, NXDOMAIN, etc.)
# - answers (response data)
 
# ============================================
# Elasticsearch Queries for DNS Threats
# ============================================
 
# High-entropy domain detection (tunneling/DGA)
GET dns-*/_search
{
  "query": {
    "script_score": {
      "query": { "match_all": {} },
      "script": {
        "source": "doc['query.keyword'].value.length() > 50 ? 1 : 0"
      }
    }
  }
}
 
# TXT record query spike
GET dns-*/_search
{
  "query": {
    "bool": {
      "must": [
        { "term": { "qtype_name": "TXT" } },
        { "range": { "@timestamp": { "gte": "now-1h" } } }
      ]
    }
  },
  "aggs": {
    "by_source": {
      "terms": { "field": "id.orig_h", "size": 20 }
    }
  }
}
 
# NXDOMAIN flood detection
GET dns-*/_search
{
  "query": {
    "bool": {
      "must": [
        { "term": { "rcode_name": "NXDOMAIN" } }
      ]
    }
  },
  "aggs": {
    "nxdomain_rate": {
      "date_histogram": {
        "field": "@timestamp",
        "interval": "1m"
      }
    }
  }
}
 
# ============================================
# Sample Alerting Rules
# ============================================
 
alerts:
  - name: "DNS Tunneling Suspected"
    condition: "
      count(query where len(subdomain) > 50) > 100
      within 5 minutes from same source"
    action: "notify security team"
    
  - name: "DNSSEC Validation Failures"
    condition: "validation_failure_count > 10 in 1 minute"
    action: "page on-call, investigate immediately"
    
  - name: "Query Volume Anomaly"
    condition: "qps > 3 * 24h_average"
    action: "notify network team"

Passive DNS (pDNS)

Passive DNS captures DNS responses seen on the network, creating a historical database of domain-to-IP mappings. This enables: (1) Identifying all domains a malware sample queried, (2) Finding related infrastructure (shared IPs), (3) Historical analysis of domain changes. Services like Farsight DNSDB, VirusTotal, and SecurityTrails provide commercial pDNS data.

DNS Security Incident Response

When DNS security incidents occur, rapid response is critical—DNS issues can affect all services depending on name resolution. Having prepared runbooks and clear escalation paths minimizes impact. Common DNS security incidents:

DNS Incident Response Playbooks
Incident Type	Detection	Immediate Response	Investigation Steps
Cache Poisoning	DNSSEC validation failures, user reports of wrong sites	Flush resolver cache, verify authoritative responses	Check for attack indicators, review resolver logs
Domain Hijacking	NS record changes, certificate warnings, CT alerts	Contact registrar immediately, verify account security	Review registrar logs, check for unauthorized access
DDoS on DNS	High latency, query failures, alert triggers	Engage DDoS mitigation, scale infrastructure, communicate status	Analyze attack patterns, identify mitigation gaps
Tunneling Detection	Security alerts, anomalous query patterns	Block suspicious domains/sources, investigate affected hosts	Examine host for malware, trace data exfiltration
Zone Compromise	Unexpected record changes, signature issues	Rotate keys, restore from backup, increase monitoring	Analyze access logs, determine attack vector

Domain Hijacking Response

•Immediate: Contact registrar security team (phone, not email)
•Lock: Request emergency registry lock on all changes
•Verify: Check NS, A, MX records at authoritative servers
•Restore: Revert unauthorized changes
•Secure: Enable MFA, change passwords, review access logs
•Monitor: Watch Certificate Transparency logs
•Communicate: Notify users if credentials may be compromised

DNS DDoS Response

•Assess: Determine attack type and volume
•Mitigate: Engage DDoS protection (if available)
•Scale: Add capacity if possible (anycast helps)
•Filter: Block obvious attack traffic at network edge
•Communicate: Update status page, notify affected parties
•Document: Collect logs and traffic samples
•Review: Post-incident analysis for prevention

Incident preparation checklist: Before incidents occur: Documentation — Maintain current runbooks for each incident type Contact list — Registrar security team, DNS provider NOC, upstream providers Access credentials — Ensure multiple team members have registrar/DNS console access Backup procedures — Regularly export zone files; maintain version history Monitoring — Alerts configured for key metrics with on-call rotation Recovery testing — Periodically test restoration from backup Communication templates — Pre-drafted user notifications for common scenarios During incidents: Preserve evidence before making changes Document timeline of actions taken Coordinate communication through incident commander Avoid panic changes that might worsen situation After incidents: Conduct blameless post-mortem Update runbooks with lessons learned Implement preventive measures identified Share findings with relevant communities (if appropriate)

Registrar Lock Is Critical

For critical domains, enable registry lock (also called 'registrar lock' or 'domain lock'). This requires out-of-band verification (phone call, notarized letter) before any changes. Major TLDs support locks that make unauthorized changes nearly impossible. Cost is minimal compared to hijacking impact.

DNS Security Governance and Policies

Technical controls are only effective when supported by organizational policies and governance. DNS security policies ensure consistent implementation and provide accountability frameworks. Key policy areas:

DNS Security Policy Framework

•Domain Registration Policy — Who can register domains on behalf of the organization? Approval workflow for new domains. Centralized registrar account with MFA. Prohibition on personal accounts for corporate domains.
•DNS Change Management — All DNS changes through change management process. Peer review for production zone changes. Testing in staging environment when possible. Rollback procedures documented.
•Access Control Policy — Role-based access to DNS management. Principle of least privilege. Regular access reviews. Logging of all administrative actions.
•DNSSEC Key Management — Key generation procedures. Secure key storage requirements. Rollover schedules and procedures. Emergency key revocation process.
•Resolver Configuration Standards — Mandatory DoH/DoT for client devices. Approved resolver list (internal or vetted external). DNSSEC validation requirements.
•Monitoring Requirements — Mandatory logging of DNS queries on resolvers. Alert thresholds and responsible parties. Retention period for DNS logs. Integration with SIEM.
•Third-Party DNS Services — Approved vendors for external DNS hosting. Security requirements for DNS providers. SLA requirements for availability. Data handling requirements.

Compliance considerations: Various regulations and frameworks have DNS-relevant requirements: NIST Cybersecurity Framework: PR.DS-2: Data-in-transit protection (DoH/DoT) PR.IP-1: Baseline configurations (resolver hardening) DE.CM-1: Network monitoring (DNS logging) CIS Controls: Control 9: Email and Web Browser Protections (DNS filtering) Control 12: Network Infrastructure Management (DNS security) Control 13: Network Monitoring and Defense (DNS monitoring) PCI DSS: Requirement 1: Network segmentation (DNS access control) Requirement 10: Logging (DNS query logging) Requirement 11: Security testing (DNS vulnerability assessment) GDPR/Privacy: DNS logs may contain personal data (query patterns) DoH/DoT supports data protection requirements Retention policies must comply with data minimization

DNS Security Maturity Model
Level	Characteristics	Key Capabilities	Typical Organization
1 - Initial	Ad-hoc DNS management; no dedicated security	Basic resolvers; manual zone management	Small business, startups
2 - Developing	Documented procedures; some monitoring	DoH/DoT enabled; basic alerting; registrar MFA	Growing companies; some IT staff
3 - Defined	Formal policies; consistent implementation	DNSSEC signed; threat feed integration; logging	Mid-size enterprises; regulated industries
4 - Managed	Metrics-driven; continuous improvement	Automated key rotation; ML-based detection; multiple providers	Large enterprises; security-focused orgs
5 - Optimizing	Industry-leading practices; innovation	Custom threat intelligence; formal verification; research contribution	Tech leaders; critical infrastructure

Start Where You Are

Organizations should assess their current maturity level and set realistic improvement goals. Moving from Level 1 to Level 3 typically provides the most security value for investment. Focus on quick wins like enabling DoH/DoT and registrar MFA before tackling complex DNSSEC deployments.

DNS Security Measures: Defense in Depth

Building a Comprehensive DNS Security Strategy

Defense in Depth Framework

Client-Side Security Configuration

Resolver Security Hardening

Authoritative DNS Security

Monitoring and Threat Detection

DNS Security Incident Response

DNS Security Governance and Policies

There’s more to understand.

DNS Security Measures: Defense in Depth

Building a Comprehensive DNS Security Strategy

Defense in Depth Framework

Client-Side Security Configuration

Resolver Security Hardening

Authoritative DNS Security

Monitoring and Threat Detection

DNS Security Incident Response

DNS Security Governance and Policies

There’s more to understand.