Emerging DNS-Based Security Techniques

DNS is a choke point. Every connection starts with a name resolution, which means DNS sits in front of every application-layer connection a device makes. This makes it a natural place to apply security controls: block the resolution, block the connection.

This isn't a new insight. DNS blacklisting has been around since the spam wars of the 1990s. What's changed is the sophistication of the threat intel driving those blocks, the speed at which new malicious infrastructure can be detected and actioned, and the depth of analysis passive DNS databases enable.

Response Policy Zones (RPZ)

RPZ (RFC 5782, with ISC's implementation documented separately) is the primary mechanism for DNS-layer blocking and policy enforcement in authoritative and recursive DNS servers.

A Response Policy Zone is a special zone in your recursive resolver that intercepts DNS responses and modifies them based on policy. When a client queries for a domain that matches an RPZ trigger, the resolver can return:

NXDOMAIN (the domain doesn't exist)
A redirect IP (send the user to a block page)
PASSTHRU (explicitly allow even if other policies would block)
DROP (don't respond at all)

RPZ triggers can match on:

The queried domain name (qname trigger): block malware.example.com
The response IP address (ip trigger): block any domain that resolves to this IP range
The name server of the domain (ns-name trigger): block all domains using this nameserver

; RPZ zone configuration in named.conf
response-policy {
    zone "rpz.example.org";
};

; In the RPZ zone file
; Block a specific domain (return NXDOMAIN)
malware.example.com.rpz-nsdname    IN CNAME    .

; Redirect to a block page
phishing.badactor.net.             IN CNAME    blockpage.internal.

; Block all domains resolving to a malicious IP range
32.0.0.1.10.rpz-ip                 IN CNAME    .

The real power of RPZ is that the zone can be updated dynamically, either by zone transfers from a threat intel provider or by your own tooling. When a new malicious domain is discovered, add it to the RPZ zone and it's blocked within seconds for all clients using that resolver.

Threat intel feeds. Commercial providers (Infoblox, IBM Security X-Force, SURBL, Spamhaus) distribute RPZ feeds via zone transfer or API. You subscribe, configure your resolver to receive updates, and get fresh blocklists automatically.

Free options include the Spamhaus RPZ feed (for small operators), various community-maintained lists, and domain blocklists that can be converted to RPZ format. The SANS Internet Storm Center maintains useful resources on converting common formats.

DNSBL: DNS-based blackhole lists

DNSBLs are the older, simpler precursor to RPZ. Originally designed for spam filtering, they work as a lookup service: to check if a domain or IP is on a blacklist, you query a special DNS zone.

To check if 192.0.2.1 is listed in a DNSBL:

Reverse the IP octets: 1.2.0.192
Append the DNSBL zone: 1.2.0.192.zen.spamhaus.org
Query for an A record. If you get a response (typically 127.0.0.x), the IP is listed.

# Check an IP against Spamhaus ZEN
dig +short 1.2.0.192.zen.spamhaus.org A

# Check a domain against SURBL
dig +short example.com.multi.surbl.org A

Mail servers have used DNSBLs for decades. Web application firewalls and DNS resolvers use them too. Spamhaus ZEN, SURBL, and Barracuda Central are long-running public DNSBLs. The data quality varies: some lists are aggressive and produce false positives; others are conservative and may miss fresh malicious domains.

Passive DNS

Passive DNS databases record historical DNS resolution data: which domain resolved to which IP address, when, and from where. They're built by running passive collection nodes across the internet: resolvers and sensors that record the answers to queries they see.

The major passive DNS databases:

DNSDB (Farsight Security, now part of DomainTools): one of the largest passive DNS collections
RiskIQ PassiveTotal (now Microsoft Defender Threat Intelligence)
VirusTotal passive DNS (integrated into VirusTotal's platform)
SecurityTrails

What passive DNS enables:

Historical lookups. badactor.com is pointing to 1.2.3.4 today. Passive DNS shows it pointed to 10.20.30.40 last month, which is the same IP that other-bad.com pointed to. You've just found related infrastructure.

Infrastructure pivoting. An IP address hosts a malicious domain. Passive DNS shows all other domains that pointed to the same IP. Many of them are likely related.

Domain age verification. Was this domain registered yesterday or in 2015? A 24-hour-old domain sending email that claims to be your bank is suspicious. A 10-year-old domain with consistent historical records is less so.

C2 infrastructure tracking. Malware families often reuse the same IP infrastructure even when rotating domain names. Passive DNS lets threat researchers track campaigns over time by following the infrastructure rather than the domains.

DNSDB's API:

# Using dnsdb-cli
dnsdb lookup rdata name example.com
dnsdb lookup rrset name example.com A

# Time-limited query: last 30 days
dnsdb lookup rrset name suspect.com --age-last 30d

The collection problem. Passive DNS is only as useful as the coverage of collection nodes. DNSDB has strong coverage from Farsight's sensor network, particularly in North America and Europe. Coverage is weaker in some regions. A domain that's never been queried through a collection node won't appear in passive DNS.

DNS-based C2 detection in practice

I described DGA detection in lesson 04. Passive DNS adds a different capability: tracking known malicious infrastructure over time.

Security teams use passive DNS in incident response: "this host was making DNS queries to these domains at this time: what do we know about those domains?" DNSDB or PassiveTotal lookups often reveal that a domain was registered in the past week, has no history before the incident, and resolves to an IP that hosts dozens of other recently registered domains. That pattern is consistent with C2 infrastructure.

In proactive threat hunting, analysts pivot through passive DNS to find domains registered by the same infrastructure or resolving to the same IPs as known-malicious domains. This is how researchers track APT infrastructure: find one domain used in an attack, pivot to the hosting IP, enumerate all domains at that IP historically, find related campaigns.

Domain monitoring for brand protection

At EBRAND, the X-RAY platform I built processes domain registrations at scale looking for patterns relevant to brand protection: domains that look like client brands, typosquats, phishing-ready registrations. This uses the same underlying capabilities as security-focused passive DNS analysis, monitoring registration patterns, flagging suspiciously similar domains as they appear, correlating hosting infrastructure with known-bad actors.

The DNS layer sees this activity early. A phishing campaign typically registers a lookalike domain, sets up hosting, and starts sending phishing emails within hours or days. If you're monitoring for domain registrations that match your brand in the first place, you have a window to act before the campaign causes damage.

This is an applied version of what security researchers do when tracking threat actor infrastructure: the domain-watching capability is the same, the purpose brand protection rather than malware tracking.

Key takeaways

RPZ is the standard mechanism for DNS-layer policy enforcement; most production recursive resolvers support it
Commercial RPZ threat intel feeds automate blocking of known-malicious domains within minutes of discovery
DNSBLs are simpler and older; useful for email security and IP reputation
Passive DNS databases (DNSDB, PassiveTotal) enable historical lookups and infrastructure pivoting
Passive DNS is essential for incident response and threat intelligence work
Domain monitoring at scale (new registrations, typosquats) provides early warning for phishing and brand abuse

Up next

Lesson 08: Case Studies: Real examples of advanced DNS in production: a CDN failover that worked, an ML detection that caught a real attack, and an IPv6 migration that didn't go well.