Comparing DNS blocking methods
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 and quad9, 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
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:
And then I get this block page:
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 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:
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 |
| 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:
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.