[Fork] Asuswrt-Merlin 374.43 LTS - DNS over TLS Beta - CLOSED

[jrmwvu04]

does it work with AB-solution?

Yeah, should.

 

[ColinTaylor]

Hi Guys,

I've been using namebench to see what impact this (DNS over TLS) has on my uncached DNS response times.

One thing that became apparent during testing was the way stubby queries the upstream servers. Unlike dnsmasq stubby queries the servers on a strict round robin basis (round_robin_upstreams: 1). So if you have configured stubby to use two servers, one fast and one slow, 50% of your uncached queries will be slow.

By contrast dnsmasq will modify its behaviour to prefer fast servers over slow ones. But of course it can't do that anymore because it only knows about one upstream server (stubby).

Here is an example of response times when stubby is configured with one fast server and one slow.

Here's another example with two fast servers and one slow.

 

[john9527]

Unlike dnsmasq stubby queries the servers on a strict round robin basis (round_robin_upstreams: 1). So if you have configured stubby to use two servers, one fast and one slow, 50% of your uncached queries will be slow.

If you want to experiment further, I did implement support for custom scripts. So you could use a stubby.postconf to change the value of round_robin_upstreams to 0 (then the servers will be accessed in the order listed in the select dialogue).

I could also add a 'manual' server selection choice. Then you could use a stubby.yml.add (note it's NOT stubby.conf.add) where you could add the servers you want in the order you want.

 

[ColinTaylor]

If you want to experiment further, I did implement support for custom scripts. So you could use a stubby.postconf to change the value of round_robin_upstreams to 0 (then the servers will be accessed in the order listed in the select dialogue).

I could also add a 'manual' server selection choice. Then you could use a stubby.yml.add (note it's NOT stubby.conf.add) where you could add the servers you want in the order you want.

Thanks for adding the custom script support.

I did think about setting round_robin_upstreams to 0. But then you're getting into the realms second-guessing what might happen in the future. As it is now if one of the servers fails it will already use the other server instead. I suppose if you only had a choice between one fast server that was unreliable and another that was slow but reliable it would be useful.

I think it's more a case of people just being aware of how it works and not selecting multiple servers just because they can.

 

[john9527]

@ColinTaylor

Another option (a bit more work though) would be to have an 'Ordered Access' option where the servers would be accessed in the order you select them in the dialogue.
I may just try and do that one as a 'challenge'

 

[ColinTaylor]

Another option (a bit more work though) would be to have an 'Ordered Access' option where the servers would be accessed in the order you select them in the dialogue.
I may just try and do that one as a 'challenge'

That does sound like a challenge , but I think it would be more useful. People seem to obsess over having "backup" DNS servers. I can image with the current menu system there would be people that would select "lots" of servers thinking that was a good thing, when in fact it would be very bad. If the menu choices were very obviously a priority list it would keep them happy without ruining performance.

How much of this would actually be noticeable to the end user is another question as most of the queries will be cached anyway.

 

[joe a]

I'm not sure how much help this will be, but...
I've got the new beta firmware running on an Asus RT-AC66U_B1. I'm running custom DDNS and DoT using CloudFlare and I haven't experienced any issues yet.

I am curious about this syslog entry:

"Aug 3 06:10:12 stubby-proxy: configured server 'Cloudflare' at address 1.1.1.1:853
Aug 3 06:10:12 stubby-proxy: configured server 'Cloudflare_alt' at address 1.0.0.1:853"

The GUI shows port 5453, but maybe I'm not understanding correctly.

 

[john9527]

I am curious about this syslog entry:

The DoT servers communicate on port 853. The router (dnsmasq) listens on port 53 for DNS requests, then uses port 5453 on your LAN to talk to the stubby proxy, which then sends the request to the DoT server port 853 and handles the TLS encryption.

 

[joe a]

The DoT servers communicate on port 853. The router (dnsmasq) listens on port 53 for DNS requests, then uses port 5453 on your LAN to talk to the stubby proxy, which then sends the request to the DoT server port 853 and handles the TLS encryption.

Awesome! Thank you for the explanation.

And, thanks for your hard work and this great firmware!

 

[soeren]

Thank you for the work you put into this, John.
Unfortunately DoT isn't working for me on my RT-N66. When I enable it, I get either time-outs or a response of 10.0.0.1 to all dns queries. I can't see anything obvious in the logs, and I tried a few servers, and turning dnssec on and off. I can try diagnosing it a bit more tomorrow. I welcome any suggestions on where to start looking.

 

[MasterBash]

I might try this out. I am interested in DoT over DoH. I want to see the speed difference between both. Unfortunately, I haven't found a way to enable DoT on RMerlin yet...

 

[john9527]

Thank you for the work you put into this, John.
Unfortunately DoT isn't working for me on my NT66. When I enable it, I get either time-outs or a response of 10.0.0.1 to all dns queries. I can't see anything obvious in the logs, and I tried a few servers, and turning dnssec on and off. I can try diagnosing it a bit more tomorrow. I welcome any suggestions on where to start looking.

Can you load a syslog up somewhere for me to take a look at? Thanks.

 

[tomsk]

The DoT servers communicate on port 853. The router (dnsmasq) listens on port 53 for DNS requests, then uses port 5453 on your LAN to talk to the stubby proxy, which then sends the request to the DoT server port 853 and handles the TLS encryption.

Looking at a comparison of protocols in the dnscrypt info ( which i suppose is biased towards promoting dnscrypt anyway) there seem to be several minuses on the DoT side. The ease an evil ISP would have to deny service just by blocking port 853 is worrying, although I'm aware that all of these protocols are at the mercy of a providers interception with varying levels of effort.
https://dnscrypt.info/faq/

 

[blueshark]

Best version version for asus RT-AC66U_B1 ?

 

[Grisu]

Best version version for asus RT-AC66U_B1 ?

possibly coming soon Merlin 384.7 (at the moment only alpha1) or if you need Aimesh then stock 21140 or 21152.

You need to tell us your needs !!!

 

[blueshark]

Need DoT. Dont care about aimesh

 

[john9527]

Thank you for the work you put into this, John.
Unfortunately DoT isn't working for me on my RT-N66. When I enable it, I get either time-outs or a response of 10.0.0.1 to all dns queries. I can't see anything obvious in the logs, and I tried a few servers, and turning dnssec on and off. I can try diagnosing it a bit more tomorrow. I welcome any suggestions on where to start looking.

Recreated it (thanks for the PM data, just what I was going to ask you to do ).... but right now I'm stumped. I'm adding some diagnostic code to stubby and making some compile tweaks to see if I can figure out what it's complaining about.

So for everyone else, I'd assume that right now it's not working on the MIPS based routers (but if someone would care to try on an N16 or AC66, it might be helpful).

 

[jeff288]

DoT isn't working either on my N66U, of course only tried Cloudflare. No time to diagnose right now unless I want to deal with a family without internet, then this place becomes a warzone.

 

[underdose]

I've installed stubby on my MacBook Air for DoT and also set Firefox for DoH, both were working fine for a day or so but somehow DoT stopped working. I assume the problem is on Cloudflare's or Stubby's end.

 

[john9527]

Recreated it (thanks for the PM data, just what I was going to ask you to do ).... but right now I'm stumped. I'm adding some diagnostic code to stubby and making some compile tweaks to see if I can figure out what it's complaining about.

So for everyone else, I'd assume that right now it's not working on the MIPS based routers (but if someone would care to try on an N16 or AC66, it might be helpful).

Just an update....I've worked on the MIPS support over the last couple of days without any luck. I've opened an issue with the getdnsapi/stubby developers to see if they have any insight.

Also, @ColinTaylor, I met my personal challenge on doing the ordered servers Will put up a beta refresh for the AC56/AC68 in the next few days.