DNS Security: Protecting Your Domain Infrastructure
Comprehensive guide to securing DNS infrastructure. DNSSEC, DoH, DoT, and defensive configurations for enterprise domains.
DNS is the phonebook of the internet-and like any critical infrastructure, it's a target. DNS attacks enable phishing, malware distribution, data exfiltration, and man-in-the-middle attacks. Despite this, DNS security is often an afterthought in enterprise security programs.
After a decade of managing DNS infrastructure for security-conscious organizations, I've seen the same vulnerabilities repeatedly. This guide covers practical DNS security measures that stop real attacks without requiring a PhD in protocol design.
The DNS Threat Landscape
Understanding threats helps prioritize defenses. DNS faces attacks at multiple layers:
┌─────────────────────────────────────────────────────────────────────────┐
│ DNS ATTACK VECTORS │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │
│ │ INTERCEPTION │ │ MANIPULATION │ │ AVAILABILITY │ │
│ ├─────────────────┤ ├─────────────────┤ ├─────────────────┤ │
│ │ │ │ │ │ │ │
│ │ • DNS Hijacking │ │ • Cache Poison │ │ • DDoS │ │
│ │ • MitM Attacks │ │ • Zone Transfer │ │ • Amplification │ │
│ │ • Eavesdropping │ │ • Record Inject │ │ • Resource Exh │ │
│ │ • BGP Hijacking │ │ • Registrar Att │ │ • Query Floods │ │
│ │ │ │ │ │ │ │
│ └────────┬────────┘ └────────┬────────┘ └────────┬────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │
│ │ SOLUTIONS │ │ SOLUTIONS │ │ SOLUTIONS │ │
│ │ │ │ │ │ │ │
│ │ • DoH/DoT │ │ • DNSSEC │ │ • Anycast │ │
│ │ • VPN/SASE │ │ • Registry Lock │ │ • Rate Limiting │ │
│ │ • Private DNS │ │ • CAA Records │ │ • Redundancy │ │
│ │ │ │ │ │ │ │
│ └─────────────────┘ └─────────────────┘ └─────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘
DNS Cache Poisoning injects fraudulent records into resolver caches. Attackers send forged responses hoping to beat legitimate answers. The Kaminsky attack (2008) demonstrated this at scale-while patches improved randomization, the fundamental vulnerability persists.
DNS Hijacking redirects queries at various points: compromised routers, malicious resolvers, or ISP-level interception. Users connect to attacker-controlled servers believing they're reaching legitimate destinations.
Zone Transfer Attacks exploit misconfigured authoritative servers that allow any client to download complete zone files. This reconnaissance reveals internal infrastructure, subdomains, and potential targets.
Registrar Attacks compromise domain registration accounts to modify nameservers or steal domains. High-profile incidents have redirected major brands to attacker infrastructure.
DNSSEC: Cryptographic DNS Validation
DNSSEC adds cryptographic signatures to DNS records. Resolvers can verify responses came from authoritative sources and weren't modified in transit.
How DNSSEC Works
┌─────────────────────────────────────────────────────────────────────────┐
│ DNSSEC CHAIN OF TRUST │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ ROOT ZONE (.) │
│ ┌─────────────────────────────────────────────┐ │
│ │ KSK (Key Signing Key) - signs DNSKEY │ │
│ │ ZSK (Zone Signing Key) - signs records │ │
│ │ DS record → points to .COM KSK │ │
│ └────────────────────┬────────────────────────┘ │
│ │ DS validates │
│ ▼ │
│ TLD ZONE (.COM) │
│ ┌─────────────────────────────────────────────┐ │
│ │ KSK + ZSK for .COM zone │ │
│ │ DS record → points to EXAMPLE.COM KSK │ │
│ └────────────────────┬────────────────────────┘ │
│ │ DS validates │
│ ▼ │
│ YOUR ZONE (EXAMPLE.COM) │
│ ┌─────────────────────────────────────────────┐ │
│ │ KSK + ZSK for EXAMPLE.COM zone │ │
│ │ RRSIG records sign all DNS records │ │
│ │ A, MX, TXT... all cryptographically signed │ │
│ └─────────────────────────────────────────────┘ │
│ │
│ Resolver validates entire chain from root → TLD → your domain │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Implementing DNSSEC
Most DNS providers now support DNSSEC with automated key management:
| Provider | DNSSEC Support | Key Management |
|---|---|---|
| Cloudflare | Full | Automatic |
| AWS Route 53 | Full | Automatic |
| Google Cloud DNS | Full | Automatic |
| Azure DNS | Full | Automatic |
| GoDaddy | Partial | Manual DS |
Cloudflare DNSSEC Activation:
- Navigate to DNS settings in Cloudflare dashboard
- Click "Enable DNSSEC"
- Add the DS record to your registrar
- Wait for propagation (up to 24 hours)
Verification:
# Check if DNSSEC is active
dig example.com +dnssec
# Look for 'ad' flag (authenticated data)
dig @8.8.8.8 example.com +dnssec +short
# Detailed validation
delv @8.8.8.8 example.com
DNSSEC Caveats
DNSSEC isn't without challenges:
- Key rotation: Keys must be rotated periodically. Automation is essential.
- Zone walking: NSEC records can reveal all subdomains (NSEC3 mitigates)
- Amplification: Signed responses are larger, potentially useful for DDoS
- Validation failures: Misconfiguration causes resolution failures-test thoroughly
Encrypted DNS: DoH and DoT
Traditional DNS queries travel in plaintext. Anyone on the network path-ISPs, coffee shop operators, attackers-can observe and potentially modify queries. Encrypted DNS protocols address this.
DNS over HTTPS (DoH)
DoH wraps DNS queries in HTTPS connections to port 443. This provides:
- Encryption: Queries hidden from network observers
- Authentication: Server certificates validate resolver identity
- Firewall evasion: Port 443 traffic rarely blocked
Client Configuration:
| Browser | DoH Configuration |
|---|---|
| Firefox | Settings → Privacy → DNS over HTTPS |
| Chrome | Settings → Security → Use secure DNS |
| Edge | Settings → Privacy → Use secure DNS |
| Safari | System-level (macOS Monterey+) |
Enterprise considerations:
DoH can bypass corporate DNS filtering. If you use DNS-based security controls (malware blocking, content filtering), configure endpoints to use your approved DoH resolver or disable DoH entirely.
DNS over TLS (DoT)
DoT uses TLS on port 853. Unlike DoH, it's clearly identifiable as DNS traffic:
┌─────────────────────────────────────────────────────────────────┐
│ DOH vs DOT COMPARISON │
├─────────────────────────────────────────────────────────────────┤
│ │
│ CHARACTERISTIC DoH DoT │
│ ────────────── ─── ─── │
│ Port 443 (HTTPS) 853 (dedicated) │
│ Protocol HTTPS TLS │
│ Visibility Hidden in HTTPS Identifiable │
│ Blockable Difficult Easy (port 853) │
│ Enterprise Control Challenging Manageable │
│ Browser Support Native Limited │
│ OS Support Growing Android 9+, iOS 14+ │
│ │
└─────────────────────────────────────────────────────────────────┘
Deploying Encrypted DNS at Scale
For organizations, deploy encrypted DNS at the resolver level:
- Run internal resolvers supporting DoH/DoT upstream
- Force endpoint DNS through DHCP and firewall rules
- Block external DNS (port 53, 853, DoH endpoints)
- Monitor for bypass attempts via 443
Defensive DNS Configuration
CAA Records
Certificate Authority Authorization (CAA) records specify which CAs may issue certificates for your domain. Without CAA, any CA could issue certificates-enabling MITM attacks if an attacker compromises any CA.
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issue "digicert.com"
example.com. CAA 0 issuewild "letsencrypt.org"
example.com. CAA 0 iodef "mailto:security@example.com"
| Tag | Purpose |
|---|---|
issue | CAs allowed to issue certificates |
issuewild | CAs allowed to issue wildcard certificates |
iodef | Email for violation reports |
Zone Transfer Restrictions
Zone transfers (AXFR) replicate zone data between nameservers. Restrict transfers to authorized secondary servers only:
# BIND configuration
zone "example.com" {
type master;
file "example.com.zone";
allow-transfer { 192.0.2.1; 192.0.2.2; };
};
Test your configuration:
# Should fail if properly configured
dig @ns1.example.com example.com AXFR
Response Rate Limiting
DNS amplification attacks abuse open resolvers. Even if you don't run an open resolver, rate limiting protects authoritative servers:
# BIND RRL configuration
rate-limit {
responses-per-second 10;
window 5;
};
Registry Lock
For critical domains, enable registry lock (also called "domain lock" or "transfer lock"). This requires manual, verified authorization for any changes to:
- Nameserver records
- Registrant information
- Transfer status
Registry lock stops attackers even if they compromise your registrar account. Contact your registrar about availability-it's typically offered for premium domains.
DNS Monitoring and Detection
Query Logging
Enable DNS query logging to detect:
- Malware beaconing: Periodic queries to suspicious domains
- Data exfiltration: Unusually long subdomain queries (DNS tunneling)
- Reconnaissance: AXFR attempts, ANY queries, version probes
# BIND query logging
logging {
channel query_log {
file "/var/log/named/query.log" versions 5 size 50m;
severity info;
print-time yes;
};
category queries { query_log; };
};
Threat Intelligence Integration
Integrate DNS with threat intelligence feeds:
| Solution | Integration Type | Coverage |
|---|---|---|
| Cisco Umbrella | Cloud resolver | Malware, phishing, C2 |
| Cloudflare Gateway | Cloud resolver | Malware, threats, content |
| Quad9 | Public resolver | Threat blocking |
| Pi-hole + feeds | Self-hosted | Customizable blocklists |
DNS Tunneling Detection
DNS tunneling exfiltrates data through DNS queries-long subdomains containing encoded data. Detection indicators:
- Query length > 50 characters
- High entropy in subdomain labels
- Unusual TXT record queries
- High query volume to single domain
# Example malicious query pattern
aGVsbG8gd29ybGQgdGhpcyBpcyBhIHRlc3Q.data.evil.com
Most DNS security platforms include tunneling detection. For DIY, analyze query logs for these patterns.
DNS Infrastructure Hardening
Authoritative Server Security
For self-hosted authoritative DNS:
- Run current software: BIND, PowerDNS, or NSD with latest patches
- Minimize exposure: Only DNS ports (53/tcp, 53/udp) accessible
- Separate recursion: Authoritative servers shouldn't recurse
- Version hiding: Don't reveal software version in responses
- Anycast deployment: Multiple geographic locations
# BIND version hiding
options {
version "none";
hostname "none";
};
Resolver Security
For internal resolvers:
- Access control: Only internal networks may query
- Forwarding strategy: Forward to trusted upstream resolvers
- DNSSEC validation: Enable validation for upstream responses
- Negative caching: Limit negative TTLs to reduce poisoning window
# BIND resolver configuration
options {
allow-query { 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; };
dnssec-validation auto;
forward only;
forwarders { 1.1.1.1; 8.8.8.8; };
};
DNS Security Checklist
Use this checklist to assess your DNS security posture:
| Control | Status | Priority |
|---|---|---|
| DNSSEC enabled on all domains | ☐ | High |
| CAA records configured | ☐ | High |
| Zone transfers restricted | ☐ | High |
| Registry lock on critical domains | ☐ | High |
| Query logging enabled | ☐ | Medium |
| DoH/DoT for internal resolvers | ☐ | Medium |
| Threat intelligence integration | ☐ | Medium |
| Rate limiting configured | ☐ | Medium |
| DNS tunneling detection | ☐ | Low |
| Regular configuration audits | ☐ | Low |
Implementation Priority
Start with high-impact, low-effort improvements:
Week 1:
- Enable DNSSEC (most providers: one click)
- Add CAA records
- Verify zone transfer restrictions
Week 2-3:
- Review registry lock options
- Deploy query logging
- Audit resolver access controls
Week 4+:
- Evaluate encrypted DNS deployment
- Integrate threat intelligence
- Implement monitoring and alerting
Next Steps
DNS security is foundational-vulnerabilities here undermine every other security control. Start with DNSSEC and CAA records, then build toward comprehensive DNS visibility and control.
We provide DNS security assessments covering authoritative configuration, resolver security, and monitoring capabilities. Request an assessment to identify gaps in your DNS security posture.
Managing complex DNS infrastructure across multiple providers? We help organizations consolidate and secure DNS at scale. Contact us to discuss your environment.