DNS sinkhole: what it is, how it works and when to use one

What a DNS sinkhole is

When a device looks up a domain, the DNS resolver normally returns the domain's real IP address. A DNS sinkhole changes that answer for domains on a deny list. Instead of the real address, the resolver returns an address you control, so any connection the device then makes lands on a harmless server rather than on the attacker's infrastructure.

The NCSC describes the sinkhole in its guidance on protective DNS as one of the ways a protective resolver can respond to a blocked domain: the traffic is sent to a specific server to which it is redirected, and a custom response is provided there. Response Policy Zones (RPZ), the DNS firewall method the NCSC's own PDNS uses, describe the same idea as redirecting clients to a "walled garden".

You may also see the word used for a related practice: security researchers and law enforcement taking control of a malicious domain itself and pointing it at their own servers, so infected machines around the world report there instead of to the criminals. That is done at the domain level by whoever controls the domain. This page is about the version you can run for your own organisation, at your resolver.

How a DNS sinkhole works, step by step

1. A device, or malware on it, asks your resolver for the address of a domain, for example a known command-and-control server.
2. The resolver checks the name against its policy: a deny list built from threat intelligence, your own block list, or both. The NCSC notes that protective DNS services typically check the IP address the answer would point to as well.
3. The domain matches, so instead of the real address the resolver returns the sinkhole address.
4. The device connects to the sinkhole server instead. Nothing reaches the attacker.
5. The sinkhole records the attempt and, depending on its purpose, shows a page explaining the block or simply drops the connection.
6. Your team reviews the records, spots devices that keep trying to reach malicious domains, and investigates them.

The final step is what makes a sinkhole more than a block. Malware that is already running on a machine typically keeps trying to reach its command-and-control domain, so it keeps appearing in the sinkhole's records. Those repeated hits are a strong sign of an infection.

Sinkhole vs NXDOMAIN vs block page

A protective resolver has three main ways to answer a lookup it has decided to block. The NCSC's private-sector guidance describes all three; the right choice depends on whether you care most about the user's experience or about investigation.

Why the certificate error? Almost every site now uses HTTPS. When a browser is sent to a block page for a domain it expected to be secure, the server answering cannot present a valid certificate for that domain, so the browser warns the user unless the device has been set up to trust a certificate issued by the filtering service. A block page is still the clearest experience; it just needs that set-up on managed devices.

In practice, a block page is itself a form of sinkholing: the blocked traffic is sent to a server the provider controls, which shows a page and records the attempt. The NCSC notes that more complex networks may want different responses for different networks, such as silently blocking with NXDOMAIN in one place and redirecting to a sinkhole in another, so check that any service you choose lets you set this per network.

Using sinkhole hits to find infected devices

A sinkhole is only useful for investigation if you can tell which device made the request. This is where many set-ups fall short.

• Internal DNS hides the device. If laptops ask an internal DNS server, which then forwards to a cloud resolver, the cloud service may only see the forwarding server or your office's public IP address. You need either your internal DNS logs, a component that passes the internal address on (Cisco Umbrella's virtual appliances do this, for example), or a client on the device.
• Roaming clients identify the device. A DNS client installed on a laptop tags lookups with that device or user, so a hit points straight to the machine. See DNS roaming clients.
• The sinkhole server can log the connection. If the sinkhole sits inside your network, it sees the internal address of each device that connects to it.
• Repetition matters more than one hit. A single block may be a user clicking a phishing link. Repeated attempts to the same command-and-control domain, sometimes at regular intervals, point to malware on the machine.

The NCSC recommends bringing blocked DNS requests into a security information and event management (SIEM) model so they can be investigated alongside other logs, and points smaller organisations to its open-source Logging Made Easy project for basic security logging. When a device turns up, isolate it, run a full scan with your endpoint protection, check how it was infected and look for the same domain in other devices' records. Our guide to DNS attacks explains the command-and-control and data theft techniques that sinkhole hits often reveal, including DNS exfiltration.

How to set up a DNS sinkhole

There are three realistic routes. Searches for "DNS sinkhole setup" often lead to home-lab projects that build ad-blocking sinkholes on a small computer, which are fine for a home network but are not a managed, supported control for an organisation.

A managed service is usually the quickest win: you point your networks and devices at it, and the provider maintains the deny lists, which the NCSC says should be regularly updated from threat intelligence feeds. Cisco Umbrella's security categories, for example, come from Cisco Talos threat intelligence; see Cisco DNS-layer security. Some firewalls do the same job at the gateway: WatchGuard DNSWatch, for example, blocks malicious DNS requests and redirects users to an informative page; see our WatchGuard DNSWatch guide.

Building your own with RPZ gives you full control, but the NCSC's checklist still applies: you would need to provide the threat intelligence, logging, allow-list process, resilience and protection against bypass yourself.

Limits of a DNS sinkhole

A sinkhole is a strong first layer, not a complete defence. Its blind spots are the same as those of any DNS-layer control:

• Unknown domains get through. A sinkhole only catches domains on its lists. Newly registered domains and those created by domain generation algorithms may not be listed yet, although some providers try to block programmatically generated names.
• Direct-to-IP connections skip DNS. Malware that connects straight to an IP address does not make a lookup.
• Other resolvers bypass it. Devices or browsers using their own DNS, including DNS over HTTPS, do not ask your resolver. See should you block DNS over HTTPS?
• It sees domains, not pages or files. A sinkhole cannot block one page on a legitimate site or scan a download. See DNS filtering vs URL filtering.
• False positives happen. You need a quick way to allow a wrongly blocked domain, which the NCSC says administrators should be able to do through a user interface.

How we can help

We can help you choose and deploy managed protective DNS with sinkhole or block-page responses, connect DNS logs to their SIEM, set up the firewall and device policies that stop DNS being bypassed, and work out what repeated blocks are telling them. Contact us to talk about your network; pricing is confirmed at quote.