[Preview] Asuswrt-Merlin 384.11 with DNS over TLS

[Gar]

You can try clicking on "Refresh" on the networkmap, then wait about 2 minutes for things to stabilize. Until Asus fixes it, that's the best that can be done.

That seems to work pretty well, just turn on the devices first and let them be detected. Thanks.

 

[owine]

Guess I do no see your point. Same port traffic parallels through while different ports daisy chains traffic into dnsmasq then stubby-getdns and reverse.
Can you give us a way to modify stubby.yml? There are settings I would like to change that are not covered in the gui.

Sent from my SM-T380 using Tapatalk

stubby listens on 127.0.1.1 while dnsmasq listens on 127.0.0.1. dnsmasq uses 127.0.1.1 as its resolver so dnsmasq continues its caching role.

 

[dave14305]

Guess I do no see your point. Same port traffic parallels through while different ports daisy chains traffic into dnsmasq then stubby-getdns and reverse.
Can you give us a way to modify stubby.yml? There are settings I would like to change that are not covered in the gui.

Sent from my SM-T380 using Tapatalk

Same port but different loopback IP 127.0.1.1 instead of 127.0.0.1. LAN client requests still go to dnsmasq on 192.168.1.1:53 then to stubby at 127.0.1.1:53.

I’m just not sure if the router will resolve (through dnsmasq) its own local nslookups based on the new design. Seems resolv.conf will point directly to Stubby.

Edit: confused /tmp/resolv.conf with /tmp/etc/resolv.conf. I need to get a life...

 

[themiron]

I’m just not sure if the router will resolve (through dnsmasq) its own local nslookups based on the new design.

Depending on "Wan: Use local caching DNS server as system resolver (default: Yes)" setting, it was always enabled in Asuswrt-Merlin and only recently was exposed in web ui. If enabled - router will resolve though dnsmasq (and whatever dnsmasq is pointed), if disabled (official fw default behavior) - router will resolve via resolv.conf nameservers, whatever they are.

Edit: confused /tmp/resolv.conf with /tmp/etc/resolv.conf. I need to get a life...

We need to go deeper (c) There's /tmp/resolv.dnsmasq as well, independent from /tmp/resolv.conf, and /etc/resolv.conf with content based on that "Wan: Use local caching DNS server as system resolver (default: Yes)" setting

 

[RMerlin]

Same port traffic parallels through while different ports daisy chains traffic into dnsmasq then stubby-getdns and reverse.

The port used makes no difference there.

 

[john9527]

Just for reference, I thought I would post a screenshot of my current fork DoT gui and the options I offer.

The server list is a csv file and can be updated by downloading just a new csv (I provide a script to do the download).

The 'Selected servers' list reflects the order in which the servers were selected.

 

[RMerlin]

I just ran a number of tests on DNSFilter, I can confirm that it's working as expected. If someone leaves the DNS Server fields empty on the DHCP page (so DHCP will use the router's own IP), then it will force your clients to all go through DNS Privacy (stubby).

If you set a specific IP in DNSFilter (for instance something to geo-unlock Netflix, or a filtering service like OpenDNS), then this will allow that client to bypass DNS Privacy, and use the specifiedDNS.

 

[Gingernut]

On the DNSFilter front, I haven't had the time to test/evaluate the various usage scenario yet. In theory, this is how it should work (again, untested yet):

• If a DNSFilter is set to Router and you have DoT enabled, then it will force that client to use DoT
• If a DNSFilter is set to a specific server/IP (for instance OpenDNS), it will force that client to use OpenDNS, bypassing DoT. It will also prevent that client from using DoT, unless it's the same server
• If a DNSFilter is set to unfiltered, then it could use either DNSFilter, or any server configured in the client (for instance, Android devices might still use 8.8.8.8 for applications like Netflix)

Working as intended, just the lan's custom DNS 1 & 2 fields need to be blank for it all to work.

DoT setup webUI is layman friendly.

Thxs

 

[RMerlin]

Working as intended, just the lan's custom DNS 1 & 2 fields need to be blank for it all to work.

DoT setup webUI is layman friendly.

Thxs

Yep, I just finished testing all various scenarios.

Also, I'm pretty sure by now that Cloudflare's test is unreliable. I ran tcpdump while using their test, and while it claims I am not using DoT, tcpdump clearly shows that ALL DNS traffic went to port 853 - nothing was sent through port 53.

So, I'm not quite sure why enabling dnssec causes that test to fail. Maybe because their own DNS had to do recursive signature lookups to validate the dnssec signature, and these are obviously done over plain DNS by their server? Not sure how it's able to detect that during its test then, unless they automatically have the test report failure whenever dnssec is involved.

 

[bbunge]

Yep, I just finished testing all various scenarios.

Also, I'm pretty sure by now that Cloudflare's test is unreliable. I ran tcpdump while using their test, and while it claims I am not using DoT, tcpdump clearly shows that ALL DNS traffic went to port 853 - nothing was sent through port 53.

So, I'm not quite sure why enabling dnssec causes that test to fail. Maybe because their own DNS had to do recursive signature lookups to validate the dnssec signature, and these are obviously done over plain DNS by their server? Not sure how it's able to detect that during its test then, unless they automatically have the test report failure whenever dnssec is involved.

We have been saying for months that the Cloudflare help test is broken when DNSSEC is enabled on the router. I know of no online test that checks the router DNSSEC. Dig, in its various forms, from the LAN or router does.

Sent from my SM-T380 using Tapatalk

 

[dave14305]

Depending on "Wan: Use local caching DNS server as system resolver (default: Yes)" setting, it was always enabled in Asuswrt-Merlin and only recently was exposed in web ui. If enabled - router will resolve though dnsmasq (and whatever dnsmasq is pointed), if disabled (official fw default behavior) - router will resolve via resolv.conf nameservers, whatever they are.

We need to go deeper (c) There's /tmp/resolv.dnsmasq as well, independent from /tmp/resolv.conf, and /etc/resolv.conf with content based on that "Wan: Use local caching DNS server as system resolver (default: Yes)" setting

When I disable "Wan: Use local caching DNS server..." and enable DNS Privacy, I end up with 3 entries in /tmp/resolv.conf: WAN DNS1, WAN DNS2 and 127.0.1.1. In that scenario, the router resolver will likely never use DoT because the WAN DNS entries are first. Is that intentional, or what is the reasoning behind all 3 entries being added if DNS Privacy is the goal?
My WAN DNS is set to OpenDNS:

# ls -l /etc/resolv.conf
lrwxrwxrwx    1 admin root            16 Apr 16 08:49 /etc/resolv.conf -> /tmp/resolv.conf
# cat /tmp/resolv.conf
nameserver 208.67.222.222
nameserver 208.67.220.220
nameserver 127.0.1.1
# nslookup asuswrt.lostrealm.ca
Server:    208.67.222.222
Address 1: 208.67.222.222 resolver1.opendns.com

Name:      asuswrt.lostrealm.ca
Address 1: 174.142.221.134

 

[Swistheater]

When I disable "Wan: Use local caching DNS server..." and enable DNS Privacy, I end up with 3 entries in /tmp/resolv.conf: WAN DNS1, WAN DNS2 and 127.0.1.1. In that scenario, the router resolver will likely never use DoT because the WAN DNS entries are first. Is that intentional, or what is the reasoning behind all 3 entries being added if DNS Privacy is the goal?
My WAN DNS is set to OpenDNS:

# ls -l /etc/resolv.conf
lrwxrwxrwx    1 admin root            16 Apr 16 08:49 /etc/resolv.conf -> /tmp/resolv.conf
# cat /tmp/resolv.conf
nameserver 208.67.222.222
nameserver 208.67.220.220
nameserver 127.0.1.1
# nslookup asuswrt.lostrealm.ca
Server:    208.67.222.222
Address 1: 208.67.222.222 resolver1.opendns.com

Name:      asuswrt.lostrealm.ca
Address 1: 174.142.221.134

the wan dns entries are what are used for that first connection.

 

[lagopodous]

Which build should I use for ac68? There's 2 of them

 

[dave14305]

Which build should I use for ac68? There's 2 of them

Use the one starting with RT-AC68U... Don't use the one starting with RT-AC86U...

 

[dave14305]

the wan dns entries are what are used for that first connection.

Yes, I would just expect to only see one or the other (WAN DNS or Stubby loopback), but not both. Not sure of the real-world scenarios where it would make sense to have all 3 if you want to bypass dnsmasq on the router locally. I suppose it's more academic than anything else at this point. Like I said, I need to get a life.

Spoiler

 

[Gar]

Does anyone ever see DoT in use using other than CF and their app? I haven't so far and wonder if that isn't more evidence that the CF test is broken/rigged?

 

[Clark Griswald]

No complaints of drops of glitches from Family!
Clean install of alpha 2, cloudflare servers, no DNSSEC:

Using DNS over HTTPS (DoH) No
Using DNS over TLS (DoT) Yes
AS Name Cloudflare
AS Number 13335
Cloudflare Data Center SMF
1.1.1.1 Yes
1.0.0.1 Yes
2606:4700:4700::1111 Yes
2606:4700:4700::1001 Yes

 

[Billy Chaney]

I checked here to see if my DNSSEC was working and it is.

https://www.dnssec-deployment.org/

 

[dave14305]

Any feedback on the webui implementation? Does it look intuitive to use in its current form?

Would it be feasible to move the preset dropdown list to the Address field under "DNS-over-TLS Server List"? It would just seem more intuitive to me.
I also think some kind of explanation of the role of WAN DNS servers when DNS Privacy is enabled would be helpful. In most cases, DoT takes over WAN DNS responsibilities, so it just feels like WAN DNS 1 and 2 need to be de-emphasized when DoT is enabled and not accepting ISP DHCP DNS servers automatically.

 

[bbunge]

Does anyone ever see DoT in use using other than CF and their app? I haven't so far and wonder if that isn't more evidence that the CF test is broken/rigged?

The CF test is not broken. Just has its limitations. It does verify that DoT or DoH is working. It does not test other resolvers. I have tested and use Quad9 and CleanBrowsing as well as Cloudflare. Usually do not use DNSSEC, with the Entware/Stubby install but this Alpha2 version seems to be running very well with DNSSEC enabled on Quad9.