[Preview] Asuswrt-Merlin 384.11 with DNS over TLS

[bbunge]

it must be there, othercase authenticated status of reply from stubby will be lost in dnsmasq and will never reach lan clients.


because this file is the only valid path with upstream (isp) nameservers that stubby can use.


right, not a really great idea to have it configured, taking into account ntp issue was fixed in alpha2 and dnsmasq will always try to resolve all [*.]pool.ntp.org via 1.1.1.1 w/o dot/dnssec/etc with this record even if internet connection was not built or can't be built yet (think about pptp/l2tp or pppoe+dhcp, or other vpn-foo).


yes, it's bad idea causing dns loop.


yep, add that servers via web ui.


things were changed, seems dnsmasq's dnssec works a bit faster unlike stubby with its additional uncached dot checking requests for every incoming one. so, dnsmasq now is used for dnssec for all non-dot + dot cases.
automatic anchor download is a good feature, but not a big deal.


no, they are different.
strict validation is about deeper checking of unsigned replies, dnsmasq takes steps to be sure they are really not signed. dnssec vs dnssec_return_status is more about bad/changed replies at the time when they can't be checked at all (due no root keys accesible, blocked by firewall, routing or so) and therefore dnssec validation is not functional.

Sometimes it is best to quit arguing and let the other person be wrong. This is one of those cases.

Sent from my SM-T380 using Tapatalk

 

[Marin]

@bbunge and @themiron,

Would you be so kind to share some screenshots of your preferred WAN DNS and DOT setups?

Thank you!


Sent from my iPhone using Tapatalk

 

[RMerlin]

in reality they should setup the three option system -like john's fork

This only leads to end-user confusion, and endless support questions. We want to limit things to a bare minimum set of config parameters. Best to have the developers pick the best design possible for everyone from a technical point of view, and stick to it. Right now, after having discussed it with themiron, it was decided to revert all DNSSEC duties back to dnsmasq, for performance reasons (benefit from dnsmasq's caching abilities) and simplicity reason (simpler = more reliable). This will be a cleaner design:

1) dnsmasq gets the request. It sends it to stubby.
2) Stubby does the recursive lookups through DoT, and gives the replies back to dnsmasq. And does nothing more.
3) Dnsmasq validates the DNSSEC, and decides whether to return a NXDOMAIN to clients, or not. And it caches the result.

This will be implemented in the next test build (code is already on Github).

 

[skeal]

Well you didn't ask for mine but these settings work for me and my static IP.

 

[L&LD]

Well you didn't ask for mine but these settings work for me and my static IP.View attachment 17200

Image is too small/blurry to read.

 

[skeal]

Image is too small/blurry to read.

Check again and let me know.

 

[L&LD]

Check again and let me know.

Now, there is no image.

 

[Marin]

Well you didn't ask for mine but these settings work for me and my static IP.View attachment 17202

Thank you!

 

[skeal]

Now, there is no image.

Sorry I got called away during the edit. Should be ok now.

 

[dave14305]

1) dnsmasq gets the request. It sends it to stubby.
2) Stubby does the recursive lookups through DoT, and gives the replies back to dnsmasq. And does nothing more.
3) Dnsmasq validates the DNSSEC, and decides whether to return a NXDOMAIN to clients, or not. And it caches the result.

Is step 3 done by dnsmasq through Stubby’s TLS connection or in the clear? Just wondering how this impacts the potential privacy implications for those who desire extreme privacy (asking for a friend).

Edit: I suppose it would need to be through Stubby because Stubby is the only upstream dnsmasq is aware of.

 

[Marin]

Check again and let me know.

I am able to see it - thanks again!

 

[EmeraldDeer]

Is step 3 done by dnsmasq through Stubby’s TLS connection or in the clear? Just wondering how this impacts the potential privacy implications for those who desire extreme privacy (asking for a friend).

Edit: I suppose it would need to be through Stubby because Stubby is the only upstream dnsmasq is aware of.

With proxy-dnssec, DNSSEC validation is just a flag that came along with the DNS reply from Step 2. Step 2 was through DNS over TLS. Actual DNSSEC validation had been performed by the DNS provider in Step 2.

 

[bbunge]

@bbunge and @themiron,

Would you be so kind to share some screenshots of your preferred WAN DNS and DOT setups?

Thank you!


Sent from my iPhone using Tapatalk

 

[Marin]

Yep that is what I have . Thank you for sharing!

 

[dave14305]

With proxy-dnssec, DNSSEC validation is just a flag that came along with the DNS reply from Step 2. Step 2 was through DNS over TLS. Actual DNSSEC validation had been performed by the DNS provider in Step 2.

You’re describing the Alpha4 behavior, if I follow you. But in the next build, Stubby won’t enable any dnssec extensions, so dnsmasq will need to perform those validations if dnssec is enabled. I’m not familiar with how dnsmasq does that so I was worried for a moment that it was going to do this outside the TLS tunnel, but that’s not possible since it has no other upstream path besides Stubby.

 

[hifiwifi]

Does DoT prevent ASUS from snooping on DNS traffic? (I'm assuming here, perhaps wrongly, that ASUS services have this privilege. I don't know that for certain, and I understand they are closed source).

 

[dave14305]

You’re describing the Alpha4 behavior, if I follow you. But in the next build, Stubby won’t enable any dnssec extensions, so dnsmasq will need to perform those validations if dnssec is enabled. I’m not familiar with how dnsmasq does that so I was worried for a moment that it was going to do this outside the TLS tunnel, but that’s not possible since it has no other upstream path besides Stubby.

And just to share my learnings with everyone, this is a test of using dnsmasq dnssec with Stubby doing no DNSSEC Validation itself, on John’s fork:

Apr 24 21:30:37 dnsmasq[2140]: 130 192.168.1.120/61356 query[A] asuswrt.lostrealm.ca from 192.168.1.120
Apr 24 21:30:37 dnsmasq[2140]: 130 192.168.1.120/61356 forwarded asuswrt.lostrealm.ca to 127.0.0.1
Apr 24 21:30:37 dnsmasq[2140]: * 192.168.1.120/61356 dnssec-query[DS] ca to 127.0.0.1
Apr 24 21:30:37 dnsmasq[2140]: * 192.168.1.120/61356 reply ca is DS keytag 2134, algo 8, digest 2
Apr 24 21:30:37 dnsmasq[2140]: * 192.168.1.120/61356 dnssec-query[DS] lostrealm.ca to 127.0.0.1
Apr 24 21:30:37 dnsmasq[2140]: * 192.168.1.120/61356 dnssec-query[DNSKEY] ca to 127.0.0.1
Apr 24 21:30:37 dnsmasq[2140]: * 192.168.1.120/61356 reply ca is DNSKEY keytag 2134, algo 8
Apr 24 21:30:37 dnsmasq[2140]: * 192.168.1.120/61356 reply ca is DNSKEY keytag 35433, algo 8
Apr 24 21:30:37 dnsmasq[2140]: * 192.168.1.120/61356 reply lostrealm.ca is DS keytag 2371, algo 13, digest 2
Apr 24 21:30:37 dnsmasq[2140]: * 192.168.1.120/61356 dnssec-query[DNSKEY] lostrealm.ca to 127.0.0.1
Apr 24 21:30:37 dnsmasq[2140]: * 192.168.1.120/61356 reply lostrealm.ca is DNSKEY keytag 34505, algo 13
Apr 24 21:30:37 dnsmasq[2140]: * 192.168.1.120/61356 reply lostrealm.ca is DNSKEY keytag 2371, algo 13
Apr 24 21:30:37 dnsmasq[2140]: 130 192.168.1.120/61356 validation result is SECURE
Apr 24 21:30:37 dnsmasq[2140]: 130 192.168.1.120/61356 reply asuswrt.lostrealm.ca is 174.142.221.134

I can see dnsmasq passing the validation queries to 127.0.0.1:8453 in my case, proving that I was a worry wart for nothing.

 

[L&LD]

A few pages back,

https://www.snbforums.com/threads/p...1-with-dns-over-tls.56095/page-21#post-484234

@Elmer asked a good question. I was looking forward to it being answered.

A complete answer from one of the users here that are really understanding the dns-over-tls options would (and I'm sure checked by everyone else) would be a good 'how to guide' for setting up 384.11 and forward.

I have tried to write up something myself, even a preliminary version, but it seems the assumptions change very fast and when I read back what I had written, I found I was contradicting myself (a lot).

 

[skeal]

A few pages back,

https://www.snbforums.com/threads/p...1-with-dns-over-tls.56095/page-21#post-484234

@Elmer asked a good question. I was looking forward to it being answered.

A complete answer from one of the users here that are really understanding the dns-over-tls options would (and I'm sure checked by everyone else) would be a good 'how to guide' for setting up 384.11 and forward.

I have tried to write up something myself, even a preliminary version, but it seems the assumptions change very fast and when I read back what I had written, I found I was contradicting myself (a lot).

@themiron and @RMerlin are the only information sources that matter. They are responsible for DoT's implementation on this firmware. I would have faith in them. Just saying, there has been a lot of assumptions made in this thread (me included), but in the end it's these two fellas that you want to hear from. See both of their earlier posts above for answers.

 

[Marin]

I couldn't agree more with @L&LD. It would be great to have an "Intro to DOT" setup guide....Perhaps a "basic" guide when setting up an initialized router with a freshly installed FW and another supplemental one containing various tweaks (and some basic validation commands) for troubleshooting and more advanced users.