[Thread-1] [ 386.1_Alpha Build(s) ] Testing available build(s)

[Wallace_n_Gromit]

This is what the "Validate unsigned DNSSEC replies" option does, and Asuswrt-Merlin enables that by default if you enable DNSSEC validation. If you issue a request for a signed domain and receive an unsigned reply, your router will reject it.

I have had both Enable DNSSEC support = Yes and Validate unsigned DNSSEC replies = Yes. So now that I am better informed by the value provided by the Merlin firmware, NO more worries... for now.

NOTE: yup, just go back to my usual worries: porch pirates, premature balding, ex'es attorney at front door serving me with papers for additional alimony. etc. etc.

 

[dave14305]

I have had both Enable DNSSEC support = Yes and Validate unsigned DNSSEC replies = Yes. So now that I am better informed by the value provided by the Merlin firmware, NO more worries... for now.

The shortcoming of this is that a relatively low percentage of domains on the internet are using DNSSEC.

 

[cooloutac]

The shortcoming of this is that a relatively low percentage of domains on the internet are using DNSSEC.

thats what they keep saying. I guess if you factor in all public and isp servers. But i'm pretty sure all the major ones do, so at the same time there is a large footprint for it. I think the real shortcoming is that most people don't change their dns server, or take advantage of the feature. so you are correct there. definitely most people don't use dot or dnscrypt lol.

 

[RMerlin]

The shortcoming of this is that a relatively low percentage of domains on the internet are using DNSSEC.

Correct. Very few domains actually implement DNSSEC signing (all my domains do), so it will only protect you when using these domains. Which is a shame, I've been advocating for DNSSEC for years, as the current DNS system has no other method of validating the authenticity of any DNS query, and these are the weakest link out there, since a DNS attack can redirect you to pretty much anywhere than the intended destination.

The write ups I've seen so far weren't clear whether clients are vulnerable, or just servers. In a router's case, it's basically a client, since the router merely forwards queries to your resolvers.

I guess if you're worried, you could switch to using an upstream DNS that has reported not being vulnerable or having patched it on their end.

 

[cooloutac]

Correct. Very few domains actually implement DNSSEC signing (all my domains do), so it will only protect you when using these domains. Which is a shame, I've been advocating for DNSSEC for years, as the current DNS system has no other method of validating the authenticity of any DNS query, and these are the weakest link out there, since a DNS attack can redirect you to pretty much anywhere than the intended destination.

The write ups I've seen so far weren't clear whether clients are vulnerable, or just servers. In a router's case, it's basically a client, since the router merely forwards queries to your resolvers.

I guess if you're worried, you could switch to using an upstream DNS that has reported not being vulnerable or having patched it on their end.

gotta get the ISP's to implement which is the major factor. its ironic, because not naming names, some people have posts on these forums recommending people use their ISP's dns which blows my mind. They are a redirect city lol. This year its worse then its ever been. Does any isp even implement dnssec? It has be rare. I think there is cobwebs in most of them...

 

[dave14305]

Correct. Very few domains actually implement DNSSEC signing (all my domains do), so it will only protect you when using these domains. Which is a shame, I've been advocating for DNSSEC for years, as the current DNS system has no other method of validating the authenticity of any DNS query, and these are the weakest link out there, since a DNS attack can redirect you to pretty much anywhere than the intended destination.

The write ups I've seen so far weren't clear whether clients are vulnerable, or just servers. In a router's case, it's basically a client, since the router merely forwards queries to your resolvers.

I guess if you're worried, you could switch to using an upstream DNS that has reported not being vulnerable or having patched it on their end.

There's an interesting test link on the site that checks your DNS server. I'm using Unbound locally, so it's checking my WAN IP and reporting I'm safe.

Your DNS server IP is 68.36.xx.xx
Since it blocks outgoing ICMP packets, your DNS server is not vulnerable.
The test currently only takes the side channel port scanning vulnerability into consideration. A successful attack may also require other features in the server (e.g., supporting cache).
The test is conducted on 2020-11-18 20:41:18.629957156 UTC
Disclaimer: This test is not 100% accurate and is for test purposes only.

 

[cooloutac]

There's an interesting test link on the site that checks your DNS server. I'm using Unbound locally, so it's checking my WAN IP and reporting I'm safe.

Your DNS server IP is 68.36.xx.xx
Since it blocks outgoing ICMP packets, your DNS server is not vulnerable.
The test currently only takes the side channel port scanning vulnerability into consideration. A successful attack may also require other features in the server (e.g., supporting cache).
The test is conducted on 2020-11-18 20:41:18.629957156 UTC
Disclaimer: This test is not 100% accurate and is for test purposes only.

did that site just say cloudflare and google are vulnerable? huh? think they just used their ip's as examples of a dns server. Well i just tested mine and it says I am not vulnerable. according to the site, 35% of resolvers are vulnerable. crazy how windows is the only os that blocks outgoing icmp's by default? There is a patch made for linux kernel so hopefully those systems get updated soon.

wonder how I can check the dns server on my lan.

 

[Wallace_n_Gromit]

did that site just say cloudflare and google are vulnerable? huh? think they just used their ip's as examples of a dns server. Well i just tested mine and it says I am not vulnerable. according to the site, 35% of resolvers are vulnerable. crazy how windows is the only os that blocks outgoing icmp's by default? There is a patch made for linux kernel so hopefully those systems get updated soon.

wonder how I can check the dns server on my lan.

When the SAD DNS paper was being prepared, they did find that Google and Cloudflare were vulnerable. They dutifully reported to them about this Side Channel attack which the DNS services patched before publication of their paper. I did notice that Cloudflare's website didn't mention how they found out about this issue. hummmmm

 

[cooloutac]

When the SAD DNS paper was being prepared, they did find that Google and Cloudflare were vulnerable. They dutifully reported to them about this Side Channel attack which the DNS services patched before publication of their paper. I did notice that Cloudflare's website didn't mention how they found out about this issue. hummmmm

wow very interesting! how did you come by this information? so 35% of resolvers were vulnerable and google and cloudflare were one of them!?! wow. I would think not if using dnssec with them though. I use quad 9 btw. I appreciate you bringing all this to our attention. I learned about sad dns on security now as well. I love that show.

 

[RMerlin]

There's an interesting test link on the site that checks your DNS server. I'm using Unbound locally, so it's checking my WAN IP and reporting I'm safe.

Not sure how thorough such a test would be however. Your recursive resolver needs to contact other servers upstream, so if these are vulnerable, I assume the whole chain can potentially be compromised.

This is probably a case where every server will need to be separately secured.

 

[dave14305]

Not sure how thorough such a test would be however. Your recursive resolver needs to contact other servers upstream, so if these are vulnerable, I assume the whole chain can potentially be compromised.

This is probably a case where every server will need to be separately secured.

I agree that the story is incomplete, and I haven’t read the whole paper, nor studied the entire poster they made, but I don’t think that the authoritative name servers Unbound would talk to are getting their info from another source, since they are authoritative. I’ll do more homework tonight and revise my thoughts tomorrow in the original SADDNS thread. This interesting discussion is misplaced in this thread.

 

[RMerlin]

but I don’t think that the authoritative name servers Unbound would talk to are getting their info from another source, since they are authoritative

Correct. A typical recursive lookup would probably involve your Unbound contacting the TLD, then the domain authoritative servers. That test possibly just tested the connection between your client and Unbound, I don't know if it tested the two servers Unbound will need to contact itself (well, I would expect TLD servers to be patched pretty quickly if they even need patching, the result may vary with the domain authoritative server however).

 

[Wallace_n_Gromit]

wow very interesting! how did you come by this information? so 35% of resolvers were vulnerable and google and cloudflare were one of them!?! wow. I would think not if using dnssec with them though. I use quad 9 btw. I appreciate you bringing all this to our attention. I learned about sad dns on security now as well. I love that show.

WHEW!!! Took me some time to find where I found that information. I've only been trying to wrap my mind around the issue since 7:39PM last night. and then posting on this thread when I could try to ask a coherent question, expressing my concern and to discover mitigations.

NOTE: Toward the End of the Security Now Podcast (I love that show too) They do emphasize that the problem resides with the DNS server being spoofed to provide you the Client with incorrect DNS. Bind, Unbound, and DNSmasq are vulnerable.

Solved - Are you SAD DNS? a.k.a. CVE-2020-25705

CVE-2020-25705 https://www.saddns.net/ [Discussion starts 1:15:13 into podcast] https://blog.cloudflare.com/sad-dns-explained/ https://thehackernews.com/2020/11/sad-dns-new-flaws-re-enable-dns-cache.html...

www.snbforums.com

[At 1:54:43 into podcast] Leo Laporte mentions that the researchers told DNS Public Resolvers including Cloudflare about this issue before they published their paper.

Additional Note: Also [https://blog.cloudflare.com/sad-dns-explained/] "... As part of a coordinated disclosure effort earlier this year, the researchers contacted Cloudflare and other major DNS providers and we are happy to announce that 1.1.1.1 Public Resolver is NO LONGER VULNERABLE (emphasis mine) to this attack."

 

[RMerlin]

and DNSmasq are vulnerable.

I assume however that implies any dnsmasq exploit would have to be done LAN-side, since it's not a public resolver.

 

[zenmota]

I can understand your confusion and to be honest I don't know what your previous builds were showing as value and if the current behavior per design or not, but from my point of view this is something what is to be expected. If you build up a VPN connection you create a secure "tunnel" in which your (encrypted) communication is taking place between you and the destination (VPN server) with the different IP address as you described. However, the connection outside your tunnel is the (public) IP address provided by your ISP. The payload inside your packet that you generate is not regular http/ftp/bt whatever data, but the data from your VPN tunnel (encrypted). So for you as a user it seems you are communicating to the other side like if it was regular traffic with an IP address which can be seen by everyone but in fact you communicate via that encrypted payload send over your outside internet traffic via the IP provided by your ISP.
Simply see it as a networkcable. The connectors and cable itself is your outside connection between client and server and everyone can see that cable (your public IP address given by your ISP) but the wiring inside the cable is the VPN tunnel over which you communicate (which no one can see since it is inside the cable and encrypted with that different IP that you talked about).

Thanks for info. It helped some. Maybe now it is working correctly since it does show I am connected to the Internet when going through VPN and it does show the real IP Address that my ISP gives me when going through VPN. All builds before it always show I was disconnect from the Internet when going through VPN even thought I wasn't.

Thanks....

 

[SomeWhereOverTheRainBow]

This is what the "Validate unsigned DNSSEC replies" option does, and Asuswrt-Merlin enables that by default if you enable DNSSEC validation. If you issue a request for a signed domain and receive an unsigned reply, your router will reject it.

So I am on alpha 3 and i do not see validate unsigned dnssec enabled in dnsmasq.conf, but i have it turned on in the gui. is the option enabled by default and only used to disable if user specifies?

 

[SomeWhereOverTheRainBow]

I assume however that implies any dnsmasq exploit would have to be done LAN-side, since it's not a public resolver.

Yea the only way I see someone being vulnerable to saddns exploit is if they are using a resolver that was impacted or they are running a WAN faced unblocked recursive resolver.

 

[deathnite]

The new built-in Ookla speedtest is nice.
On AC86U the highest result I got is 752 Mbps, while on speedtest.net with the same server I get over 900 Mbps. I guess the hardware in this router is not powerful enough to reach 900 Mbps with the built-in speedtest.

 

[RMerlin]

So I am on alpha 3 and i do not see validate unsigned dnssec enabled in dnsmasq.conf, but i have it turned on in the gui. is the option enabled by default and only used to disable if user specifies?

That's correct, it's the default behaviour in dnsmasq - that was changed at one point.

 

[faria]

The new built-in Ookla speedtest is nice.
On AC86U the highest result I got is 752 Mbps, while on speedtest.net on the same server I get over 900 Mbps. I guess the hardware in the router is not powerful enough to reach 900 Mbps with the built-in speedtest.

View attachment 27771

those speeds are consistent with my rt-ac86u too. In the RT-AX86U Ookla speedtest reports 900+Mbps up and down.