What Are The Benefits Of Using pfSense DNS Resolver/Forwarder Services?

tictag

TL;DR What are the benefits of using pfSense for DNS resolution, when compared to, for example, configuring the network to use Google's public DNS servers?

I am trying to understand what the benefits are to using pfSense for DNS resolution, either using the DNS Resolver, the DNS Resolver in Forwarding Mode or the DNS Forwarder services when compared to say, using Google or Cloudflare’s public DNS recursive resolvers.

You could say: it’s most local so fastest to resolve if the DNS resolution in within cache. Yes, that is true, but most OS’s keep their own DNS cache in memory, which would be faster than querying a local network service.

You could say: it provides its own recursive DNS resolution, so you’re not having the extra hop to an external recursive server. Yes, that is true, but the fastest DNS servers will be those authoritative for the top-level domains, and these will be cached soon enough anyway, those nearing the end of the DNS chain will be the slowest, and, therefore, both local recursive resolution and forwarding to an external recursive server, even with the extra hop, I can’t imagine there being that much difference timewise.

You could say: it is easy to setup pfSense as a recursive DNS resolver, the service is on by default and its IP is easily distributed using default DHCP settings. Yes, that’s true but it’s just as easy pass Google’s or Cloudflare’s public DNS servers through via DHCP.

You could say: pfSense is more secure because it supports DNS over TLS and, I presume, DNS over HTTPS (DoT/DoH) on the local network. Yes, that is true, but why bother? The local network is secured against interlopers via other means e.g. wired infrastructure, wireless WPA, MAC ACLs, 802.1Q, 802.1X etc.

You could say: pfSense is more secure because it supports DoT and DoH for upstream servers too. Yes, that is true, but this is only supported when DNS Resolver is in Forwarding Mode and if I’m just forwarding DNS queries, I could just as easily configure DHCP with a forwarding DNS server e.g. Google/Cloudflare. And most browsers these days have built in secure DNS (e.g. Chromium-based).

You could say: pfSense DNS resolution is further secured with DNSSEC support. Yes, but not in DNS Resolver Forwarding Mode, according to the manual.

So considering that my pfSense application is running on a cheap NUC in my bedroom over an shitty ADSL connection, compared to Google/Cloudflare DNS servers running in load-balanced clusters in geographically distributed data centres with resilient and super-fast Internet links … why would I use pfSense for any kind of DNS resolution? In other words, what are the benefits of using pfSense DNS Resolver / Forwarder?

Edit: changed some text formatting.

nimrod

You named all reasons why it should be used, however you made a firm decision not to use it. So yeah. You dont have to use it if you dont want to. Your network, your rules. Simple.

tictag

@nimrod Whilst it might not appear so, I am genuinely trying to make a case for using it, in fact, I am currently using it!, I'm just really struggling and thinking to myself, I must be missing something obvious here ...

I appreciate the response, thank you.

nimrod

Adblocking.

SteveITS

@tictag
host override
domain override
pfBlocker DNSBL lists

johnpoz

@tictag Lets forget about forwarding or resolving..

You mention most all OSes have their own local cache, which is true. Browsers do as well. But your forgetting that if you have multiple devices on your network.. Device A looks up www.something.tld, the Device B doesn't have to go out to the internet to look that up, it gets from the local dns cache.

Most iot devices do not have local caches - and some of them can be very dns noisy.. Here is just my thermostat and my AV recv

Something like unbound, can be set to prefetch - so that when ttl is close to being expired it can go and look that up again after a client asks so your cache and ttl are refreshed so you never have a situation where your local clients are not pulling from local cached. Unless it hasn't been looked up again.

Unbound can also be set to serve 0, so even if the ttl of that cached item has expired, it will serve up the last entry it had for that and then refresh it in the background..

And my unbound has only been up for 11 hours, I made some changes to it and it restarted and flushed its cache. Notice the cache hits as well in the above.

If you point your clients to some external dns like google or quad9, how exactly are you going to resolve any local resources?

To forwarding vs resolving - I would never go back to forwarding.. I could care less if all of google dns goes down.. The roots are not going down. If dns for a specific domain go down.. Only that domain is not going to resolve.. That would be the same if forwarding as well. I don't have to hand over on a silver platter every single thing I am looking up to some outside company..

As to you mentioning of dnssec and forwarding - if you forward, where you forward already does dnssec or it doesn't.. All the major players do dnssec already unless you use some special IP of theirs that doesn't do it.

The only time you should really consider forwarding is when your isp connection is just shitty and high latency. If your on some sat connection yeah your prob best to forwarding. Or you want to use dot.. Which in its current state does really nothing in hiding where your going from your isp. Since they for sure going to know what IP your going to for some website. And while that might be hiding in a sea of IPs since the site is hosted off a CDN.. The sni you send when you make the connection is in the clear - that your isp can easy just view.. Even though your actual traffic is encrypted in your https connection to some site, the actual fqdn of where your going is in the clear in the sni of the https handsake. Until such time ech (esni is dead) takes off and is deployed across all of the enternet. Maybe you have some other reason for using dot or doh.. But they sure are not hiding where your going from your isp if you isp wants to know - that is for sure.

Be it you forward or resolve - if you have a shitty isp connection its going be better to run a local dns for just caching..

Also as already mentioned. Running your own local dns allows for easy filtering of stuff you just don't want clients to go to, and those queries never go to the internet in the first place.

edit: also want to point out I run a pihole that most all of my devices point to first, before unbound even gets asked. The cache hit numbers are going to be a bit skewed because pihole is also caching, total queries to unbound also skewed because of that, etc.

Don't get me wrong, I am a fan of pfblocker and do run it for aliases and geoip aliases.. I also run pihole because I like it eye candy better.

You do you for sure - but I would never not run a local dns. And I would never forward - resolving is the way to go hands down..

tictag

@johnpoz
You mention that when multiple devices, especially IoT devices, share the same DNS Resolver, they all benefit from that central cache. A very valid point which would undoubtedly speed up DNS resolution across the network as a whole.

You mention that expired cache can be served (then refreshed in the background). A valid point, this would provide speedier resolution to the application, though this might cause problems if the cached entry is particularly old?

You mention resolving local resources without a local DNS Resolver. A partially valid point, local resources can be resolved using a local hosts file, though, as I am already using Ad Guard Home, which has its own DNS Rewrites feature, I would most likely use this.

You mention DNSSEC. A potentially valid point assuming that pfSense cached the resulting ‘secure resolution’ (i.e. to avoid the multiple to’ing and fro’ing of key checks, multiple times per resolution request) but as it is only supported in Forwarding Mode, I doubt this actually happens.

You mention DoT. Whilst your commentary is acknowledged, pfSense only supports this in Forwarding Mode, so is not a supporting argument for using pfSense as a local DNS Resolver.

You mention DNS filtering. A partially valid point if the assumption is that no other filtering is available, I personally use Ad Guard Home, which, imho, is a significantly better solution than filtering via the DNS Resolver. Btw, I did try PiHole but Ad Guard just had a richer feature set in my option.

Thank you for your comprehensive contribution to this debate, your points are clearly made, substantiated and most definitely food for thought.

@nimrod
You mention AdBlocking, a partially valid point if the assumption is that no other filtering solution is available e.g. Ad Guard, PiHole etc.

@SteveITS
You mention host and domain overrides, a valid, if somewhat niche, point principally benefitting corporate networks. For the home-gamer could be implemented in other solutions, like Ad Guard Rewrites.

You mention pfBlocker and DNSB lists, a partially valid point if the assumption is that no other filtering solution is available e.g. Ad Guard, PiHole etc.

Thank you all so much for contributing to this debate, I have a lot to think about!

johnpoz

@tictag said in What Are The Benefits Of Using pfSense DNS Resolver/Forwarder Services?:

cause problems if the cached entry is particularly old?

Possible - but it is served to the client with a ttl of 0, so even if that was no longer vaild. Next time the client wanted to go there it would get current value because unbound had updated its record after it served it to the client.

A potentially valid point assuming that pfSense cached the resulting ‘secure resolution’

Huh? it does cache the resolution. Do you think only forwarding mode caches results?

If you are running adguard home, you are already running a local dns.. Be it you also run it on pfsense and have adguard forward to it, like I do for my pihole.. That would be your choice.

I think your starting to get into a apples/oranges discussion.. pfsense out of the box provides for local dns, with ability to filter either by creating your own filtering actually directly in unbound, say with redirects, etc. or host overrides - or with the added ability of pfblocker that uses unbound.

I let pfsense handle my dhcp, which then handles all my local resolution. If you forward from your other local dns, be that adguard or pihole or just some other local dns your running would be up to you. Then your local resolution would be fine, and you wouldn't need to handle putting records directly into your other dns.

Since your already running a local dns, not sure exactly what your asking - are you really asking if unbound with pfblocker is better than adguard or pihole? All of them are local dns solutions with filtering. You could run just 1 of them, or you run them together, etc.

RobbieTT

For me it is for the balance of security and performance. I use the resolver with forwarding to quad9, DoT, filtered with server hosted in a privacy-minded & 'difficult' country.

None of the above in itself makes it 'secure' but it does make it very hard to get a complete picture of activity on IPv6 (or 4). Queries are scattered across 4 servers, are not retained by Quad9, privacy addresses are in use, pre-fetch confusing matters, pfBlocker, additional crypto layer and, of course, 90% or so of queries answered internally.

My resolver has also just been reset following patches and an update but the cache is warming up and doing its job for all devices:

[23.05.1-RELEASE][admin@Router-8.redacted.me]/root: unbound-control -c /var/unbound/unbound.conf stats_noreset | grep total
total.num.queries=119450
total.num.queries_ip_ratelimited=0
total.num.cachehits=108299
total.num.cachemiss=11151
total.num.prefetch=18603
total.num.expired=16113
total.num.recursivereplies=11151
total.num.dnscrypt.crypted=0
total.num.dnscrypt.cert=0
total.num.dnscrypt.cleartext=0
total.num.dnscrypt.malformed=0
total.requestlist.avg=0.538852
total.requestlist.max=13
total.requestlist.overwritten=0
total.requestlist.exceeded=0
total.requestlist.current.all=0
total.requestlist.current.user=0
total.recursion.time.avg=0.103761
total.recursion.time.median=0.0385256
total.tcpusage=0
[23.05.1-RELEASE][admin@Router-8.redacted.me]/root:

Like all security measure, the goal is to be more 'difficult' than those who just don't bother or think that this kind of stuff is all unimportant and will remain 'unimportant' forever.

️

johnpoz

@RobbieTT said in What Are The Benefits Of Using pfSense DNS Resolver/Forwarder Services?:

Queries are scattered across 4 servers, are not retained by Quad9, privacy addresses are in use

What do you mean scattered across 4 servers? quad9 would have access to all of your queries be it you ask only 1 of their servers or 4 different ones. And since they are anycast - just because you say use 4 different Ips for their servers - it quite likely is just going to whatever the closest "server(s)" to you.

privacy addresses? Not sure what you mean by that..

As to if they retain them or not, who knows for sure? Clearly they are getting some sort of data from the queries that are sent to them - what exactly they do with it, how they monetize it? But clearly all of these services that provide public dns services are getting something out of it. They are for sure not providing public dns to the planet out of the goodness of their hearts ;)

RobbieTT

@johnpoz

John, you have posted your antipathy to my reasoning a few times now, so I am aware of your thoughts and your chosen configuration.

️

tictag

@johnpoz said in What Are The Benefits Of Using pfSense DNS Resolver/Forwarder Services?:

Huh? it does cache the resolution. Do you think only forwarding mode caches results?

This comment related to DNSSEC DNS resolution, which, it is my understanding, on its first pass resolves the DNS query, then, on its second pass, confirms the PKI encrypted hash of the query back up the resolution tree to the root. Only once it has the query response together with an unbroken cryptographically secure resolution chain does it provide a 'secure resolution' back to the querying application. If pfSense did this, then cached the result so that the next query would be delivered from that cache instead of requiring the second pass, this would speed up DNS resolution overall. But I doubt this actually happens because it is only supported with Forwarding Mode active, which means that each query is forwarded, so each query will have to go through the first and second passes, as described.

I agree with all your other points. pfSense is currently providing my Firewall, DHCP, PPPoE gateway (yes, I know...) and will likely be providing 802.1Q and 802.1X services in the future (homelab), and probably more, I'm just not 100% sure, considering I also use Ad Guard, whether there are sufficient benefits to using it for DNS resolution. And, hence this post!

johnpoz

@tictag said in What Are The Benefits Of Using pfSense DNS Resolver/Forwarder Services?:

But I doubt this actually happens because it is only supported with Forwarding Mode active

Huh? Again if you forward - asking for any dnssec anything is pointless and only going to create more queries that do nothing.

If you forward, where you forward, there is always a resolver at the end of the chain. They are doing dnssec or they are not..

If I query something lets say www.domain.tld, and it passes the dnssec checking.. And 1.2.3.4 is given to the client.. If another client asks for www.domain.tld - no dnssec check is required.. 1.2.3.4 is just handed to the client asking..

tictag

@RobbieTT
I've heard some good things about Quad9, particularly their base in Switzerland, that has some of the world's most restrictive data privacy legislation - much more restrictive than the EU's GDPR. Of course, @johnpoz is right in that we can't possibly know what they do 'behind the scenes' but I'll put good money on the fact they'll want to comply with their own country's privacy legislation. It's an indicator of privacy, not an assurance.

For me this is more about functional performance, but with a healthy dollop of security and privacy. If I can get what I need by, for example, forcing all network devices to use Google's DNS servers (or Quad9's) and that works at least as well if not better than pfSense's DNS Resolver, then I'll force that out via DHCP - I certainly wouldn't want to match my pfSense DNS Resolver performance (running on a cheap NUC etc.) against Google's DNS infrastructure.

tictag

@johnpoz said in What Are The Benefits Of Using pfSense DNS Resolver/Forwarder Services?:

If I query something lets say www.domain.tld, and it passes the dnssec checking.. And 1.2.3.4 is given to the client.. If another client asks for www.domain.tld - no dnssec check is required.. 1.2.3.4 is just handed to the client asking..

I defer to your knowledge, my assumption was that if a DNSSEC query was requested (I technically do not know how this is done, some sort of flag?), each and every query would go through the same down'n'up process before the response was provided back to the application. I believe what you are saying is that, yes this does happen, but all resolvers, pfSense or otherwise, would then provide subsequent resolution from cache, within the original TTL. So pfSense would indeed provide resolution from cache, if it is able to, so Forwarding Mode is irrelevant.

bmeeks

@tictag said in What Are The Benefits Of Using pfSense DNS Resolver/Forwarder Services?:

I defer to your knowledge, my assumption was that if a DNSSEC query was requested (I technically do not know how this is done, some sort of flag?), each and every query would go through the same down'n'up process before the response was provided back to the application. I believe what you are saying is that, yes this does happen, but all resolvers, pfSense or otherwise, would then provide subsequent resolution from cache, within the original TTL. So pfSense would indeed provide resolution from cache, if it is able to, so Forwarding Mode is irrelevant.

Just to be sure you understand- DNSSEC is not about encrypting the DNS traffic at all. It is simply used to validate the endpoint DNS server is who he says he is. Here is the description straight from Google Cloud:

The Domain Name System Security Extensions (DNSSEC) is a feature of the Domain Name System (DNS) that authenticates responses to domain name lookups. It does not provide privacy protections for those lookups, but prevents attackers from manipulating or poisoning the responses to DNS requests.

DNSSEC really has nothing at all to do with privacy directly. It only is a way for validating a host is who it portrays itself to be.

DoT (DNS over TLS) is geared more towards privacy as it encrypts the actual DNS communications session between the two hosts.

johnpoz

@tictag said in What Are The Benefits Of Using pfSense DNS Resolver/Forwarder Services?:

so Forwarding Mode is irrelevant.

Correct does not matter if you forward or resolve - once something is cached, any other queries for that record would be served from cache for life of that ttl that is cached.

Which brings up a point, when you resolve you always get the full ttl of whatever you resolved.. When you forward, it will return what it has in its cache with the ttl of what is left on its cached

So lets say something had a ttl of 2 hours. While you will always get that 2 hour ttl if you asked authoritative NS for www.domain.tld, when you forward to say google or quad.. Maybe its ttl only had 30 seconds left? So you would only be able to cache that for 30 seconds until you had to query for it again. Now you might get something closer to the 2 hours next time, you might also get only 45 seconds because a different server answered with a different cache value

example..

$ dig @8.8.8.8 www.cnn.com                                               
                                                                         
; <<>> DiG 9.16.42 <<>> @8.8.8.8 www.cnn.com                             
; (1 server found)                                                       
;; global options: +cmd                                                  
;; Got answer:                                                           
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62151                
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1     
                                                                         
;; OPT PSEUDOSECTION:                                                    
; EDNS: version: 0, flags:; udp: 512                                     
;; QUESTION SECTION:                                                     
;www.cnn.com.                   IN      A                                
                                                                         
;; ANSWER SECTION:                                                       
www.cnn.com.            151     IN      CNAME   cnn-tls.map.fastly.net.  
cnn-tls.map.fastly.net. 25      IN      A       151.101.3.5              
cnn-tls.map.fastly.net. 25      IN      A       151.101.67.5             
cnn-tls.map.fastly.net. 25      IN      A       151.101.131.5            
cnn-tls.map.fastly.net. 25      IN      A       151.101.195.5            
                                                                         
;; Query time: 19 msec                                                   
;; SERVER: 8.8.8.8#53(8.8.8.8)                                           
;; WHEN: Sat Aug 19 11:11:19 Central Daylight Time 2023                  
;; MSG SIZE  rcvd: 140                                                   
                                                                         

$ dig @8.8.8.8 www.cnn.com

; <<>> DiG 9.16.42 <<>> @8.8.8.8 www.cnn.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16433
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.cnn.com.                   IN      A

;; ANSWER SECTION:
www.cnn.com.            82      IN      CNAME   cnn-tls.map.fastly.net.
cnn-tls.map.fastly.net. 6       IN      A       151.101.3.5
cnn-tls.map.fastly.net. 6       IN      A       151.101.67.5
cnn-tls.map.fastly.net. 6       IN      A       151.101.131.5
cnn-tls.map.fastly.net. 6       IN      A       151.101.195.5

;; Query time: 9 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Aug 19 11:11:21 Central Daylight Time 2023
;; MSG SIZE  rcvd: 140

Notice those queries to 8.8.8.8 are only 2 seconds apart.. But I got completely different ttls back.. That for sure are more than 2 seconds different in their length.

If I query the actual NS for that fqdn, I always get back the full TTL.

$ dig  cnn-tls.map.fastly.net @ns1.fastly.net                            
                                                                         
; <<>> DiG 9.16.42 <<>> cnn-tls.map.fastly.net @ns1.fastly.net           
;; global options: +cmd                                                  
;; Got answer:                                                           
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63836                
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1     
;; WARNING: recursion requested but not available                        
                                                                         
;; OPT PSEUDOSECTION:                                                    
; EDNS: version: 0, flags:; udp: 1232                                    
;; QUESTION SECTION:                                                     
;cnn-tls.map.fastly.net.                IN      A                        
                                                                         
;; ANSWER SECTION:                                                       
cnn-tls.map.fastly.net. 30      IN      A       146.75.79.5              
                                                                         
;; AUTHORITY SECTION:                                                    
fastly.net.             7200    IN      NS      ns1.fastly.net.          
fastly.net.             7200    IN      NS      ns2.fastly.net.          
fastly.net.             7200    IN      NS      ns3.fastly.net.          
fastly.net.             7200    IN      NS      ns4.fastly.net.          
                                                                         
;; Query time: 9 msec                                                    
;; SERVER: 23.235.32.32#53(23.235.32.32)                                 
;; WHEN: Sat Aug 19 11:15:42 Central Daylight Time 2023                  
;; MSG SIZE  rcvd: 139

Another possible advantage to resolving vs forwarding. Is you should always get back from the authoritative NS the best geographically IP for where your query came from. When you forward to some anycast NS.. While it should be the one closest to you, and then hand over the best IP, but maybe the one that answers not really all that close to you.. Maybe it has a different geographically based IP for different region. With the use of ECS via EDNS.. Its "possible" that where you forward has something cached for www.domain.tld that is not really the best IP for you to talk to from where your at.. Because the person that queried that before that it had to be resolved was not all that close to where your at.

I prefer to always ask the actual authoritative NS for what I am looking for.. From my actual source IP.

To running your own local dns that either resolves or forwards - also allows you to adjust for min ttl.. Not a fan of 30 second or 60 second ttls that many sites love to hand out for stuff. I have my local dns set to use a min of 3600 seconds (1 hour) I have never yet run into any issue in doing this.. For the years and years have been doing it. This can drastically reduce the amount of queries that have to go out my internet connection, because I cache stuff for min of 1 hour once I have looked it up.

It is normally not good practice to alter a ttl, but then again - its not efficient to set such low ttls on records, unless you were in the process of getting ready to change the IP that record is going to point too.. But more and more your seeing very low ttls, which I believe is a way to help track how long your on a site.. Because like every 30 seconds your on that site a new query would be done..

RobbieTT

@tictag said in What Are The Benefits Of Using pfSense DNS Resolver/Forwarder Services?:

@RobbieTT
...but I'll put good money on the fact they'll want to comply with their own country's privacy legislation. It's an indicator of privacy, not an assurance.

Yes, it has been thoroughly audited but it has also survived a court-ordered investigation that was based (incorrectly, as it turned out) on the idea that they (surely!) retained more than they claimed. That governments have come to expect that Quad9 is a bit of a dead-end for information has, no doubt, them fishing for data elsewhere but it adds an additional layer of reassurance to the end-users.

There are always skeptics who think Quad9 must be up to something nefarious, rather than operating 'out of the goodness of their hearts' as a non-profit. They are funded, of course, but by companies and by donations, including from those most technically able to test and audit their activities.

But, skeptics do their thing. Which is good for the rest of us.

️

JKnott

@tictag said in What Are The Benefits Of Using pfSense DNS Resolver/Forwarder Services?:

I am trying to understand what the benefits are to using pfSense for DNS resolution, either using the DNS Resolver, the DNS Resolver in Forwarding Mode or the DNS Forwarder services when compared to say, using Google or Cloudflare’s public DNS recursive resolvers.

One reason is for accessing my local devices that have private addresses, either RFC1918 on IPv4 or Unique Local on IPv6. No point on having those on a public DNS.

Another reason is to provide my own address for a certain service. For example, my notebook computer is configured to use pool.ntp.org and when I'm away from home, that's what it uses. However, when at home, I want to use my own NTP server, so I use my DNS to send NTP to my own server.

johnpoz

@RobbieTT said in What Are The Benefits Of Using pfSense DNS Resolver/Forwarder Services?:

skeptics who think Quad9 must be up to something nefarious

Even if they are the cleanest most moral dns provider on the planet - which they very may well be.. I still wouldn't forward.. There are too many advantages to doing my own resolving..

Other people might have other opinions - they are free to forward to whoever they want to forward.. There are plenty of providers to choose from that is for sure - I find it unlikely that they are all squeaky clean ;)

There can be advantages as well to forwarding, don't get me wrong - they can provide some safety in filtering - but they also could filter stuff that you don't want filtered, etc. They just recently blocked a site..

$ dig @9.9.9.9 canna-power.to                                           
                                                                        
; <<>> DiG 9.16.42 <<>> @9.9.9.9 canna-power.to                         
; (1 server found)                                                      
;; global options: +cmd                                                 
;; Got answer:                                                          
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37350              
;; 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:                                                    
;canna-power.to.                        IN      A                       
                                                                        
;; Query time: 12 msec                                                  
;; SERVER: 9.9.9.9#53(9.9.9.9)                                          
;; WHEN: Sat Aug 19 12:51:51 Central Daylight Time 2023                 
;; MSG SIZE  rcvd: 43

$ dig canna-power.to

; <<>> DiG 9.16.42 <<>> canna-power.to
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60008
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;canna-power.to.                        IN      A

;; ANSWER SECTION:
canna-power.to.         3600    IN      A       46.148.26.245

;; Query time: 88 msec
;; SERVER: 192.168.3.10#53(192.168.3.10)
;; WHEN: Sat Aug 19 12:52:00 Central Daylight Time 2023
;; MSG SIZE  rcvd: 59

As to them always sticking to their word - well clearly on their FAQ they state

No. Quad9 will not provide a censoring component and will limit its actions solely to the blocking of malicious domains around phishing, malware, and exploit kit domains.

Yet the above site is blocked by them due to a lawsuit by German arm of Sony Music. Maybe they should add to that faq, or if someone asks us too block something ;)

Now personally I have no use for that site - but if they are blocking that one, what other sites are they blocking? People all about privacy of their PI and and anonymity just hand over all their dns on a silver platter to a company that says - hey trust us, we are the good guys all the time.. Which they all say, so why should I trust any of them, when I can just do my own resolving thank you very much..