A DNS sinkhole (also known as Blackhole DNS) is a security mechanism that prevents devices from connecting to malicious or unwanted domains.
When a client requests the IP address of a blocked domain, the DNS resolver replaces the legitimate answer with a controlled response. It may return NXDOMAIN, provide a null IP address, or redirect the request to an internal server.
This allows organizations to block malware command-and-control traffic, phishing websites, malicious downloads, unwanted trackers, and other suspicious destinations before a connection is established.
In this article, we will explain how DNS sinkholing works and show how to set up a DNS sinkhole using three open-source solutions: BIND 9, Unbound, and dnsmasq.
Table of Contents
What Is a DNS Sinkhole?
A DNS sinkhole is a security tool that blocks access to dangerous or unwanted websites at the DNS level.
Normally, when a device asks for a domain name, the DNS resolver returns the correct IP address so the connection can continue.
With a DNS sinkhole, the resolver checks the domain against a blocklist. If the domain is blocked, it does not return the real IP address. Instead, it may return an error such as NXDOMAIN or send the request to a safe internal address.
This prevents the device from connecting to the original destination and can help stop malware, phishing, and other suspicious activity.
How Does a DNS Sinkhole Work?
A DNS sinkhole operates on the recursive DNS resolver used by clients.
The process usually follows these steps:
- A device sends a DNS query to its configured resolver.
- The resolver checks the queried domain against its policy.
- If the domain is permitted, normal DNS resolution continues.
- If the domain is blocked, the resolver generates a modified response.
- The event may be recorded for security monitoring.
In simple terms:
Client device → Recursive DNS resolver → Policy check
- Allowed domain: The resolver returns the normal DNS answer.
- Blocked domain: The resolver returns
NXDOMAIN, a null address, or a controlled destination.
For the policy to work reliably, devices must use the approved resolver. If a client can query another DNS service, it may bypass the DNS sinkhole.
What Is DNS Sinkholing Used For?
DNS sinkholing can help prevent or identify several types of unwanted activity.
Blocking Malware Communication
Many malware families use domain names to locate command-and-control servers.
When those domains are blocked at the DNS level, infected devices cannot obtain the real server addresses. Repeated queries for the blocked domains may also help administrators identify compromised systems.
Preventing Access to Phishing Domains
A DNS sinkhole can block domains associated with fake login pages, credential theft, and other phishing campaigns.
Even if a user clicks a malicious link, the destination will not resolve normally.
Blocking Malicious Downloads
Domains known to distribute ransomware, trojans, scripts, or other malicious files can be added to the sinkhole policy.
Enforcing Network Policies
DNS filtering can also restrict access to unwanted applications, tracking services, advertising networks, or domains prohibited by an organization’s internal policy.
Common DNS Sinkhole Responses
A resolver can handle a blocked domain in several ways.
NXDOMAIN
NXDOMAIN tells the client that the requested domain does not exist.
This is often the best default because it produces a clear failure without requiring another server.
In RPZ syntax, an NXDOMAIN action is represented by:
bad-domain.example. CNAME .
RPZ defines policy rules as DNS records, with the record owner acting as the trigger and its data defining the action. CNAME . represents an NXDOMAIN response.
Null Address
The resolver can return:
0.0.0.0
for IPv4 and:
::
for IPv6.
This prevents access to the real destination, although some clients may attempt to connect to themselves when they receive a null address.
Controlled IP Address
The resolver can redirect a domain to an internal system:
bad-domain.example. 60 IN A 192.0.2.10
This can help record connection attempts or display a warning page.
Redirection should be used carefully with HTTPS. The internal server will normally not have a valid TLS certificate for the blocked domain, so the browser may display a certificate warning.
DROP or REFUSED
A resolver may silently drop the query or return REFUSED.
Dropping requests creates timeouts and retries, while REFUSED may encourage some clients to try another resolver. For most deployments, NXDOMAIN provides more predictable behavior.
Where Should a DNS Sinkhole Be Deployed?
A DNS sinkhole should normally be configured on the recursive resolvers used by workstations, servers, mobile devices, and other internal systems.
It should not usually be deployed on authoritative DNS servers.
Authoritative servers publish records for domains under their control. Recursive resolvers process queries from clients and are therefore the correct place to apply filtering policies.
A typical design looks like this:
Workstations and servers → Internal recursive resolvers → DNS sinkhole policy → Public DNS hierarchy
The resolver first checks the requested domain against the sinkhole policy. If the domain is allowed, the query continues normally. If it is blocked, the resolver returns a modified response, such as NXDOMAIN or a controlled IP address.
How to Set Up a DNS Sinkhole with BIND 9
BIND 9 supports Response Policy Zones, commonly called RPZ. RPZ policies are stored as DNS zone files, making them suitable for larger deployments and distribution between multiple resolvers. The BIND 9 documentation describes RPZ as its mechanism for implementing DNS firewall policies.
The following example returns NXDOMAIN for selected domains.
Step 1: Restrict Recursive Access
Never operate an unrestricted public recursive resolver.
Define the networks allowed to use the server:
acl “trusted-clients” {
127.0.0.1;
10.20.0.0/16;
192.168.50.0/24;
2001:db8:50::/48;
};
Add the recursive resolver settings:
options {
recursion yes;
allow-recursion {
trusted-clients;
};
allow-query-cache {
trusted-clients;
};
response-policy {
zone “rpz.local”;
};
};
Replace the example networks with the actual client networks.
Step 2: Define the Response Policy Zone
Add the RPZ zone configuration:
zone “rpz.local” {
type primary;
file “/etc/bind/zones/db.rpz.local”;
allow-query {
none;
};
allow-transfer {
none;
};
};
Direct queries to the policy zone should normally be restricted because the zone may reveal security indicators and filtering rules.
Step 3: Create the RPZ Zone File
Create /etc/bind/zones/db.rpz.local:
$TTL 60
@ IN SOA localhost. hostmaster.localhost. (
2026072101
300
60
86400
60
)
IN NS localhost.
; Block the exact domain
bad-domain.example. CNAME .
; Block its subdomains
*.bad-domain.example. CNAME .
; Another blocked domain
malware-host.example. CNAME .
*.malware-host.example. CNAME .
The first rule blocks the exact domain:
bad-domain.example
The wildcard blocks names below it:
www.bad-domain.example
api.bad-domain.example
Include both rules when the parent domain and all its subdomains must be blocked.
Step 4: Validate the Configuration
Check the BIND configuration:
named-checkconf
Validate the RPZ zone:
named-checkzone rpz.local /etc/bind/zones/db.rpz.local
Do not reload the resolver if either command reports an error.
Step 5: Reload BIND
Reload the configuration:
rndc reload
To reload only the policy zone:
rndc reload rpz.local
Step 6: Test the Sinkhole
Query the resolver directly:
dig @192.0.2.53 bad-domain.example A
The response should contain:
status: NXDOMAIN
Test a subdomain:
dig @192.0.2.53 www.bad-domain.example A
Also test IPv6 resolution:
dig @192.0.2.53 bad-domain.example AAAA
Finally, query an allowed domain to confirm that ordinary resolution still works.
How to Set Up a DNS Sinkhole with Unbound
Unbound is an open-source validating, recursive, and caching DNS resolver.
For a small sinkhole policy, use local-zone rules:
server:
local-zone: “bad-domain.example.” always_nxdomain
local-zone: “malware-host.example.” always_nxdomain
The always_nxdomain action returns NXDOMAIN for every matching query. Unbound also supports actions including always_null, always_refuse, redirect, and inform_redirect.
To return null IPv4 and IPv6 addresses:
server:
local-zone: “bad-domain.example.” always_null
To redirect queries to a controlled address and log the requesting clients:
server:
local-zone: “warning-domain.example.” inform_redirect
local-data: “warning-domain.example. 60 IN A 192.0.2.10“
local-data: “warning-domain.example. 60 IN AAAA 2001:db8:10::10“
The redirect action applies to the domain and its subdomains, while inform_redirect also records the client that sent the query.
Validate the configuration:
unbound-checkconf
Reload Unbound:
unbound-control reload
For larger deployments, Unbound also supports RPZ. RPZ policies can be stored in zone files, loaded from external sources, and transferred between resolvers using standard DNS mechanisms.
How to Set Up a DNS Sinkhole with dnsmasq
dnsmasq is a lightweight open-source DNS forwarder and cache designed primarily for smaller networks and resource-constrained systems.
To return NXDOMAIN for a domain and its subdomains:
address=/bad-domain.example/
To return null IPv4 and IPv6 addresses:
address=/bad-domain.example/#
To redirect the domain to a controlled server:
address=/warning-domain.example/192.0.2.10
address=/warning-domain.example/2001:db8:10::10
dnsmasq documents that an empty address returns NXDOMAIN, while # returns 0.0.0.0 and the IPv6 equivalent. Domain rules also apply to matching subdomains.
Query logging can be enabled with:
log-queries=extra
log-facility=/var/log/dnsmasq-queries.log
The extra logging mode includes the requesting client’s IP address and a serial number connecting log entries from the same query.
After updating the configuration, restart or reload dnsmasq using the service-management system provided by the operating system.
dnsmasq is suitable for smaller deployments. BIND RPZ or Unbound RPZ is generally easier to manage when policies contain large numbers of domains or must be shared across several resolvers.
How to Prevent DNS Sinkhole Bypass
A DNS sinkhole is effective only when clients actually use it.
To reduce bypass opportunities:
- Distribute the approved resolver addresses to clients
- Restrict direct outbound DNS traffic from client networks
- Apply controls to both TCP and UDP port 53
- Enforce the same policy over IPv4 and IPv6
- Monitor attempts to contact unauthorized resolvers
- Define how managed devices should handle encrypted DNS
- Ensure remote users receive the same resolver configuration
A DNS sinkhole cannot block direct connections to IP addresses, cached addresses, traffic inside an uncontrolled VPN, or queries sent through an alternative resolver.
It should therefore be one layer of a wider security strategy rather than a replacement for endpoint protection, firewalls, segmentation, monitoring, and patch management.
DNS Sinkhole Best Practices
For a reliable deployment:
- Use at least two recursive resolvers
- Restrict recursion to trusted networks
- Begin with high-confidence malicious domains
- Use NXDOMAIN as the default blocking action
- Maintain an allowlist for false positives
- Test both A and AAAA queries
- Track the source and age of every rule
- Remove expired domains and IP addresses
- Validate configurations before reloading
- Monitor query volume, memory use, and response time
- Log policy matches for incident investigation
- Protect DNS logs because they may reveal user activity
- Test policy updates before production deployment
DNSSEC and DNS Sinkholing
DNSSEC allows validating resolvers to verify that DNS data is authentic and has not been modified in transit.
A DNS sinkhole intentionally replaces an answer according to local policy. The modified response is therefore not the original signed answer from the authoritative DNS zone.
This does not mean DNSSEC validation should be disabled.
A secure resolver should continue validating permitted DNS responses so that it can:
- Detect invalid DNSSEC signatures
- Protect ordinary DNS resolution
- Distinguish validation failures from policy blocks
- Avoid making policy decisions based on manipulated upstream data
Test how the resolver handles DNSSEC flags, validation failures, logs, and policy-generated responses.
Frequently Asked Questions
What does a DNS sinkhole do?
A DNS sinkhole blocks or redirects DNS queries for selected domains. Instead of returning the real IP address, it provides a controlled response such as NXDOMAIN, a null address, or an internal destination.
Is a DNS sinkhole the same as a DNS firewall?
Not exactly. A DNS firewall is the broader policy system that analyzes DNS requests. Sinkholing is one action that the firewall or resolver can apply to a blocked request.
Should a DNS sinkhole return NXDOMAIN or 0.0.0.0?
NXDOMAIN is usually the cleaner default. It clearly indicates that the domain cannot be resolved. Null addresses can also work, but client behavior may vary.
Can a DNS sinkhole block malware?
It can disrupt malware that uses DNS to locate command-and-control systems or download additional files. It cannot stop malware that connects directly to an IP address or uses a DNS path outside the organization’s control.
Does DNS sinkholing work with IPv6?
Yes, but the configuration and network controls must cover AAAA requests and IPv6 connectivity. Blocking only IPv4 may leave another route available.
Conclusion
A DNS sinkhole turns a recursive resolver into an active security checkpoint.
It can prevent access to known malicious domains, interrupt malware communication, reduce exposure to phishing pages, and provide valuable information about devices making suspicious requests.
BIND 9 and RPZ are well suited to larger or distributed deployments. Unbound offers both simple local-zone filtering and RPZ support, while dnsmasq provides a lightweight option for smaller networks.
Regardless of the software used, a successful deployment requires controlled resolver access, IPv4 and IPv6 coverage, reliable logging, policy maintenance, redundancy, and regular testing.
When combined with other security controls, DNS sinkholing can stop unwanted traffic at one of the earliest possible stages: before the destination’s IP address ever reaches the client.
