Any reason to use DNSSEC with Quad9?

[drinkingbird]

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.

 

[drinkingbird]

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.

 

[RMerlin]

Also, something @RMerlin might want to update

That database is on Asus' servers.

 

[drinkingbird]

That database is on Asus' servers.

Ah, maybe someday they'll realize it. No biggie.

 

[drinkingbird]

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.

 

[drinkingbird]

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

 

[Treadler]

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.

 

[bbunge]

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.

 

[dave14305]

“Trust, but verify.”

 

[Cap10Canuck]

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...

 

[bluepoint]

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.

 

[bbunge]

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.

 

[drinkingbird]

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.

 

[drinkingbird]

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.

 

[drinkingbird]

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.

 

[drinkingbird]

“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.

 

[bbunge]

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

 

[drinkingbird]

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.

 

[Mogsy]

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.

System resolver

Adguard private dns

NextDns private dns

Quad9 9.9.9.11 DoT

Quad9 9.9.9.9 DoT

And expected answer from Google DoT

SVCB, 1 dns.google. alpn=dot
SVCB, 2 dns.google. alpn=h2,h3 key7=/dns-
query{?dns}

and Cloudflare DoT

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

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

Discovery of Designated Resolvers

This document defines Discovery of Designated Resolvers (DDR), a mechanism for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration. This mechanism can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a resolver is known. This...

www.ietf.org

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?

 

[drinkingbird]

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.