This chapter covers DNS filtering and sinkholing, two critical techniques for blocking malicious domains and detecting compromised hosts. For the SY0-701 exam, these concepts fall under Security Operations (Objective 4.4: Implement and maintain security operations techniques). Understanding how DNS filtering and sinkholing work, their differences, and their deployment is essential for scenario-based questions. This chapter will explain the mechanisms, key components, real-world examples, and common exam traps.
Jump to a section
Imagine a hotel concierge who receives all guest requests for directions or recommendations. When a guest asks for a specific restaurant, the concierge checks a list of approved, safe venues. If the restaurant is on the list, the concierge provides the address and directions. If the restaurant is blacklisted (known for poor hygiene or scams), the concierge refuses and suggests alternatives. This is DNS filtering: the DNS resolver acts as a concierge, checking requested domain names against a policy-based list (allowlist or blocklist) and either resolving the IP or returning a false response (like NXDOMAIN). Sinkholing is a more active defense: imagine the concierge has a trap street for criminals. When a known criminal asks for a specific address, the concierge sends them to a police station instead. Similarly, a DNS sinkhole redirects DNS queries for known malicious domains to a controlled IP address (often a sinkhole server) that logs the query and blocks the connection. This allows security teams to detect infected hosts, block malware callbacks, and analyze attacker infrastructure. The mechanism mirrors how a DNS resolver intercepts queries and returns a non-routable or internal IP to prevent harm.
What is DNS Filtering?
DNS filtering is a security technique that controls access to domain names based on a policy. It operates at the DNS resolution layer, intercepting DNS queries and comparing them against a list of allowed or blocked domains. The goal is to prevent users from accessing malicious, inappropriate, or unauthorized websites. DNS filtering can be implemented on local DNS servers, network appliances, or cloud-based DNS services.
How DNS Filtering Works
When a client (e.g., a workstation) wants to visit a website, it sends a DNS query to a DNS resolver (usually configured via DHCP). The resolver checks the requested domain against a policy:
If the domain is on an allowlist (whitelist), the query is resolved normally.
If the domain is on a blocklist (blacklist), the resolver returns a non-routable IP (e.g., 0.0.0.0), a false NXDOMAIN response, or redirects to a block page.
If the domain is not on either list, it may be resolved normally or subjected to further analysis (e.g., reputation scoring).
DNS filtering relies on threat intelligence feeds that provide lists of known malicious domains (e.g., from malware C2, phishing, or botnets). These feeds are updated frequently (sometimes in real-time).
Key Components and Variants
DNS Resolver: The server that performs the filtering. Examples: BIND, Unbound, Microsoft DNS Server, Cloudflare Gateway, Cisco Umbrella.
Policy Database: Contains rules (allow/block) and categories (e.g., malware, adult, social media).
Threat Intelligence Feeds: Sources of domains to block. Examples: Spamhaus, Suricata rules, commercial feeds.
Response Policy Zones (RPZ): A standard (RFC 5782) for distributing DNS blocklists. RPZ allows a DNS server to override responses for specific domains, returning a different IP or NXDOMAIN.
Variants include: - Category-based filtering: Blocks domains by category (e.g., gambling, phishing). - Reputation-based filtering: Blocks domains with low reputation scores. - Custom allow/block lists: Manually curated.
How Attackers Exploit or Defenders Deploy
Attackers try to evade DNS filtering by:
Using domain generation algorithms (DGAs) to create many random domain names, making it hard to block all.
Using fast flux DNS to rapidly change IP addresses.
Using DNS over HTTPS (DoH) or DNS over TLS (DoT) to encrypt queries, bypassing local filtering.
Defenders deploy DNS filtering by:
Configuring a local DNS server to use RPZ zones.
Using cloud-based DNS security services (e.g., OpenDNS, Quad9).
Integrating DNS filtering with SIEM for logging and alerting.
What is DNS Sinkholing?
DNS sinkholing is a more advanced technique where DNS queries for known malicious domains are redirected to a sinkhole server (a controlled IP address) instead of being simply blocked. The sinkhole server logs the query and often serves a harmless response (e.g., a web page with a warning) or drops the connection. This allows security teams to identify infected hosts, measure the spread of malware, and analyze attacker infrastructure.
How Sinkholing Works
An organization obtains a list of known malicious domains (e.g., from threat intelligence).
The DNS server is configured to return a specific IP address (the sinkhole IP) for those domains, rather than the real IP.
When a compromised host tries to connect to a malicious domain, the DNS query resolves to the sinkhole IP.
The sinkhole server logs the source IP, timestamp, and queried domain.
The host attempts to connect to the sinkhole IP, which may be a honeypot or a dead end. The connection fails, preventing the malware from communicating with its C2 server.
Key Components
Sinkhole Server: A server that listens on ports (e.g., HTTP/HTTPS) and logs incoming connections. Tools: F-Secure Sinkhole, custom Python scripts.
DNS Configuration: The DNS resolver (e.g., BIND) is configured with a zone file that maps malicious domains to the sinkhole IP.
Logging and Monitoring: Logs from the sinkhole server are fed into a SIEM for analysis.
Real Command/Tool Examples
Using BIND to implement a sinkhole: 1. Create a zone file for the malicious domain:
$TTL 86400
@ IN SOA ns1.example.com. admin.example.com. (
2023010101 ; serial
3600 ; refresh
1800 ; retry
604800 ; expire
86400 ) ; minimum
IN NS ns1.example.com.
@ IN A 10.0.0.2 ; sinkhole IP
* IN A 10.0.0.2 ; wildcard for subdomains2. Configure named.conf to use the zone:
zone "malware-domain.com" {
type master;
file "/etc/bind/db.malware-domain.com";
};Reload BIND: rndc reload
For cloud services like Cisco Umbrella, administrators can simply add domains to a block list, and the service automatically returns a sinkhole IP.
Comparison with DNS Filtering
DNS Filtering: Blocks or allows based on policy; returns NXDOMAIN or redirects to a block page. Does not log the query for analysis.
DNS Sinkholing: Redirects to a controlled IP that logs the query; allows detection of infected hosts. Often used in conjunction with filtering.
Standards and RFCs
RFC 5782: DNS Response Policy Zones (RPZ) – the standard for DNS filtering and sinkholing.
RFC 8484: DNS Queries over HTTPS (DoH) – relevant as it can bypass local filtering.
Exam Relevance
SY0-701 tests your understanding of how these techniques are used in security operations. You should know:
The difference between filtering and sinkholing.
How sinkholing helps detect infected hosts.
Common evasion techniques (DoH, DGA).
The role of RPZ.
Identify Malicious Domains
The first step is to obtain a list of known malicious domains from threat intelligence feeds. These feeds can be commercial (e.g., CrowdStrike, Proofpoint) or open-source (e.g., Spamhaus, AlienVault OTX). The list includes domains used for C2 communication, phishing, malware distribution, or botnet activity. For example, a feed might include `evil.com` and `bad.xyz`. The quality of the feed is critical; outdated or incomplete lists lead to false negatives (malware bypassing the filter) or false positives (blocking legitimate domains). In an enterprise, the SOC analyst configures the DNS resolver to pull these feeds automatically, often via RPZ.
Configure DNS Resolver for Filtering
The DNS resolver (e.g., BIND, Unbound, Windows DNS Server) is configured to apply policy based on the feed. For filtering, the resolver returns a non-routable IP (e.g., `0.0.0.0` or `127.0.0.1`) or a custom block page. For sinkholing, the resolver returns the IP of the sinkhole server. This is often done using RPZ zones. For example, in BIND, you add an RPZ zone and load the feed as a zone file. The configuration is tested to ensure it does not break legitimate DNS resolution. The resolver's logging is enabled to capture blocked queries.
Deploy Sinkhole Server
A sinkhole server is set up to listen on common ports (e.g., TCP 80, 443, 53) and log all incoming connections. The server can be a dedicated machine or a virtual machine with a simple web server (e.g., Apache or Nginx) configured to log requests. The sinkhole IP is added to the DNS configuration as the answer for malicious domains. When an infected host attempts to connect to `evil.com`, it resolves to the sinkhole IP, and the sinkhole server logs the source IP, timestamp, and requested domain. The server may also serve a harmless response (e.g., a 200 OK with a blank page) to keep the connection open for logging.
Monitor and Analyze Logs
The sinkhole server logs are sent to a SIEM (e.g., Splunk, ELK stack) for analysis. Analysts look for repeated connections from internal IPs to sinkholed domains, which indicate compromised hosts. For example, if the same IP queries `evil.com` every 5 minutes, it is likely infected with malware that attempts to contact its C2 server. The analyst correlates this with other logs (e.g., firewall, endpoint detection) to confirm the infection. The analyst then initiates incident response: isolating the host, scanning for malware, and removing the infection.
Update and Maintain Lists
Threat intelligence feeds must be updated regularly (e.g., every hour) to include new malicious domains. Attackers constantly register new domains or use DGAs to generate random ones. The DNS resolver should automatically fetch updated RPZ zones. Additionally, false positives are reviewed and whitelisted if necessary. For example, if a legitimate marketing domain is mistakenly blocked, the analyst adds it to an allowlist. The maintenance also includes removing outdated domains that are no longer malicious. This step ensures the filtering remains effective and minimizes business disruption.
Scenario 1: Enterprise SOC Detecting C2 Traffic
A large enterprise uses a DNS sinkhole to detect malware infections. An analyst notices a spike in DNS queries to a newly registered domain update-software.xyz from multiple workstations. The domain is not on any blocklist yet. The analyst manually adds it to the sinkhole configuration. Within hours, the sinkhole server logs connections from 50 internal IPs. The analyst correlates this with endpoint detection logs and finds that these hosts have a new variant of TrickBot malware. The incident response team isolates the hosts and removes the malware. The common mistake here would be to ignore the initial spike, assuming it's legitimate software update traffic. The correct response is to investigate the domain's reputation and add it to the sinkhole proactively.
Scenario 2: DNS Filtering Blocking Phishing
A company deploys DNS filtering via a cloud service like Cisco Umbrella. A user receives a phishing email with a link to secure-bank-login.com. When the user clicks the link, the DNS query is intercepted by the cloud resolver, which checks the domain against its threat intelligence. The domain is categorized as phishing and blocked. The user sees a block page warning them of the malicious site. The SOC receives an alert about the blocked query and the user's identity. The analyst follows up with the user to confirm they did not enter credentials elsewhere. The common mistake is to disable filtering for that user to avoid alerts, which would expose them to future phishing.
Scenario 3: Bypass via DoH
A malicious insider configures their browser to use DNS over HTTPS (DoH) with a public resolver (e.g., Google's 8.8.8.8). This bypasses the corporate DNS filter. The host successfully resolves a malicious domain and connects to a C2 server. The SOC notices unusual outbound traffic to a suspicious IP but cannot see the DNS query in their logs. The analyst must rely on other indicators (e.g., endpoint detection, netflow) to identify the compromise. The correct response is to block DoH at the firewall level (e.g., blocking port 443 to known DoH providers) or use TLS inspection. The common mistake is to assume DNS filtering alone is sufficient; attackers can bypass it with encrypted DNS.
What SY0-701 Tests
Objective 4.4 (Security Operations) includes DNS filtering and sinkholing under "Implement and maintain security operations techniques." The exam expects you to:
Distinguish between DNS filtering and sinkholing.
Know how sinkholing helps detect compromised hosts.
Understand evasion techniques (DoH, DGA, fast flux).
Identify the role of RPZ.
Common Wrong Answers and Why
"DNS filtering blocks all traffic to malicious IPs" – Wrong: DNS filtering blocks domain name resolution, not IP-based traffic. IP blocking is done by firewalls.
"Sinkholing prevents all malware from executing" – Wrong: Sinkholing only blocks C2 communication; malware may still execute locally.
"DNS filtering and sinkholing are the same" – Wrong: Filtering blocks queries; sinkholing redirects to a logging server.
"DNS filtering uses deep packet inspection" – Wrong: DNS filtering operates at the DNS layer, not packet inspection.
Specific Terms to Memorize
RPZ (Response Policy Zone) – RFC 5782.
NXDOMAIN – DNS response code for non-existent domain.
DGA (Domain Generation Algorithm) – used by malware to evade filtering.
DoH (DNS over HTTPS) – encrypts DNS queries, bypassing filtering.
Sinkhole IP – typically a private IP (e.g., 10.0.0.2) or loopback (127.0.0.1).
Common Trick Questions
A scenario describes a host making repeated DNS queries to random domains. The question asks for the best defense. Answer: Use a DGA-based detection or sinkhole; not simply block all random domains.
A question asks about the purpose of a sinkhole. Answer: To detect infected hosts by logging connections.
A scenario where a user can access a malicious site despite DNS filtering. Answer: The user may be using DoH; implement firewall rules to block DoH.
Decision Rule for Eliminating Wrong Answers
When faced with a scenario question about DNS filtering or sinkholing: 1. Identify if the goal is to block (use filtering) or to detect (use sinkhole). 2. If the question mentions "detecting compromised hosts," the answer involves sinkholing. 3. If the question mentions "preventing access to malicious sites," the answer involves filtering. 4. Eliminate answers that mention IP-based blocking (that's firewall/NGFW). 5. Eliminate answers that suggest using deep packet inspection for DNS (DNS is lightweight).
DNS filtering blocks domain resolution based on allow/block lists; sinkholing redirects to a logging server.
Sinkholing is primarily used to detect infected hosts by capturing DNS queries to malicious domains.
RPZ (Response Policy Zone, RFC 5782) is the standard for distributing DNS blocklists and sinkhole configurations.
Attackers evade DNS filtering using DoH (DNS over HTTPS), DGA (Domain Generation Algorithms), and fast flux DNS.
DNS filtering operates at the DNS layer; it does not block direct IP access or inspect traffic content.
A sinkhole server typically uses a private IP (e.g., 10.0.0.2) to log connections from compromised hosts.
SY0-701 expects you to differentiate between filtering and sinkholing in scenario-based questions.
These come up on the exam all the time. Here's how to tell them apart.
DNS Filtering
Returns NXDOMAIN, non-routable IP, or block page
Primarily blocks access to malicious domains
Does not log queries by default; may log blocked queries
Simpler to implement; often cloud-based
Used for content control and malware blocking
DNS Sinkholing
Redirects to a controlled sinkhole IP
Logs all queries to sinkholed domains for analysis
Actively logs source IP, timestamp, queried domain
Requires a sinkhole server and log management
Used for detection of compromised hosts and threat intelligence
Mistake
DNS filtering and web filtering are the same thing.
Correct
DNS filtering blocks domain name resolution, while web filtering (proxy) inspects HTTP/HTTPS traffic. DNS filtering is lighter but cannot block direct IP access or encrypted traffic.
Mistake
A DNS sinkhole is only useful for blocking malware.
Correct
Sinkholes are also used for identifying compromised hosts, measuring infection spread, and analyzing attacker infrastructure by logging all connections.
Mistake
DNS filtering prevents all malware infections.
Correct
DNS filtering only blocks C2 communication via DNS; malware can still infect via other vectors (e.g., USB, email attachments) and use IP addresses directly.
Mistake
DNS over HTTPS (DoH) makes DNS filtering impossible.
Correct
DoH can be blocked at the firewall by blocking known DoH provider IPs or using TLS inspection. It does not make filtering completely impossible, but it complicates it.
Mistake
RPZ is a type of malware.
Correct
RPZ (Response Policy Zone) is a DNS standard (RFC 5782) for distributing blocklists and sinkhole configurations. It is not malware.
DNS filtering blocks or allows domain resolution based on a policy, returning NXDOMAIN or a block page. DNS sinkholing redirects queries for malicious domains to a controlled IP (sinkhole) that logs the connection, allowing detection of infected hosts. Filtering is for prevention; sinkholing is for detection.
When a compromised host tries to resolve a malicious domain, the DNS resolver returns the sinkhole IP. The host then attempts to connect to the sinkhole server, which logs the source IP, timestamp, and domain. Analysts review these logs to identify infected devices.
RPZ stands for Response Policy Zone, defined in RFC 5782. It allows a DNS server to override responses for specific domains, returning alternative IPs or NXDOMAIN. RPZ is used to implement DNS filtering and sinkholing by distributing blocklists.
Yes, attackers can use DNS over HTTPS (DoH) to encrypt queries, bypassing local DNS filtering. They can also use domain generation algorithms (DGAs) to create many random domains, making it hard to block them all. Fast flux DNS constantly changes IP addresses to evade filtering.
Common sinkhole IPs include private IPs like 10.0.0.2 or loopback 127.0.0.1. In production, an internal IP that is not routable externally is used to ensure that malicious traffic is captured and logged.
A client sends a DNS query to a resolver. The resolver checks the domain against a policy (allow/block list). If blocked, the resolver returns a false response (e.g., NXDOMAIN). If allowed, it resolves normally. This prevents the client from reaching malicious sites.
Threat intelligence feeds provide lists of known malicious domains (e.g., C2 servers, phishing sites). DNS filtering uses these feeds to automatically update blocklists, ensuring that new threats are blocked quickly.
You've just covered DNS Filtering and Sinkholing — now see how well it sticks with free SY0-701 practice questions. Full explanations included, no account needed.
Done with this chapter?