DNS Sinkholing Explained

How DNS Sinkholing Works

Every time a device on your network tries to reach a website, application server, or cloud service, it starts with a DNS query. The device asks "what is the IP address for this domain name?" and a DNS resolver answers. DNS sinkholing intercepts this process. When a device queries a domain that appears on a blocklist, the sinkhole resolver returns a fake answer - either a non-routable IP address (like 0.0.0.0) or an NXDOMAIN response (domain does not exist).

The device receives this fake answer and tries to connect to the non-routable address. The connection fails silently. The device never reaches the malicious server. From the user's perspective, the bad domain simply does not load.

This happens before any network connection is established. The malicious server never sees a single packet from your network. Compared to a firewall rule that blocks connections to a specific IP, DNS sinkholing is more flexible because it operates on domain names - which are more stable identifiers than IP addresses that change frequently.

graph TD
    subgraph "Normal DNS Resolution"
        DEV1[Device] -->|Query: example.com| DNS1[DNS Resolver]
        DNS1 -->|Answer: 93.184.216.34| DEV1
        DEV1 -->|Connect to 93.184.216.34| SERVER1[Legitimate Server]
    end
    subgraph "DNS Sinkholing"
        DEV2[Device] -->|Query: malware-c2.bad| SINK[Sinkhole Resolver]
        SINK -->|Check Blocklist| BL[Blocklist Database]
        BL -->|Domain Found on List| SINK
        SINK -->|Answer: 0.0.0.0| DEV2
        DEV2 -->|Connect to 0.0.0.0| FAIL[Connection Fails Silently]
    end
    subgraph "Sinkhole Logging"
        SINK -->|Log: Device X queried blocked domain| LOG[Query Log]
        LOG -->|Alert: Possible compromise| ADMIN[Administrator Review]
    end

Normal DNS resolution connects to the real server - sinkholing returns a dead-end address for known bad domains

Threat Intelligence Feeds

A DNS sinkhole is only as good as its blocklist. The blocklist must be comprehensive enough to catch real threats, updated frequently enough to include new malicious domains, and curated carefully enough to avoid blocking legitimate sites.

Several free threat intelligence feeds provide domain blocklists suitable for DNS sinkholing. The most commonly used include abuse.ch URLhaus (malware distribution URLs), PhishTank (confirmed phishing domains), Malware Domain List (domains hosting malware), and various community-maintained lists aggregated by tools like Pi-hole and pfBlockerNG.

Commercial feeds from providers like Proofpoint, DomainTools, and Cisco Talos offer broader coverage and faster updates. For home use, the free feeds provide solid coverage. The key is using multiple lists - no single feed catches everything, but combining several creates a much more complete picture.

Most sinkhole implementations update their blocklists automatically on a schedule (daily or more frequently). This is important because the threat landscape changes constantly. A domain that is safe today might host malware tomorrow, and a malicious domain might be taken down and reassigned to a legitimate owner.

Implementation Options

Three main approaches exist for implementing DNS sinkholing on a home or small business network.

Pi-hole is the most popular consumer option. It runs on a Raspberry Pi or any Linux system, acts as your network's DNS resolver, and checks every query against its blocklists. It has a web dashboard showing query statistics, top blocked domains, and per-client activity. Setup takes about fifteen minutes.

Response Policy Zones (RPZ) on BIND or Unbound give you DNS sinkholing on a standard DNS server. RPZ is an IETF standard that lets you override DNS responses for specific domains. This is more flexible than Pi-hole but requires more DNS knowledge to configure. It is common in enterprise environments.

pfBlockerNG on pfSense combines DNS sinkholing with IP-based blocking. It handles both domain-based blocking (like Pi-hole) and blocking traffic to/from entire IP ranges associated with malicious activity. If you already run pfSense, pfBlockerNG eliminates the need for a separate Pi-hole device.

What Sinkholing Blocks

DNS sinkholing is effective against several categories of threats.

Malware command-and-control (C2). When malware infects a device, it typically needs to contact a command server to receive instructions and exfiltrate data. Most malware uses domain names for C2 communication. If those domains are on the blocklist, the infected device cannot reach its controller, limiting the damage.

Phishing domains. Links in phishing emails point to domains designed to impersonate legitimate sites. If the phishing domain is on a blocklist (which depends on the domain being reported and the feed being updated), the DNS query returns a dead end and the user never sees the fake login page.

Ad tracking and telemetry. While not strictly a security threat, blocking advertising trackers and telemetry domains reduces the data your devices leak about your browsing habits. This is Pi-hole's most popular use case - network-wide ad blocking.

Known malware distribution sites. Domains that host malware downloads, exploit kits, or drive-by download infrastructure are blocked before your browser ever connects.

What Sinkholing Does Not Block

DNS sinkholing has clear limitations that matter for security planning.

Direct IP connections. If malware is programmed to connect to an IP address instead of a domain name, DNS is never involved. The sinkhole never sees the query because there is no query. Some sophisticated malware avoids DNS entirely for this reason.

DNS over HTTPS (DoH) and DNS over TLS (DoT) bypass. If a device uses its own encrypted DNS resolver instead of your network's resolver, your sinkhole is bypassed completely. Modern browsers (Firefox, Chrome) support DoH and some enable it by default. Devices like Chromecast and Amazon Echo use hardcoded DNS servers. Blocking outbound DNS (port 53) and DoT (port 853) to any destination except your sinkhole helps, but blocking DoH (port 443) is impractical since it shares a port with all HTTPS traffic.

Newly registered domains. There is always a gap between when a malicious domain is registered and when it appears on blocklists. Threat actors exploit this by using fresh domains that no feed has flagged yet.

Legitimate domains hosting malicious content. If an attacker hosts malware on a compromised legitimate website or uses a cloud service (AWS S3, Google Drive) for C2, the domain is legitimate and will not appear on blocklists.

graph TD
    subgraph "Blocked by DNS Sinkhole"
        B1[Malware C2 via Domain Name]
        B2[Known Phishing Domains]
        B3[Ad/Tracking Domains]
        B4[Malware Download Sites]
    end
    subgraph "NOT Blocked by DNS Sinkhole"
        N1[Direct IP Connections - No DNS]
        N2[DoH/DoT Bypass]
        N3[Newly Registered Domains]
        N4[Malware on Legitimate Domains]
        N5[IP-only C2 Communication]
    end
    subgraph "Defense"
        SINK[DNS Sinkhole] --> B1
        SINK --> B2
        SINK --> B3
        SINK --> B4
        FW[Firewall Rules] --> N1
        FW --> N5
        DNS_POLICY[DNS Policy - Block External DNS] --> N2
        IDS[IDS/IPS] --> N3
        IDS --> N4
    end

DNS sinkholing covers domain-based threats - other defense layers handle the gaps

Enterprise vs Home Deployment

The core mechanism is the same at any scale, but implementation details differ.

Enterprise deployments typically use RPZ on dedicated DNS infrastructure, integrate with commercial threat intelligence feeds that cost thousands per year, and enforce DNS policies that prevent devices from using external resolvers. They also correlate sinkhole hits with other security data (SIEM integration) and investigate every blocked C2 domain as a potential compromise indicator.

Home deployments use Pi-hole or pfBlockerNG, rely on free community feeds, and rarely have the enforcement to prevent DoH bypass on every device. The blocked query log serves double duty as both security monitoring and ad-blocking verification.

The security value at home is still significant. Blocking known malicious domains catches a meaningful percentage of commodity malware, phishing, and tracking. The effort required is minimal - Pi-hole installs in minutes and largely maintains itself.

Detecting Bypass Attempts

Sophisticated malware and privacy-focused applications both attempt to bypass local DNS. Detecting these attempts adds another layer of visibility.

Monitor outbound DNS traffic (UDP/TCP port 53) to destinations other than your sinkhole resolver. Any device making DNS queries to 8.8.8.8, 1.1.1.1, or any other external resolver is bypassing your sinkhole. On pfSense, a firewall rule can block this traffic and redirect it to your local resolver.

DoT on port 853 can also be blocked at the firewall since that port has no other common use. DoH on port 443 is harder - you would need to block access to known DoH resolver IPs (Cloudflare, Google, Quad9), which is a game of whack-a-mole but better than nothing.

Combining DNS Defense With Network Monitoring

DNS sinkholing is most powerful as part of a layered defense. The sinkhole blocks known bad domains. A firewall blocks direct IP connections to known malicious addresses. An IDS (like Suricata) catches attack patterns that bypass both DNS and IP blocklists. And wireless monitoring with the BLEShark Nano catches threats that operate at the WiFi/BLE layer, entirely below the network stack where DNS operates.

When a sinkhole blocks a C2 domain query from a specific device, that is a strong indicator of compromise. The device that made the query needs investigation. The Nano can help identify the physical device (by MAC address in the WiFi scan) while your firewall logs show what other connections that device has made. This kind of multi-tool correlation turns an individual alert into actionable intelligence.