What's new

Any reason to use DNSSEC with Quad9?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

drinkingbird

Part of the Furniture
Quad9 claims to do DNSSEC with remote hosts, and even validate the response (seemingly the same as enabling DNSSEC in Merlin and selecting "validate unsigned responses"). I've noticed having these enabled does cause a bit of performance hit to lookups, wondering if there is any reason to enable them, I trust Quad9 at least to the extent that I need to, so not sure I need to re-validate every response they send me? Especially since someone malicious that gets into their infra could just sign the response as valid.
 
Last edited:
Also, something @RMerlin might want to update - the Quad9 servers that are labeled as "Privacy Respecting", that isn't really accurate. Both of their preconfigured servers respect privacy the same way, the difference is the second set (.11) allows geolocation without exposing too much of your IP.

The first set is "Secured" and the second set is "Secured w/ECS". Not sure if that is coming from the Asus code or not (probably). A bit confusing why they put it that way.
 
Quad9 claims to do DNSSEC with remote hosts, and even validate the response (seemingly the same as enabling DNSSEC in Merlin and selecting "validate unsigned responses"). I've noticed having these enabled does cause a bit of performance hit to lookups, wondering if there is any reason to enable them, I trust Quad9 at least to the extent that I need to, so not sure I need to re-validate every response they send me? Especially since someone malicious that gets into their infra could just sign the response as valid.

Eh I found that enabling DOT or DNSSEC both caused pretty significant delays and even timeouts with DNS lookups. Maybe my old router isn't up to it. Honestly I'm not all that concerned with my ISP collecting data on the sites I'm visiting (who isn't doing that these days), more just wanted to implement some malicious site blocking. Quad9 for whatever reason I'm getting routed to Virginia instead of Boston, cleanbrowsing is keeping me much closer. Will try that one for a while. If they're doing DNSSEC for me, I'm fine with that.
 
That database is on Asus' servers.

Do you know if your (or Asus's - not sure if it is in stock firmware or not) DNSSEC implementation is sending the CD flag to the recursive DNS server telling it to forward all the DNSSEC records to the router for validation? I'm just trying to figure out what the purpose of DNSSEC between the router and a recursive resolver is.

Thanks
 
I believe Quad9’s DNSSEC verifies responses from the authoritive servers to them.
Enabling DNSSEC on router verifies from them (Quad9) to the router. The ‘last mile’ if you like.
 
I have experienced "delays" with Quad9 with or without DoT/DNSSEC. Seems to be an Anycast issue and not with Quad9. My ISP seems to play with the routing of Anycast address routing. Sometimes the Quad9 requests go to Miami and next to New York. Neither of which is the closest data center to me.
I believe Asus does have the Quad9 listing correct.
 
Last edited:
I have experienced "delays" with Quad9 with or without DoT/DNSSEC. Seems to be an Anycast issue and not with Quad9. My ISP seems to play with the routing of Anycast address routing. Sometimes the Quad9 requests go to Miami and next to New York. Neither of which is the closest data center to me.
I believe Asus does have the Quad9 listing correct.
I played with the DoT/DNSSEC settings for a while and things seemed to work fine. Decided I wanted ad blocking too, and didn't want to further burden my RT-AX86U by installing a solution with AMTM. Had an old RPi3b lying around, flashed it with DietPi, installed PiHole with Unbound, and changed the router's DNS settings to point to the Pi. Runs like a champ (translation - my wife hasn't complained about "the wifi not working") and haven't looked back! Now if only pixelserv-tls played nice with PiHole/Unbound, I could finally eliminate those pesky https ads...
 
Quad9 for whatever reason I'm getting routed to Virginia instead of Boston, cleanbrowsing is keeping me much closer. Will try that one for a while. If they're doing DNSSEC for me, I'm fine with that.
Report it to quad9 about you being routed to Virginia instead of Boston. There was a time NYC quad servers were being routed to Miami since then after I let them know by sending traceroute and dig to their technical support they've corrected it.

 
I played with the DoT/DNSSEC settings for a while and things seemed to work fine. Decided I wanted ad blocking too, and didn't want to further burden my RT-AX86U by installing a solution with AMTM. Had an old RPi3b lying around, flashed it with DietPi, installed PiHole with Unbound, and changed the router's DNS settings to point to the Pi. Runs like a champ (translation - my wife hasn't complained about "the wifi not working") and haven't looked back! Now if only pixelserv-tls played nice with PiHole/Unbound, I could finally eliminate those pesky https ads...
Diversion on an AX86U with Merlin firmware does not slow things down. And would provide a simpler and just as secure network as using a RPI and Pi-Hole.
 
I have experienced "delays" with Quad9 with or without DoT/DNSSEC. Seems to be an Anycast issue and not with Quad9. My ISP seems to play with the routing of Anycast address routing. Sometimes the Quad9 requests go to Miami and next to New York. Neither of which is the closest data center to me.
I believe Asus does have the Quad9 listing correct.
Pretty much any large DNS will be anycast (with the exception of ISPs since they can assign you local ones via DHCP). I tried both Quad9 and Cleanbrowsing and both are pretty fast without DNSSEC and DOT enabled and noticably slow with either or both enabled. My old router may just not be up to it.

The IPs in Asus are correct, the description is not, at least not on my model.
 
I believe Quad9’s DNSSEC verifies responses from the authoritive servers to them.
Enabling DNSSEC on router verifies from them (Quad9) to the router. The ‘last mile’ if you like.

As far as I can tell, enabling DNSSEC between you and a non authoritative DNS (last mile) just asks them to forward you the DNSSEC related records that they already validated. Anyone that can hack into their DNS to change something in their cache can just as easily remove or modify those records too. So if your DNS provider is already doing DNSSEC for you, it doesn't seem to gain anything by validating it again and does not protect you from a man in the middle attack.

If you want true DNSSEC end to end you need to set up your own recursive DNS server looking up to the roots directly.
 
Report it to quad9 about you being routed to Virginia instead of Boston. There was a time NYC quad servers were being routed to Miami since then after I let them know by sending traceroute and dig to their technical support they've corrected it.

Yeah I considered it then found cleanbrowsing is hitting a local server. They seem to go back and forth as to who is better at blocking malicious stuff so close enough.
 
“Trust, but verify.”
Unfortunately I think people are not realizing that DNSSEC to a non-auth DNS is not really providing that much extra verification (if any). I could be misunderstanding but the very thing you're trying to prevent with DNSSEC (spoofed response) is not prevented in that setup.
 
Unfortunately I think people are not realizing that DNSSEC to a non-auth DNS is not really providing that much extra verification (if any). I could be misunderstanding but the very thing you're trying to prevent with DNSSEC (spoofed response) is not prevented in that setup.
I feel that statement is not correct. DNSSEC provides validation that the connection is secure. And that is a big improvement over conventional DNS communication.

See: https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-05-en
 
I feel that statement is not correct. DNSSEC provides validation that the connection is secure. And that is a big improvement over conventional DNS communication.

See: https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-05-en
I don't see any reference to secure connection, only that the data returned is validated (yes using cryptography to ensure the validation is reliable). A secure connection requires DOT or DOH, which is why DNSSEC alone does not prevent your ISP or anyone else from snooping your DNS lookups. That article also only references traffic between the recursive DNS and the authoritative DNS, not the last mile to the user.

I haven't been able to find any good info on what exactly enabling DNSSEC between the client and recursive DNS does. It appears it just forwards you the information necessary to re-validate the record a second time. But if that DNS is hacked (or a rogue anycast IP pops up) the hacker could just return the standard response without any security info as though the domain does not support DNSSEC, and you will just use whatever it sends you without any validation.
 
Probably related or un-related but I noticed this _dns.resolver.arpa behaviour from iOS devices logged in uiDivstats. Out of curiosity I installed Adguard on iOS and enabled DNS protection. Trying out a few public and private DNS, the SVCB answers varies.

Router setting : 9.9.9.9 (and the secondary dns)
Forward local domain queries to upstream DNS : No
Everything else Yes including Prevent client Auto DoH
DoT Profile 9.9.9.9 Strict.

These are the various answer I get.



E9700E66-9763-4E9B-8C15-E7F3810D8A49.png
System resolver

675FA5D9-3231-4CBC-8FFE-07AD5BAF12D4.jpeg
Adguard private dns

E4D518BC-B073-4C2B-AD5B-D973DBA4B0FF.jpeg
NextDns private dns

9BD1A524-877F-4F76-9EDB-279265214261.png
Quad9 9.9.9.11 DoT

43808B7C-A384-4D5B-A093-AA52EA2612EA.png


Quad9 9.9.9.9 DoT

And expected answer from Google DoT
Code:
SVCB, 1 dns.google. alpn=dot
SVCB, 2 dns.google. alpn=h2,h3 key7=/dns-
query{?dns}
and Cloudflare DoT
Code:
SVCB, 1 one.one.one.one.
alpn=h2 port=443
ipv4hint=1.1.1.1,1.0.0.1
ipv6hint=2606:4700:4700:11
11,2606:4700:4700:1001
key7=/dns-query{?dns}
SVCB, 2 one.one.one.one.
alpn=dot port=853
ipv4hint=1.1.1.1,1.0.0.1
ipv6hint=2606:4700:4700:11
11,2606:4700:4700:1001

AdGuard’s public dns
Code:
SVCB, 1 dns.adguard-dns.com. alpn=h3,h2,http/1.1
port=443
ipv4hint=94.140.14.14,94.140.
15.15
ipv6hint=2a10:50c0::ad1:ff,2a
10:50c0::ad2:ff key7=/dns-
query{?dns}
SVCB, 2 dns.adguard-dns.com. alpn=dot port=853 ipv4hint=94.140.14.14,94.140.
15.15
ipv6hint=2a10:50c0:ad1:ff,2a
10:50c0::ad2:ff
SVCB, 3 dns.adguard-dns.com. alpn=doq port=853 ipv4hint=94.140.14.14,94.140.
15.15
ipv6hint=2a10:50c0..ad1:ff,2a
10:50c0:.ad2:ff

The closes reading I can find is this

TL;DR : Why some return with SVCB answer with IPV4 and IPV6 hint while upstream router’s 192.168.50.1 snd others have NXDOMAIN answers. Should I assign hostnames to clients that doesnt have one via manual DHCP assignment?
 
TL;DR : Why some return with SVCB answer with IPV4 and IPV6 hint while upstream router’s 192.168.50.1 snd others have NXDOMAIN answers. Should I assign hostnames to clients that doesnt have one via manual DHCP assignment?

For local devices, you need a manual DHCP assignment or a script to assign hostnames. Otherwise they'll resolve to whatever hostname is shown on the DHCP leases table (if * is shown, they won't resolve). Setting a name on the client list does not create DNS records. Nothing to do with DNSSEC or DOT, there is no encryption or security between your client and the router.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top