DNS Filtering: Blocking Malicious Domains at the Network Level

Bottom Line Up Front

DNS filtering acts as your network’s first line of defense by blocking access to malicious, phishing, and unwanted domains before connections are established. When a user or system attempts to resolve a domain name, your DNS filter checks it against threat intelligence feeds and policy rules — blocking dangerous requests and logging everything for compliance and incident response.

This control addresses multiple compliance requirements across SOC 2 (CC6.1 network controls), ISO 27001 (A.13.1.1 network controls management), NIST CSF (Protect function), CMMC (AC.L2-3.1.20 for network access control), and HIPAA (Administrative, Physical, and Technical Safeguards). For organizations handling sensitive data, DNS filtering provides both security value and audit evidence for network-level threat protection.

Unlike endpoint-only security tools, DNS filtering protects all devices on your network — including IoT devices, mobile phones, and unmanaged systems that might lack comprehensive endpoint protection. It’s particularly effective against command-and-control (C2) communications, data exfiltration attempts, and drive-by download attacks.

Technical Overview

How DNS Filtering Works

DNS filtering intercepts domain name resolution requests before they reach public DNS servers like 8.8.8.8 or 1.1.1.1. When a user types a URL or an application makes a network request, the DNS filter evaluates the domain against several criteria:

• Threat intelligence feeds from commercial and open-source providers
• Category-based policies (malware, phishing, adult content, social media)
• Custom blocklists and allowlists specific to your organization
• Newly registered domains and domain generation algorithm (DGA) detection
• DNS tunneling and DNS-over-HTTPS (DoH) abuse prevention

The filter responds with either the legitimate IP address, a blocked response, or redirects to a block page explaining why access was denied. All requests — allowed and blocked — generate logs for security monitoring and compliance reporting.

Architecture and Data Flow

In a typical deployment, DNS filtering sits between your internal network and external DNS infrastructure:

“`
User Request → Internal DNS → DNS Filter → Threat Intelligence Check → Allow/Block Decision
“`

Cloud-based solutions like Umbrella, Cloudflare for Teams, or NextDNS process requests through their global infrastructure, providing threat intelligence updates in real-time without on-premises hardware.

On-premises solutions like pfBlockerNG, Pi-hole, or enterprise appliances give you complete control over data and policies but require local maintenance and threat feed management.

Hybrid approaches combine local caching and policy enforcement with cloud-based threat intelligence, balancing performance with security.

Where DNS Filtering Fits in Defense in Depth

DNS filtering operates at the network layer of your security stack, complementing rather than replacing other controls:

• Above: Endpoint detection and response (EDR), application security
• Alongside: Firewalls, intrusion prevention systems (IPS), secure web gateways
• Below: network segmentation, VPN access controls

This positioning makes DNS filtering particularly valuable because it catches threats that might bypass email security or exploit unpatched endpoints. It also provides visibility into potentially compromised internal systems attempting to communicate with known bad domains.

Cloud vs. On-Premises Considerations

Cloud-based DNS filtering integrates easily with remote workforces and cloud infrastructure but requires trust in your provider’s data handling and uptime. Configure your cloud DNS filter to log to your SIEM and maintain backup DNS resolution for business continuity.

On-premises solutions work well for air-gapped environments or organizations with strict data residency requirements. However, you’ll need to manage threat feed updates, certificate management for HTTPS inspection, and high availability configurations yourself.

Hybrid deployments let you keep sensitive DNS queries local while leveraging cloud threat intelligence for unknown domains. This approach works particularly well for organizations with both cloud and on-premises infrastructure.

Compliance Requirements Addressed

SOC 2 Type II Requirements

DNS filtering primarily addresses CC6.1 (Logical and Physical Access Controls) by implementing network-level access restrictions based on security policies. Your SOC 2 auditor will want to see:

• Documented DNS filtering policies aligned with your risk assessment
• Regular review and updates of blocked domain categories
• Monitoring and alerting on DNS filter bypass attempts
• Incident response procedures for DNS-based threats

Compliant: Basic category blocking (malware, phishing) with quarterly policy reviews.
Mature: Real-time threat intelligence integration, automated incident response, and behavioral analysis of DNS patterns.

ISO 27001 Control Mapping

DNS filtering supports several Annex A controls:

• A.13.1.1 Network Controls Management: DNS filtering as a network security control
• A.12.2.1 Controls Against Malware: Blocking access to malware distribution sites
• A.16.1.1 Management of Information Security Incidents: DNS logs for incident detection

Your Statement of Applicability (SoA) should document how DNS filtering contributes to your risk treatment plan, particularly for threats involving malicious domains and data exfiltration.

NIST Cybersecurity Framework

DNS filtering aligns with multiple NIST CSF subcategories:

• PR.AC-4: Access permissions are managed
• PR.PT-4: Communications and control networks are protected
• DE.CM-1: Networks and network services are monitored
• RS.MI-2: Incidents are mitigated

CMMC and NIST 800-171

For defense contractors, DNS filtering helps satisfy AC.L2-3.1.20 (Control Network Access) and SI.L1-3.14.1 (Identify and Block Malicious Content). Document your DNS filtering as part of your system security plan (SSP) and include it in your continuous monitoring strategy.

HIPAA Security Rule

DNS filtering supports Administrative Safeguards (§164.308(a)(1)) by preventing access to sites that could compromise PHI, and Technical Safeguards (§164.312(a)(1)) through network-level access controls.

Evidence Requirements

Your auditor will expect to see:

• Policy documentation: Which categories and domains are blocked, review frequency
• Configuration snapshots: Current DNS filter settings and rule sets
• Log samples: Blocked and allowed DNS requests over the audit period
• Incident reports: How DNS filtering detected and helped respond to security events
• Review records: Evidence of periodic policy updates and threat feed validation

Implementation Guide

Step 1: Choose Your Deployment Model

Cloud-Based Implementation (Recommended for Most Organizations)

For Cloudflare for Teams:

• Create a Cloudflare for Teams account and configure your organization
• Update your network’s DNS settings to point to Cloudflare’s filtering resolvers
• Install the WARP client on endpoints for roaming protection
• Configure policies in the Gateway dashboard

“`bash

Configure DNS settings on Ubuntu/Debian

sudo systemctl stop systemd-resolved
echo “nameserver 162.159.36.1” | sudo tee /etc/resolv.conf
echo “nameserver 162.159.132.1” | sudo tee -a /etc/resolv.conf
“`

For Cisco Umbrella:

• Deploy the Umbrella roaming client or configure DNS redirection
• Set up site-to-site policies in the Umbrella dashboard
• Configure Active Directory integration for user-based policies
• Enable SIEM integration for log forwarding

On-Premises Implementation

Using pfBlockerNG on pfSense:

• Install pfBlockerNG from the Package Manager
• Configure DNSBL feeds (I-BlockList, Spamhaus, custom feeds)
• Set up logging and alerting for blocked requests
• Create custom allowlists for business-critical domains

“`bash

Example pfBlockerNG DNSBL configuration

Navigate to Firewall > pfBlockerNG > DNSBL > DNSBL Feeds

Enable feeds: Abuse.ch, Malware Domain List, Phishing Database

Set logging to “Enabled” for compliance evidence

“`

Step 2: Configure Security Policies

Basic Policy Framework:

Category	Action	Business Justification
Malware	Block	Security requirement
Phishing	Block	Security requirement
Command & Control	Block	Security requirement
Adult Content	Block/Log	HR policy compliance
Social Media	Log Only	Productivity monitoring
Newly Registered Domains	Alert	Risk assessment

Advanced Policy Configuration:

“`yaml

Example policy for enterprise DNS filtering

security_categories:
– malware: block_with_alert
– phishing: block_with_alert
– c2: block_with_siem_forward
– cryptomining: block_with_alert

business_categories:
– social_media: log_only
– streaming: bandwidth_limit
– shopping: log_only

custom_rules:
– block_dga_domains: true
– block_dns_tunneling: true
– allow_business_critical:
– salesforce.com
– microsoft.com
– your-saas-providers.com
“`

Step 3: Integrate with Security Tooling

SIEM Integration

Configure your DNS filter to forward logs to your SIEM (Splunk, Elastic, Chronicle):

“`bash

Splunk Universal Forwarder configuration for DNS logs

[monitor:///var/log/dns_filter/blocked_requests.log]
index = security
sourcetype = dns_filter
host = dns-filter-01

Sample log format to expect:

2024-01-15 10:30:15 BLOCKED user@company.com malware.example.com malware category

“`

SOAR Integration

Create automated playbooks for high-risk DNS events:

“`python

Example SOAR playbook trigger

if dns_event.category == “c2” and dns_event.internal_ip:
# Isolate potentially infected endpoint
isolate_endpoint(dns_event.internal_ip)
# Create incident ticket
create_incident(“Potential C2 Communication”, dns_event)
# Notify SOC
send_alert(“High Priority DNS Block”, dns_event)
“`

Step 4: Infrastructure as Code Configuration

Terraform Example for AWS Route 53 Resolver DNS Firewall:

“`hcl
resource “aws_route53_resolver_firewall_domain_list” “malware_domains” {
name = “malware-blocklist”
domains = [
“malware-example.com”,
“*.phishing-site.org”,
“known-bad-domain.net”
]

tags = {
Environment = “production”
Compliance = “soc2-cc6.1”
}
}

resource “aws_route53_resolver_firewall_rule” “block_malware” {
name = “block-malware-domains”
action = “BLOCK”
firewall_domain_list_id = aws_route53_resolver_firewall_domain_list.malware_domains.id
firewall_rule_group_id = aws_route53_resolver_firewall_rule_group.main.id
priority = 100

block_response = “NODATA”
}
“`

Operational Management

Daily Monitoring and Alerting

Set up automated monitoring for DNS filtering health and security events:

Key Metrics to Track:

• Total DNS queries processed
• Blocked request percentage and trends
• Top blocked categories and domains
• DNS filter bypass attempts
• Query latency and availability

Critical Alerts:

• DNS filter service outage or degraded performance
• Unusual spike in blocked requests from specific internal IPs
• Attempts to use alternative DNS servers (potential filter bypass)
• New command-and-control domains blocked

“`bash

Sample monitoring script for DNS filter health

#!/bin/bash

Check DNS filter response time

response_time=$(dig @your-dns-filter example.com | grep “Query time” | awk ‘{print $4}’)

if [ “$response_time” -gt 500 ]; then
echo “ALERT: DNS filter response time elevated: ${response_time}ms”
# Send to monitoring system
fi
“`

Log Review and Analysis

Weekly Reviews:

• Analyze top blocked domains for new threat patterns
• Review allowlist requests and approve legitimate business needs
• Check for DNS tunneling or suspicious query patterns
• Validate threat feed accuracy (false positives/negatives)

Monthly Deep Dives:

• Correlate DNS blocks with endpoint security alerts
• Review policy effectiveness and adjust categories
• Analyze user behavior patterns around blocked content
• Generate compliance reports for audit preparation

Change Management for Compliance

All DNS filtering changes require documentation for audit trails:

Standard Change Process:

• Request: Business justification for allowlist/blocklist changes
• Approval: Security team review and risk assessment
• Implementation: Staged rollout with testing
• Validation: Confirm changes work as expected
• Documentation: Update change log and policy documentation

Emergency Changes: For security incidents, implement first and document afterward, but ensure you have pre-approved emergency change procedures.

Annual Review and Recertification

Policy Review Tasks:

• Validate all blocked categories still align with business risk tolerance
• Review custom allowlists for business necessity
• Update threat intelligence feeds and validate quality
• Test DNS filtering bypass detection and alerting
• Review and update incident response procedures for DNS-based threats

Compliance Documentation Updates:

• Update risk assessments with new threat landscape
• Refresh DNS filtering documentation for auditors
• Validate evidence collection procedures
• Test log retention and retrieval processes

Common Pitfalls

Implementation Mistakes That Create Compliance Gaps

Insufficient Logging: Many organizations enable DNS filtering but fail to configure comprehensive logging. Your compliance framework likely requires evidence of the control’s operation — blocked requests, policy changes, and system health events.

Over-Reliance on Default Policies: Vendor default settings rarely align with your risk assessment. Document why you chose specific categories and review them regularly. Auditors want to see thoughtful policy decisions, not checkbox implementations.

Poor Integration with Incident Response: DNS filtering alerts often get ignored because they’re not properly integrated into your security operations workflow. Ensure blocked C2 communications trigger your incident response process.

Performance and Usability Trade-Offs

DNS Latency Impact: Aggressive filtering or poorly configured cloud DNS can add 50-100ms to web requests. Monitor user experience and implement local caching where appropriate.

False Positive Management: Legitimate business domains sometimes get miscategorized. Establish a clear process for users to request access and ensure your allowlist changes don’t create security gaps.

Mobile and Remote Worker Coverage: DNS filtering works well for office networks but requires additional configuration (VPN, roaming clients) for remote workers. Don’t assume your policy applies to all users.

The Checkbox Compliance Trap

Blocking Without Understanding: Simply enabling “malware” and “phishing” categories isn’t enough for mature security. Understand what domains you’re blocking and why. Tune your filters based on your organization’s actual threat profile.

Ignoring DNS Filter Logs: Compliance requires evidence that controls are operating effectively. If you’re not reviewing DNS filtering logs and incorporating them into security monitoring, you’re missing both compliance value and security insights.

Set-and-Forget Mentality: Threat landscapes evolve rapidly. DNS filtering requires ongoing tuning, threat feed updates, and policy refinement. Static configurations become less effective over time and may not satisfy “continuous monitoring” requirements in frameworks like CMMC.

FAQ

How granular should DNS filtering policies be for compliance requirements?

Your DNS filtering granularity should align with your risk assessment and data classification. For basic SOC 2 compliance, blocking malware, phishing, and command-and-control domains is sufficient. For HIPAA or CMMC environments, consider additional categories like file sharing, anonymizers, and dynamic DNS services that could facilitate data exfiltration. Document your policy decisions based on business risk, not just technical capability.

Can DNS filtering satisfy network segmentation requirements in compliance frameworks?

DNS filtering provides application-layer access control but doesn’t replace true network segmentation required by frameworks like PCI DSS or CMMC Level 3. However, it complements segmentation by preventing lateral movement through DNS-based attacks and provides visibility into cross-segment communications. Use DNS filtering as part of your layered network security approach, not as a standalone segmentation solution.

How do we handle DNS filtering for cloud-native applications and microservices?

Cloud-native environments require DNS filtering integration at the container orchestration level. For Kubernetes, implement DNS policies using tools like CoreDNS with filtering plugins or service mesh