Every chapter so far has treated DNS as something to defend — a vulnerable protocol that attackers exploit. But DNS is also one of the most powerful defensive tools in network security, leveraging the same caching and resolution mechanisms that make DNS fast. Every connection on the internet starts with a DNS query, which means DNS is the single best chokepoint for blocking threats before they reach their targets.
Protective DNS flips the script. Instead of asking “how do we secure DNS?”, it asks “how do we use DNS as security?”
DNS-Based Threat Blocking
The concept is simple: if malware needs to resolve evil-c2-server.com to phone home, and the DNS resolver returns a block page (or NXDOMAIN) instead of the real IP address, the malware can’t connect. The threat is neutralized before any malicious traffic flows.
This approach works because:
- DNS is universal. Every network-connected device uses DNS. You don’t need to install agents or configure firewalls on every endpoint.
- DNS is early. The DNS query happens before the connection is established. Blocking at the DNS layer prevents the TCP handshake, TLS negotiation, and data transfer from ever occurring.
- DNS is low-cost. Filtering DNS responses adds negligible latency and requires no deep packet inspection. A resolver can check a query against a blocklist in microseconds.
- DNS is observable. DNS queries provide a real-time stream of every connection attempt on the network — visibility that no other single protocol provides.
How It Works
Protective DNS resolvers maintain lists of known-malicious domains compiled from threat intelligence feeds. When a client queries for a domain on the blocklist, the resolver returns:
- NXDOMAIN — pretending the domain doesn’t exist
- A block page IP — redirecting to a page explaining the block
- 0.0.0.0 or 127.0.0.1 — a non-routable address that silently fails
- NODATA — a response with no records (the domain exists but has no records of the requested type)
The client never reaches the malicious server. The malware’s command-and-control channel is severed. The phishing page never loads.
Major Protective DNS Services
Quad9 (9.9.9.9)
Quad9 is a non-profit protective DNS service operated by the Quad9 Foundation, headquartered in Switzerland (for its strong privacy laws). It blocks queries to domains associated with malware, phishing, and other threats using threat intelligence from over 25 providers, including IBM X-Force, Abuse.ch, and numerous CERTs.
Key characteristics:
- No logging of client IP addresses — privacy-first design
- Swiss jurisdiction — subject to Swiss data protection law, not US or EU surveillance frameworks
- DNSSEC validation — all responses are validated
- Free for all users — funded by sponsorships and partnerships
Quad9 blocks approximately 100-150 million malicious queries per day across its global anycast network.
Cloudflare for Families (1.1.1.2 / 1.1.1.3)
Cloudflare extends its 1.1.1.1 resolver with filtered variants:
- 1.1.1.2 — blocks malware domains
- 1.1.1.3 — blocks malware and adult content
Built on Cloudflare’s global anycast network (300+ data centers), these resolvers combine Cloudflare’s own threat intelligence with third-party feeds. The malware blocking uses the same threat data that powers Cloudflare’s enterprise Gateway product.
Cisco Umbrella (OpenDNS)
Originally launched as OpenDNS in 2006, Cisco Umbrella is one of the oldest and most widely deployed protective DNS services. It processes over 620 billion DNS queries per day and uses machine learning models to predict malicious domains before they appear on traditional blocklists.
Umbrella’s key innovation was predictive blocking — analyzing domain registration patterns, WHOIS data, hosting infrastructure, and query patterns to identify likely-malicious domains before they’re used in attacks. A newly registered domain that shares hosting infrastructure with known malware, uses a domain generation algorithm (DGA) naming pattern, and was registered through a privacy service gets flagged proactively.
NextDNS
NextDNS offers highly customizable protective DNS with per-device configuration, detailed analytics, and user-controlled blocklists. Users can select from dozens of threat intelligence feeds, ad-blocking lists, and content filtering categories.
Unlike the other services, NextDNS provides granular analytics dashboards showing every blocked and allowed query, making it popular with technical users who want visibility into their DNS traffic.
DNS Firewalls: Response Policy Zones (RPZ)
For organizations that run their own recursive resolvers, Response Policy Zones (RPZ) provide a standardized mechanism for implementing DNS-based threat blocking locally.
RPZ, described in a draft specification and widely implemented in BIND, Unbound, and other resolver software, works by loading special zone files that define override policies for specific domains:
; RPZ zone file
$ORIGIN rpz.example.com.
; Block known malware domain (return NXDOMAIN)
malware-c2.evil.com CNAME .
; Redirect phishing domain to block page
phishing.bad.com A 10.0.0.1
; Block all subdomains of a malicious domain
*.malware-hosting.net CNAME .
; Log but don't block (passthru)
suspicious.domain.com CNAME rpz-passthru.
When the resolver receives a query matching an RPZ rule, it applies the policy instead of performing normal resolution. The policies can:
- Block (NXDOMAIN) —
CNAME . - Redirect — return a specific IP address
- Log only —
CNAME rpz-passthru.(allow the query but flag it) - Drop —
CNAME rpz-drop.(silently drop the query with no response)
RPZ Feeds
Organizations typically subscribe to commercial RPZ feeds from threat intelligence providers:
- Spamhaus — maintains RPZ feeds for malware, phishing, botnet C&C, and cryptocurrency mining domains
- Farsight DNSDB — provides passive DNS data for threat hunting
- SURBL — tracks domains used in spam and phishing campaigns
- Abuse.ch — community-driven feeds for malware and botnet tracking
RPZ feeds are distributed as zone transfers (AXFR/IXFR), allowing resolvers to receive updates in real time as new threats are identified. A resolver might load RPZ feeds from multiple providers, applying them in priority order.
Enterprise Deployment
In enterprise environments, RPZ is typically deployed on internal recursive resolvers:
┌─────────────┐
│ RPZ Feeds │
│ (Spamhaus, │
│ SURBL...) │
└──────┬──────┘
│ Zone Transfer
┌──────▼──────┐
Clients ──────────> │ Internal │ ──────> Internet DNS
│ Resolver │ (for allowed queries)
│ (with RPZ) │
└─────────────┘
│
┌──────▼──────┐
│ Block Page │
│ / Logging │
└─────────────┘
All internal clients use the organization’s resolver. RPZ policies block malicious queries before they leave the network. Logging captures blocked queries for security analytics and incident response.
Certificate Authority Authorization (CAA Records)
CAA records (RFC 8659, originally RFC 6844) are a DNS-based mechanism that specifies which certificate authorities are authorized to issue certificates for a domain.
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issuewild "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:security@example.com"
These records declare:
- issue — only Let’s Encrypt may issue standard certificates for
example.com - issuewild — only Let’s Encrypt may issue wildcard certificates
- iodef — send violation reports to
security@example.com
Certificate authorities are required to check CAA records before issuing certificates (per the CA/Browser Forum Baseline Requirements, effective September 2017). If a CAA record exists and the CA isn’t listed, the CA must refuse the certificate request.
Security Value
CAA records mitigate the threat of unauthorized certificate issuance that often accompanies DNS hijacking (as seen in the Sea Turtle campaign). Even if an attacker temporarily controls DNS for a domain, a CAA record can prevent them from obtaining certificates from CAs they haven’t anticipated.
However, CAA is not foolproof:
- An attacker who controls DNS can modify CAA records — the CAA check only helps if the attacker doesn’t think to change it, or if the window between DNS hijacking and certificate request is brief
- Not all CAs check CAA rigorously — while required, implementation quality varies
- CAA is advisory — there’s no cryptographic enforcement; it relies on CAs honoring the records
Despite these limitations, CAA records are a valuable defense-in-depth measure. They’re free to implement, add no operational overhead, and raise the bar for certificate fraud.
DNS Monitoring and Anomaly Detection
Beyond blocking, DNS traffic is a goldmine for security monitoring. Analyzing DNS query patterns can reveal compromised devices, data exfiltration, and advanced persistent threats.
What to Monitor
Query volume anomalies. A device that suddenly starts making thousands of queries per minute to a single domain is likely infected with malware. Normal browsing generates diverse queries; malware generates concentrated, repetitive patterns.
Newly registered domains. Domains registered within the past 24-48 hours are disproportionately associated with malicious activity. Monitoring queries to newly registered domains (using feeds like the Newly Observed Domains list) can catch phishing and malware campaigns in their early hours.
Domain generation algorithms (DGA). Many malware families generate pseudo-random domain names for their command-and-control servers (e.g., xk3j8f9a2.com, p7q2m5n8.net). DGA domains have distinctive characteristics: high entropy, unusual length, and no semantic meaning. Machine learning classifiers can identify DGA queries with high accuracy.
DNS tunneling signatures. As discussed in Chapter 1, DNS tunneling encodes data in subdomain labels, producing unusually long domain names with high entropy. Monitoring for excessive query lengths and high per-domain query rates can detect tunneling attempts.
Unusual record type requests. Normal DNS traffic is dominated by A, AAAA, and CNAME queries. A high volume of TXT, NULL, or ANY queries to a single domain suggests DNS tunneling or other abuse.
Passive DNS
Passive DNS databases collect and store DNS query-response data from sensors deployed at recursive resolvers (with appropriate authorization). These databases allow security analysts to:
- Track domain history — what IP addresses has a domain resolved to over time?
- Find related infrastructure — what other domains share the same IP address or nameserver?
- Identify fast-flux networks — domains that rapidly rotate through IP addresses, a common botnet technique
- Investigate incidents — what domains did a compromised device query?
Major passive DNS providers include Farsight DNSDB, Cisco Umbrella Investigate, and DomainTools. These databases are essential tools for threat intelligence and incident response teams.
SIEM Integration
DNS logs from internal resolvers are high-value data sources for Security Information and Event Management (SIEM) systems. Correlating DNS queries with other security telemetry (firewall logs, endpoint detection, authentication events) provides context that makes individual signals more actionable.
For example: a DNS query to a known malware C&C domain, combined with an unusual authentication event from the same source IP, combined with a firewall alert for outbound traffic on an unusual port, creates a high-confidence indicator of compromise that none of the signals would provide alone.
Building a Defensive DNS Strategy
An effective DNS security posture combines multiple layers:
- Protective DNS resolver — Quad9, Cloudflare for Families, or Umbrella for basic threat blocking
- Internal RPZ — for organizations that need customized blocking policies and control over their threat intelligence sources
- CAA records — limit certificate issuance to authorized CAs
- DNS monitoring — log and analyze query patterns for anomaly detection
- DNSSEC validation — ensure your resolver validates DNSSEC signatures
- Encrypted transport — DoH or DoT to protect query privacy from network observers
No single layer is sufficient. DNSSEC doesn’t block malware. Encrypted DNS doesn’t authenticate responses. Protective DNS doesn’t prevent BGP hijacking. Defense in depth — applying multiple, complementary controls — is the only approach that addresses the full threat landscape.
Key Takeaways
- Protective DNS blocks threats at the DNS layer — before malicious connections are established
- Quad9, Cloudflare for Families, and Cisco Umbrella provide free or commercial threat-blocking resolvers
- Response Policy Zones (RPZ) allow organizations to implement custom DNS-based blocking on their own resolvers
- CAA records restrict which certificate authorities can issue certificates for your domain
- DNS monitoring reveals compromised devices, data exfiltration, DGA activity, and tunneling attempts
- Passive DNS databases are essential for threat intelligence and incident investigation
- Defense in depth — combining protective DNS, DNSSEC, encrypted transport, and monitoring — provides comprehensive DNS security
You’ve completed Part 4: DNS Security. You now understand the threats DNS faces and the defenses that protect it. Next up, Part 5: Modern DNS Infrastructure explores how DNS powers today’s internet — from CDNs and load balancing to containers, edge computing, and serverless architectures.