What's new

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

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
Beta has been refreshed to 34B5 for the AC56 and AC68....
Code:
7cc8d15b8 (HEAD -> 374.43_2-update) Version and Documentation to 34B5j9527
a590665f6 stubby: services - set correct permissions on stubby.yml
222992971 stubby: services - clean up yml file formatting
bb29fd1cf dnsmasq: (upstream) fix crash parsing a --synth-domain with no prefix
1329e4b47 Version and Documentation to 34B4j9527
41afb1a9f stubby: do not listen on ipv6 if not enabled
e97da20e5 stubby: change default padding blocksize
cc0a2c2bd stubby: add support for ordered vs roundrobin server access
ba8bdde67 webui: add gui support for stubby_noipv6
83ce63603 Version and Documentation to 34B2j9527
f02d5ce26 dnsmasq: add server name to insecure DS syslog
8f348d3a1 stubby: add nvram only option for stubby_noipv6
1917776f5 updown: properly initialize vars for dns proxy status
 
Last edited:
Thanks John. Everything working as expected.

Side note: While testing the new firmware I noticed that a) all DNS requests across my ISP's network were much slower compared to 4 days ago (33ms vs. 23ms), and b) response times from cloudflare's servers were significantly slower than before (47ms vs. 24ms). The times were consistent over multiple tests. Go figure. :rolleyes: This has nothing to do with the firmware as I went back to an earlier version and the results were the same.
 
Loaded the beta refresh yesterday on my AC68
Normally stay away from betas but couldn't resist.

Using DoT with ipv6 ordered server list.

Cloudflare DNS latency at my location as good as ISP DNS

DoT Order 1.1.1.1 ,1.0.0.1, 9.9.9.9 Hopefully Quad 9 never needed

Using namebench, DoT uncached Query with Cloudflare minimal performance difference vs standard DNS Query

Great work, hope you can get it working on the MIPS routers!
 
John, I deduced today that stubby must have switched over to my secondary DNS server because it was giving slower responses. I had a look in the syslog to see if there were any messages about this but unsurprisingly there weren't.

So I thought I'd increase stubby's logging level to 7, which I'd previously used interactively. I didn't want to have to leave a terminal open all the time so I set stubby_log=7 and restarted it. Looking at the output of ps I can see that the log level is set to 7 but I can't see anything in the syslog or under /var/tmp/stubby.

Does the logging actually work or am I just looking in the wrong place? Maybe stdout need to be redirected when stubby is running in background.
 
Does the logging actually work or am I just looking in the wrong place? Maybe stdout need to be redirected when stubby is running in background.
Yes, right now everything just goes to stdout/stderr. For right now, you can stop and manually restart stubby in the background with the redirect.
 
@john9527, thank you for your efforts on implementing DNS privacy with DNS over TLS. I have been researching the topic more in depth the past several months. Unfortunately, the solutions are not ready for most end users at this time due to the technical acumen required to implement, but I expect they will get there eventually. I am very grateful for your efforts.

For others who may want to learn more about the lack of security with DNS, see https://dnsprivacy.org/wiki/
 
Just installed 34B5 on RT-AC66U_b1 and all seems well. I'm running DoT with Cloudflare and "" Alt and DDNS with custom script.

So far, pretty sweet.
 
Last edited:
YAHOO! After spending more time that I would like to admit, I finally tracked down why stubby was failing on the MIPS builds!
Time for a celebration shot or two of Palinka :D

Have a bit of extra checking to do....expect a new beta that will cover MIPS in a day or two.

Sending this from my N66R....
Code:
admin@RT-N66R-2628:/tmp/home/root# ps | grep stubby | grep -v grep
  862 admin     4448 S    stubby -g -v 5 -C /etc/stubby.yml 2>/var/tmp/stubby/stubby.log

And the test..

DoT-MIPS.png
 
QoS

Just a quick warning about something that caught me out. I noticed that I was getting DNS timeouts while browsing whenever my wife was using Netflix. I've never had DNS timeouts before.

This morning "the penny dropped" and I realised that one my QoS rules was now no longer correct since I was using DoT. DNS should have been getting the Highest priority, but as DoT doesn't use port 53 it was defaulting to Low priority (which was below HTTP/S streaming).

Obvious when you think about it :rolleyes:. Anyway, here's my updated QoS rule.

Untitled.png
 
Beta has been refreshed to 34B6 for all fork supported routers, including the MIPS based N16, AC66 and N66!
Code:
a2dc6a385 (HEAD -> 374.43_2-update) Version and Documentation to 34B6j9527
0ce7ee1f3 webui: clean up wan dns display elements
8638fcc02 stubby: work around broken getaddrinfo on MIPS
b080dd0ac stubby: add debug error messages
a90f946fe stubby: services - redirect stderr to var/tmp/stubby/stubby.log
756ca825a make: build getdns with static libraries
 
but as DoT doesn't use port 53 it was defaulting to Low priority (which was below HTTP/S streaming).
Hmmm....thinking ahead. When DoH takes hold on port 443, then what are we going to do?
Probably going to have to define multiple rules with transfer size limits.

BTW....Great piece of deductive reasoning on this one!
 
Last edited:
Probably going to have to define multiple rules with transfer size limits.
That would seem the only choice. Might have to do some analysis to understand what the typical packets sizes and stream lengths (if any) are. I know a DoH "transaction" can be multiple kilobytes in size, but I have no idea whether that's typical or not. Maybe a question for the people promoting DoH.

EDIT: Or.... create a QoS rule that's based on the destination IP address rather than port number.
 
Beta has been refreshed to 34B6 for all fork supported routers, including the MIPS based N16, AC66 and N66!
Code:
a2dc6a385 (HEAD -> 374.43_2-update) Version and Documentation to 34B6j9527
0ce7ee1f3 webui: clean up wan dns display elements
8638fcc02 stubby: work around broken getaddrinfo on MIPS
b080dd0ac stubby: add debug error messages
a90f946fe stubby: services - redirect stderr to var/tmp/stubby/stubby.log
756ca825a make: build getdns with static libraries
I upgraded to the B6 from the B5 without doing a factory reset and now my wireless clients don't show in the network map, but they do show in the log and they are connected.

I don't mind, but I thought people will like to know.
 
Last edited:
I upgraded to the B6 from the B5 and now my wireless clients don't show in the network map, but they do show in the log and they are connected.
Nothing changed that would affect networkmap and working fine here. Did you give it enough time? It can take up to 5 minutes after boot for it to populate.
 
Nothing changed that would affect networkmap and working fine here. Did you give it enough time? It can take up to 5 minutes after boot for it to populate.
It has been about 15 minutes and they still don't show.
 
Nothing changed that would affect networkmap and working fine here. Did you give it enough time? It can take up to 5 minutes after boot for it to populate.
Should I have done a factory reset?
 
Status
Not open for further replies.

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!

Members online

Top