How to Implement DNS Security Controls: RPZ, DNSSEC, and DNS Filtering

# Install BIND9 on Ubuntu:
apt install bind9 bind9-utils -y

# Edit /etc/bind/named.conf.options:
options {
    # ... existing options ...
    
    # Enable DNSSEC validation:
    dnssec-validation auto;
    
    # Enable query logging:
    querylog yes;
    
    # Configure RPZ:
    response-policy {
        zone "rpz.malware-domains.local" policy NXDOMAIN;
        zone "rpz.phishing.local" policy NXDOMAIN;
        # Multiple zones processed in order; first match wins
    };
};

# Create the RPZ zone file: /etc/bind/db.rpz.malware
$TTL 300
@ IN SOA localhost. root.localhost. (
    2024010101  ; Serial
    3600        ; Refresh
    900         ; Retry
    604800      ; Expire
    300 )       ; Negative Cache TTL

@ IN NS localhost.

; Block specific malicious domains:
evil-c2-domain.com    IN CNAME .
*.evil-c2-domain.com  IN CNAME .
malware-dist.net      IN CNAME .
*.malware-dist.net    IN CNAME .
# CNAME . = NXDOMAIN (no such domain response)

# Add the RPZ zone to named.conf.local:
zone "rpz.malware-domains.local" {
    type master;
    file "/etc/bind/db.rpz.malware";
    allow-query { none; };
};

# Restart BIND9:
named-checkconf && systemctl restart bind9

# Test RPZ is working:
dig evil-c2-domain.com @localhost
# Expected: NXDOMAIN with authority section from RPZ zone

# Check BIND9 logs for RPZ hits:
tail -f /var/log/named/named.log | grep 'rpz'

Subscribe to external RPZ threat intelligence feeds:

# Configure BIND9 to pull RPZ from a remote threat intelligence provider:
# Many vendors provide RPZ feeds (Spamhaus, SURBL, Farsight Security)

# Example: Spamhaus RPZ DNSBL (subscription required for enterprise use):
zone "rpz.spamhaus.org" {
    type slave;
    masters { [spamhaus-transfer-ip] port 53; };
    file "/var/cache/bind/db.rpz.spamhaus";
    allow-query { none; };
};

# Free option: use Pi-hole as RPZ frontend with community blocklists:
# Pi-hole integrates with Gravity (blocklist aggregator) for free DNS blocking

Windows DNS Server added Response Policy Zone support in Windows Server 2016.

# Check Windows DNS Server version (RPZ requires Server 2016+):
Get-DnsServerSetting | Select-Object -ExpandProperty BuildNumber

# Add a Response Policy Zone to Windows DNS:
Add-DnsServerResponsePolicyZone \
    -Name 'rpz.malware-blocks' \
    -TransferTo 'None' \
    -PassThru

# Add specific domain blocking rules to the RPZ:
# Block a specific domain:
Add-DnsServerResponsePolicyZoneRule \
    -ZoneName 'rpz.malware-blocks' \
    -Name 'evil-c2-domain.com.' \
    -QType '*' \
    -Action NXDomain

# Block a domain and all subdomains:
Add-DnsServerResponsePolicyZoneRule \
    -ZoneName 'rpz.malware-blocks' \
    -Name '*.evil-c2-domain.com.' \
    -QType '*' \
    -Action NXDomain

# Import a blocklist from file (mass import):
$blocklist = Get-Content 'C:\DNS\blocklist.txt'  # One domain per line
foreach ($domain in $blocklist) {
    Add-DnsServerResponsePolicyZoneRule \
        -ZoneName 'rpz.malware-blocks' \
        -Name "$domain." \
        -QType '*' \
        -Action NXDomain
    Add-DnsServerResponsePolicyZoneRule \
        -ZoneName 'rpz.malware-blocks' \
        -Name "*.$domain." \
        -QType '*' \
        -Action NXDomain
}

# Verify RPZ is working:
Resolve-DnsName evil-c2-domain.com -Server [DNS-server-IP]
# Expected: no result returned (NXDomain)

# Enable Windows DNS audit logging (query logging):
Set-DnsServerDiagnostics \
    -Queries $true \
    -Answers $true \
    -FullPackets $false \
    -LogFilePath 'C:\Windows\System32\dns\dns-query-log.txt' \
    -MaxMBFileSize 500

Forward Windows DNS queries to Sentinel:

Windows DNS Server query logging writes to:
%SystemRoot%\System32\dns\dns-query-log.txt

Forward to Log Analytics workspace via:
- Azure Monitor Agent (AMA) with a custom table data collection rule
- Or: Microsoft Sentinel DNS connector (native integration for Windows DNS)

In Sentinel: Data connectors > DNS (Preview) > Connect
This automatically parses Windows DNS debug log format into:
DnsEvents table in Log Analytics

Threat hunting with DNS query logs:

// Detect DNS tunneling: high-volume queries with long subdomain names
DnsEvents
| where TimeGenerated > ago(24h)
| where SubType == "LookupQuery"
// Long subdomain names are characteristic of DNS tunneling (encoded data):
| extend SubdomainLength = strlen(extract(@'^([^.]+)\.', 1, Name))
| where SubdomainLength > 40  // 40+ char subdomain = likely encoded payload
// High query volume from one host to one domain:
| summarize
    QueryCount = count(),
    LongQueries = countif(SubdomainLength > 40)
    by Computer, Domain = tostring(split(Name, ".", 1)), bin(TimeGenerated, 1h)
| where LongQueries > 20  // Many long queries = DNS tunneling
| order by LongQueries desc

// Detect beaconing: regular-interval DNS queries to same domain
DnsEvents
| where TimeGenerated > ago(24h)
| where SubType == "LookupQuery"
// Look for consistent query intervals (C2 beaconing signature):
| summarize
    QueryCount = count(),
    Times = make_list(TimeGenerated, 100)
    by Computer, Name
| where QueryCount > 50  // Minimum query count to analyze
// High count, regular interval = beacon pattern
| order by QueryCount desc

// Detect newly registered domains (high risk):
DnsEvents
| where TimeGenerated > ago(24h)
| join kind=inner (
    ThreatIntelligenceIndicator
    | where Active == true
    | where NetworkDnsName != ""
    | project MaliciousDomain = NetworkDnsName, IndicatorId
) on $left.Name == $right.MaliciousDomain
| project TimeGenerated, Computer, Name, IndicatorId
// Match against MISP or other TIP indicators

DNS-over-HTTPS (DoH) encrypts DNS queries inside HTTPS: bypassing corporate DNS resolvers, RPZ blocklists, and query logging. Attackers increasingly use DoH to evade DNS-based controls.

Block known DoH providers at the firewall:

Block outbound HTTPS to DoH provider IPs:

# Major DoH providers (Palo Alto, Cisco, Fortinet have signature-based blocks):
# Cloudflare: 1.1.1.1, 1.0.0.1
# Google: 8.8.8.8, 8.8.4.4
# Quad9: 9.9.9.9, 149.112.112.112
# NextDNS: 45.90.28.0/23

# Firewall rule: block outbound HTTPS (443) to these IPs
# This prevents DoH bypassing the corporate DNS resolver

# Exception: allow DNS (UDP/TCP 53) to corporate DNS resolver ONLY
# Block DNS to all other destinations:
# Deny outbound UDP/TCP 53 to anything except [corporate DNS IPs]

Windows GPO to prevent browser DoH:

For Chrome:
Computer Configuration > Administrative Templates > Google > Google Chrome >
"DNS interception checks enabled": Disabled
"Use built-in DNS client": Disabled

For Firefox:
Deploy enterprise policy via GPO:
Computer Configuration > Administrative Templates > Mozilla > Firefox >
"DNS over HTTPS": Disabled (or set to "off")

Or via registry:
HKCU\SOFTWARE\Policies\Mozilla\Firefox
  DNSOverHTTPS.Enabled = 0

Configure DNSSEC validation on Windows DNS:

# Enable DNSSEC validation on Windows DNS resolver:
Set-DnsServerRecursion -Enable $true
# DNSSEC validation is enabled by default in Windows Server 2012+

# Verify DNSSEC validation is active:
Resolve-DnsName dnssec-failed.org -Type A
# If DNSSEC is working: this should return SERVFAIL (intentionally failing domain)
Resolve-DnsName dnssec.works -Type A
# This should return a valid IP (intentionally working DNSSEC domain)

# Check DNSSEC status on a specific zone:
Get-DnsServerDnsSecZoneSetting -ZoneName 'yourdomain.com'