--- title: "Comparing DNS Blocking Methods: NXDOMAIN, 0.0.0.0 and More" description: "How protective DNS resolvers answer blocked queries with NXDOMAIN, 0.0.0.0, a block-page IP or the gateway, and how adam:ONE DNSharmony combines them." url: https://adamnet.works/blog/comparing-dns-blocking-methods/ index: https://adamnet.works/llms.txt --- [All Articles](https://adamnet.works/blog/articles.md) Articles · DNS · Protective DNS · DNSharmony # Comparing DNS Blocking Methods NXDOMAIN, 0.0.0.0, a dedicated block-page IP or the internal gateway: how protective DNS resolvers answer a blocked query, what each method means for users and SIEMs, and how adam:ONE DNSharmony combines them. David Redekop | ADAMnetworks • August 22, 2024 ![adam:ONE block page for a domain not on any allow list](https://adamnet.works/uploads/comparing-dns-blocking-methods-3.webp) In the world of protective DNS servers, a variety of blocking methods are used that have differing optimal use cases. adam:ONE® consolidates the answers and transposes its own method below, but it is sometimes helpful to understand the different methods in use by other protective resolvers. ## What is a DNS blocking method? For the simplicity of this blog, we will explore only IPv4 with examples, although the same concepts apply to IPv6. For starters, the most common purpose of DNS is to convert names (`www.google.com`) to one or more IP addresses (`216.239.38.120`). When a device wants to go to a place like `badactor.co`, we want it to blocked. This is where a blocking method needs to be decided. The question is, if the answer silent, is it a “no”? Is it something else? That’s what we’ll explore here. The DNS block goal is simple: don’t tell the device where `badactor.co` actually is. It can be answered with anything else but not the published `A` record. ## Method #1: Using NXDOMAIN In DNS parlance, the **NXDOMAIN** answer is like responding with a blank stare. To be clear, there’s a response, but it’s blank, so the endpoint knows the answer doesn’t exist. [CleanBrowsing](https://cleanbrowsing.org/) and [quad9](https://quad9.net/), for example, use this technique. In the case of quad9, a nuanced detail is added by changing Recursion Available (RA) flag to 0 which shows up in a dig query as **WARNING: recursion requested but not available**. This is helpful in a SIEM to differentiate between invalid domains vs ones that were intentionally blocked by a protective resolver such as QUAD9. ``` : dig @9.9.9.9 evri-uk-servei.help ; <<>> DiG 9.18.19 <<>> @9.9.9.9 evri-uk-servei.help ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 40107 ;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;evri-uk-servei.help. IN A ;; Query time: 9 msec ;; SERVER: 9.9.9.9#53(9.9.9.9) (UDP) ;; WHEN: Thu Aug 22 11:36:00 EDT 2024 ;; MSG SIZE rcvd: 48 ``` Compare that if we ask Google Public DNS which never blocks anything: ``` : dig @8.8.8.8 evri-uk-servei.help ; <<>> DiG 9.18.19 <<>> @8.8.8.8 evri-uk-servei.help ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62222 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;evri-uk-servei.help. IN A ;; ANSWER SECTION: evri-uk-servei.help. 3603 IN A 47.89.174.1 ;; Query time: 85 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP) ;; WHEN: Thu Aug 22 11:36:13 EDT 2024 ;; MSG SIZE rcvd: 64 ``` The advantages of using this method is primarily that it is super light-weight for the provider. Considering that quad9 is offering a free service as a non-profit, this makes sense. The disadvantage is that the end-user doesn’t have any idea what happened when something is blocked. --- ## Method #2: Using [`0.0.0.0`](https://en.wikipedia.org/wiki/0.0.0.0) Devices attempting to go to `0.0.0.0` won’t go anywhere. Cloudflare’s protective DNS server, for example, uses this method. For example: ``` : dig @1.1.1.3 ocs.ca +short 0.0.0.0 ``` Compared to Google DNS: ``` : dig @8.8.8.8 ocs.ca +short 23.227.38.65 ``` The advantages of using `0.0.0.0` are: - requires no resources on behalf of the protective resolver - endpoints are not waiting to re-try the DNS query, so the end-user experience is quick and efficient - your SIEM can easily identify what was purposefully blocked by looking for DNS answers of `0.0.0.0` The disadvantage of `0.0.0.0` is: - the end-user has no idea what happened or why Fun use:: try using `0.0.0.0` for YouTube and watch your kids play outside. --- ## Method #3: Using a dedicated public IP (or IP range) Using a purposefully-assigned IP address or block of public IPs for blocked answers enables a different kind of experience by the end user. Provided that the endpoints have installed the provider’s SSL Root certificate, the block page can now include feedback as to why it was blocked. Note that installing the root certificate is optional, but when opting out, it makes for an unwanted end-user experience. **Cisco Umbrella** and **DNSfilter** are two protective DNS servers that use this method. Here’s an example of what the Umbrella experience looks like when attempting to visit an adult content site: ``` : dig @208.67.222.123 pornhub.com +short 146.112.61.106 ``` The answer given by Umbrella above is an IP address owned by Cisco Umbrella. This is what the block page looks like. First, since I do not have the Cisco Umbrella root certificate, I have to get past this warning: ![Browser certificate warning shown when a blocked HTTPS site is redirected to a block-page IP](https://adamnet.works/uploads/comparing-dns-blocking-methods-1.webp) And then I get this block page: ![Cisco Umbrella block page for a site blocked by content filtering](https://adamnet.works/uploads/comparing-dns-blocking-methods-2.webp) --- ## Method #4: Using the internal gateway When a domain is queried that is to be blocked, the answer is always the gateway itself, e.g.: ``` : dig badactor.co +short 192.168.94.251 ``` This is the adam:ONE approach. We just wanted the best of all worlds. Here was our wish list: - Avoid sending signals to ISPs and cloud providers about blocked domains for privacy reasons - Avoid the security and privacy risk that comes with installing protective providers’ SSL root certificates - Offer endpoints the fastest response possible when a DNS block occurs - Offer devices feedback that is transparent and doesn’t break SSL The last wish list item came by way of a browser [extension](https://adamnet.io/extension) that detects the gateway’s response and then offers a simple redirect. Observed from a global perspective, this is how we achieve distributed sink-holing. None of this traffic, or even a signal of it leaves the local network. To use the `badactor.co` as an example again, the browser, in turn, recognizes it is blocked and redirects it like so: ![adam:ONE block page for a domain not on any allow list](https://adamnet.works/uploads/comparing-dns-blocking-methods-3.webp) Note that `mytools.management` is an ADAMnetworks-owned domain that always resolves locally to the adam:ONE service. It only resolves to its public IP when adam:ONE isn’t in the path. In summary, here are some well-known products/resolvers and their blocking methods of choice: | Protective DNS Resolver | Blocking Method | | - | - | | quad9 | NXDOMAIN | | CleanBrowsing | NXDOMAIN | | Cisco Umbrella | [IP range](https://support.opendns.com/hc/en-us/articles/227986927-What-are-the-Cisco-Umbrella-Block-Page-IP-Addresses) | | CloudFlare (No Malware) | 0.0.0.0 | | CloudFlare (No Malware or Adult Content) | 0.0.0.0 | | DNSfilter | IP `45.253.131.236` | | Webroot SecureDNS | IP `35.199.56.164` | --- ## How it all fits together with adam:ONE DNSharmony With our DNSharmony feature/plan, any number of protective resolvers can be used simultaneously. So what happens when the blocking methods differ? adam:ONE re-writes the answers to its own block page method so that the experience is consistent. In each of the examples above, the block pages look like this, no matter which DNS intelligence source offered the block: ![adam:ONE block page for adult content](https://adamnet.works/uploads/comparing-dns-blocking-methods-4.webp) ![adam:ONE block page for a site blocked by a DNSharmony schedule](https://adamnet.works/uploads/comparing-dns-blocking-methods-5.webp) ![adam:ONE block page for a phishing site](https://adamnet.works/uploads/comparing-dns-blocking-methods-6.webp) NOTE that if you are attempting to replicate these dig queries, your results may vary, especially if you are behind Zero Trust Connectivity that enforces local policy-based DNS answers. adam:ONE, for example, implements a default hijacking rule that will prevent any endpoint from reaching a public DNS server. --- Edit #1 ## Retro Method: using `127.0.0.1` (localhost) For years, there have been publicly maintained lists of a `hosts` file that replaces your \*nix `/etc/hosts` or Windows `c:\windows\system32\drivers\etc\hosts` file to blackhost third party ads/trackers. This might be an appropriate method for advanced users that don’t even want to register a DNS query as hosts file usage takes precedence over a DNS query. However, when using 127.0.0.1 it is important to test to make sure it offers a quick reset by the firewall. In other words, you want to experience an instantanous `Connection refused` when attempting to make an http or https connection: ``` % curl -v -k https://127.0.0.1 * Trying 127.0.0.1:443... * connect to 127.0.0.1 port 443 from 127.0.0.1 port 60658 failed: Connection refused * Failed to connect to 127.0.0.1 port 443 after 0 ms: Couldn't connect to server * Closing connection curl: (7) Failed to connect to 127.0.0.1 port 443 after 0 ms: Couldn't connect to server ``` The only reason why this method may be helpful is if there’s any kind of monitoring or counter happening for analytics or local collection purposes. In fact, this is a really bad idea for any environments that actually have http or https listeners on 127.0.0.1 as this blocking method will cause very poor performance and even unexpected browser behaviour as blocked content will attempt to serve up from the localhost web server. ## Related reading Articles ### [Mastering DNS Resilience: How to Assess and Ensure Network Survivability](https://adamnet.works/blog/dns-resilience-and-network-survivability.md) October 2, 2024 Articles ### [About Apple Private Relay](https://adamnet.works/blog/apple-private-relay.md) June 21, 2021 Podcast ### [Defending the DNS: How Quad9 Protects the Internet](https://adamnet.works/podcast/tdl-002-defending-the-dns-how-quad9-protects-the-internet.md) August 8, 2025 ## See it on your own network Zero Trust Connectivity reduces attack surface 7000:1 by denying egress by default. Talk to us about what that looks like in your environment. [Request a Demo](https://adamnet.works/contact.md) [How adam:ONE® Works](https://adamnet.works/how-it-works.md)