DNSSEC DNS on RT-AX86U Pro causing some websites not to load properly

[Intrepid]

I just completed my final tests with Quad9.
1. Just DNSSEC: Business.Comcast.com FAILS to load properly
2. Just DNSSEC with Validate unsigned DNSSEC replies: Business.Comcast.com FAILS to load properly
3. DNSSEC (with and without Validation) -and- DNS-over-TLS (DoT): Business.Comcast.com FAILS to load properly.
4. Just DNS-over-TLS (DoT): Business.Comcast.com Loads Properly.

As recommended by Quad9, I will not be using DNSSEC because it's unreliable. As mentioned by other users this is not just a Quad9 issue as Comcast fails with Cloudflare and DNSSEC as well. If Comcast fails there will be others. I think Quad9's implementation of DNSSEC along with DNS-over-TLS (DoT) encryption on the Asus router provides more than enough security as well as reliability.

 

[maxbraketorque]

...

DNSSEC is the best way to provide last mile security between your upstream resolvers and your network.

...

If the DNS provider does their own DNSSEC, what does DNSSEC at the router provide if the connection to the DNS provider is secure and cannot be spoofed? Not trying to argue. I just want to hear a sufficiently detailed explanation.

 

[RMerlin]

If the DNS provider does their own DNSSEC, what does DNSSEC at the router provide if the connection to the DNS provider is secure and cannot be spoofed? Not trying to argue. I just want to hear a sufficiently detailed explanation.

If you use DoH/DoT to connect to the resolver, then you don't really need to add your own DNSSEC validation if the resolver does it already. Doing local DNSSEC validation becomes more important if the remote resolver doesn't do it for you, or if you use plain UDP/TCP 53 connections to your resolver.

 

[bbunge]

If you use DoH/DoT to connect to the resolver, then you don't really need to add your own DNSSEC validation if the resolver does it already. Doing local DNSSEC validation becomes more important if the remote resolver doesn't do it for you, or if you use plain UDP/TCP 53 connections to your resolver.

Not true. DNSSEC validates the connection between the upstream resolver and the router in our case. DoT does not play in that at all other than to encrypt the connection. Yes, DoT also validates the TCP connection. Bur DNSSEC is not the same as DoT. While DNSSEC may be used between resolvers (servers) it is very important to use it to help prevent DNS poisioning and other DNS attacks.
But, the upstream resolver needs to support DNSSEC. Many don't especially ISP resolvers (DNS Servers).

Again I reference:

DNSSEC – What Is It and Why Is It Important? - ICANN

www.icann.org

 

[Intrepid]

DNSSEC validates the connection between the upstream resolver and the router in our case.

But I think Quad9's implementation of DNSSEC along with DNS-over-TLS (DoT) encryption on the Asus router provides more than enough security as well as reliability for most home and small business users. If you really need DNSSEC at the local router, you must use a DNS provider that reliably supports it - which seems difficult. In my case, the top priority is using the best DNS provider that blocks lookups of malicious host names from an up-to-the-minute list of threats - which is Quad9 (and they use DNSSEC). Quad9's stance is: "If you don't trust Quad9 to perform DNSSEC validation, you should be running your own recursor".

"Local [router] DNSSEC validation provides protection against these cache poisoning attacks:

1. Your ISP injecting unsolicited DNS responses with false information, such as to send you to a search page with ads for mistyped domains
2. Your public resolver unintentionally giving you bad DNS responses because its cache was poisoned
3. Your public resolver intentionally lying to you, potentially because of a government request

Local DNSSEC validation mitigates these attacks by providing end-to-end authentication, at least for signed domains. But there are other solutions to some of these concerns:

#1 can be prevented by encrypting the connection to the public resolver as in DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH). In #2, if the public resolver you are using already does DNSSEC validation and you trust it, then doing the validation locally is redundant. I don’t see other widely-deployed mitigations for #3 for DNS, but SSL/TLS really helps if the lookup is for HTTP traffic."

See: https://cyounkins.medium.com/costs-and-benefits-of-local-dnssec-validation-53c72ca9059b

 

[SkippyP]

Not true. DNSSEC validates the connection between the upstream resolver and the router in our case. DoT does not play in that at all other than to encrypt the connection. Yes, DoT also validates the TCP connection. Bur DNSSEC is not the same as DoT. While DNSSEC may be used between resolvers (servers) it is very important to use it to help prevent DNS poisioning and other DNS attacks.
But, the upstream resolver needs to support DNSSEC. Many don't especially ISP resolvers (DNS Servers).

Again I reference:

DNSSEC – What Is It and Why Is It Important? - ICANN

www.icann.org

How would DNS get poisoned in the last mile if your traffic is encrypted between your router and your upstream resolver? While probably not impossible, I’d assume it’s extremely unlikely and nearly zero risk.

 

[Intrepid]

How would DNS get poisoned in the last mile if your traffic is encrypted between your router and your upstream resolver? While probably not impossible, I’d assume it’s extremely unlikely and nearly zero risk.

Agreed. DoT and DoH establish a secure connection directly with the DNS resolver. If you trust your DNS provider and they have implemented DNSSEC validation (like Quad9), you can also trust your DNS even without local DNSSEC on your router.

 

[dave14305]

How do resolvers that modify/filter DNS results (Quad9, OpenDNS, Cloudflare for Families, NextDNS, etc.) handle DNSSEC signing? They are altering the original response. How do they sign that?

Granted, very few blocked domain owners probably bothered to implement DNSSEC…

 

[Intrepid]

How do resolvers that modify/filter DNS results (Quad9, OpenDNS, Cloudflare for Families, NextDNS, etc.) handle DNSSEC signing? They are altering the original response. How do they sign that?

They don't re-sign it - but it doesn't matter since the response would be NXDomain anyway (for Quad9) or a redirection to a warning page.
See: https://www.snbforums.com/threads/d...not-to-load-properly.90670/page-3#post-914606

 

[dave14305]

They then modify the result (for example, for a malware domain) and send an NXDomain (a non-existent domain) response after they re-sign the modified response with their own DNSSEC signature.

Isn’t this a problem then if Quad9 (or any other DNS operator) modifies the expected signature? That’s the reason for my question.

 

[bbunge]

Isn’t this a problem then if Quad9 (or any other DNS operator) modifies the expected signature? That’s the reason for my question.

Come on @dave14305. You are baiting @Intrepid and @SkippyP . But they need to be baited as they refuse to understand DNS and DNS Security. DNSSEC between authoritive resolvers and DNS providers is not the issue but between the DNS provider's server, AKA an upstream resolver, and their router. They just refuse to see that the DNS link between these points is vulnerable. They base their judgement on old reviews and YouTube videos made by folks who are interested in making money by getting clicks. I guess that is OK as there is sometining about taking a horse to water....

 

[Intrepid]

Isn’t this a problem then if Quad9 (or any other DNS operator) modifies the expected signature? That’s the reason for my question.

Using DNSSEC, they validate the authenticity of the original response received from the authoritative nameserver. If and only if it's a malicious domain, do they modify the response to prevent you from reaching the harmful site. I don't think they sign the modified response with DNSSEC because it wouldn't be valid with the original signature chain. However, they will encrypt it if the end user is utilizing DoT or DoH. So, if you trust Quad9 and you're using DoT or DoH encryption you can trust their response as it will be secure. I assume if you visit a malicious domain, Quad9 modifies the response, and you have DNSSEC enabled on your router it will fail DNSSEC validation. But that wouldn't matter since the response was NXDomain anyway.

But they need to be baited as they refuse to understand DNS and DNS Security. DNSSEC between authoritive resolvers and DNS providers is not the issue but between the DNS provider's server, AKA an upstream resolver, and their router. They just refuse to see that the DNS link between these points is vulnerable.

It's only vulnerable if you do not use DoT or DoH. And try not to be condescending.

 

[Tech9]

I personally always recommend this configuration:

DNSSEC with DoT to upstream trusted DNS resolver is not necessary. Quad9 response is correct.

 

[bbunge]

I personally always recommend this configuration:

View attachment 59693

DNSSEC with DoT to upstream trusted DNS resolver is not necessary. Quad9 response is correct.

Well, DoT to Quad9 does not always work either. I did use Quad9 for several years with plain old DNS. And it worked mostly when my ISP would route the anycast addresses correctly..

My only concern with using DNSSEC the way Merlin and Asus have implemented it is the root keys are hard coded into the dnsmasq config file. If and when ICAN decides to change the root keys, there will need to be a firmware upgrade to make the change in the Asus router. I discussed this with Merlin some time ago and he tried to assure me that plenty of notice of a change would be given. Right. I feel that dynamic retrieval of the keys is a better solution and Stubby can do just that. I am, however, resolved that nothing will change until a major hack or crash happens.

 

[Tech9]

My only concern with using DNSSEC the way Merlin and Asus have implemented it

It's just an available option. Default is disabled. Best compatibility - disabled. Options creating issues shouldn't be exposed. Asuswrt is full of exposed options for no reason and with no dependencies. You can do completely senseless configurations and no warning will be shown. Many examples.

 

[OzarkEdge]

It's just an available option. Default is disabled. Best compatibility - disabled. Options creating issues shouldn't be exposed. Asuswrt is full of exposed options for no reason and with no dependencies. You can do completely senseless configurations and no warning will be shown. Many examples.

ASUSWRT 5.0 on AX88U Pro does not appear to expose those settings you recommend, unless I'm missing something, so maybe ASUS heard you.

OE

 

[RMerlin]

DNSSEC validates the connection between the upstream resolver and the router in our case.

That`s not the scenario he asked about. He asked about what if you don't enable DNSSEC on the router, in which case validation will be between Quad9 and the authoritative DNS. Whatever is passed on to you can still be intercepted and rewritten, unless you use DoT.

 

[Tech9]

so maybe ASUS heard you

Interesting. I remember it was there in 388 firmware.

Does the option reappear if you disable DoT? Perhaps they have some logic behind it now.

 

[OzarkEdge]

Interesting. I remember it was there in 388 firmware.

Does the option reappear if you disable DoT? Perhaps they have some logic behind it now.

No, I tried that before I spoke... did not Save but that shouldn't matter.

OE

 

[Tech9]

It's coming back to RT-AX88U Pro perhaps. RT-AX86U Pro runs on newer 102 version.