Why DNS over TLS is so important, and if you are not using it you should be

[Smokey613]

IIRC he was trying to use NextDNS on the routers DoT platform. However, He soon discovered a brick wall. i.e. Nextdns secondary DNS servers are not friendly to round robin queries done by Stubby. You have to completely disable round robin queries with stubby in order to use NextDNS, otherwise queries to the secondary DNS servers will quickly reach ratelimits. NextDNS developers designed NextDNS to "promote" the DoH concept which is what their client uses. however they do provide subpar DoT servers.

That is correct, however I also had issues with Cloudflare, Quad9 and even Google. They all worked when first activated but over time DNS responses became very slow. I finally landed on the NextDNS client that uses DoH and so far it has been very reliable.

 

[SomeWhereOverTheRainBow]

That is correct, however I also had issues with Cloudflare, Quad9 and even Google. They all worked when first activated but over time DNS responses became very slow. I finally landed on the NextDNS client that uses DoH and so far it has been very reliable.

Stubby is a bit of a beast when it queries servers. It can sometimes become quickly ratelimited for example if you are using servers that enforce rate-limits (probably servers in certain countries for example).

 

[Toink]

I picked up an Asus GS-AX3000 (same HW as RT-AX58U) running stock Asus firmware 3.0.0.4.386.43588 as they are really a great value right now and heavily discounted. The stock firmware does not support DNS over TLS unfortunately. I hope @GNUton will support the GS-AX3000 as part of extending Merlin to even more deserving routers.

Back to Earth, it appears that Comcast is hijacking DNS queries and redirecting them to their own DNS servers. I know they do that when you have their Comcast gateway, but I am using my own cable modem and router. Really maddening and it is hard to believe this is legal. @RMerlin a shout out for you including Stubby! You are an IT guy, are you seeing other ISPs doing this too?

1) Test case 1 using Asus GS-AX3000 with stock firmware

DNS set to Google

View attachment 41581

Yet Comcast is able to hijack the DNS queries as they are unencrypted and redirect to their own servers:

View attachment 41582


2) Test case 2 my old RT-AX56U running Merlin and set up with DNS over TLS in WAN settings

A mix of Cloudfare and Quad9 (aka WoodyNet) like a good stew:

View attachment 41583

Comcast cannot penetrate the encrypted DNS over TLS.... We call DoT the Comcast neuterer:

View attachment 41584

Hi, @JWoo!

Did you still manually set up the WAN DNS settings to cloudfare's/Quad9's DNS when you activated the DNS-over-TLS settings? Or you left it at 'Auto'?

Thanks!

 

[bbunge]

Stubby is a bit of a beast when it queries servers. It can sometimes become quickly ratelimited for example if you are using servers that enforce rate-limits (probably servers in certain countries for example).

Not really as Stubby only passes what dnsmasq sends it. If you are getting rate limited it is the fault of dnsmasq not stubby.

 

[SomeWhereOverTheRainBow]

Not really as Stubby only passes what dnsmasq sends it. If you are getting rate limited it is the fault of dnsmasq not stubby.

No it is true it would be more likely from stubby with round robin and connection timeouts/shuts. I have seen stubby send out the same request obnoxiously. Dnsmasq is more likely to respond from its cache first if the answer already exists, then to throw out a massive amount requests in an effort to get a response.

 

[Elmer]

So, this thread got me to start looking at DNS in a bit more detail. I thought I was battened down with DNS over TLS and router as filter, but I had installed OpenVPN Cloud (openvpn.net). One of the DNS checkers (top10vpn) picked up the fact that I had a DNS server called MADEIT (MadeIT inc.), even though 'Accept DNS Configuration' was set to 'disabled' in the profile. Deleted the openvpn connection and I was back to cloudflare only. So I guess the moral of the story is, even if a site offers a "free" connection and sounds very legit, as does openvpn.net, there is still some sort of monetization going on. Sigh.

 

[iJorgen]

IIRC he was trying to use NextDNS on the routers DoT platform. However, He soon discovered a brick wall. i.e. Nextdns secondary DNS servers are not friendly to round robin queries done by Stubby. You have to completely disable round robin queries with stubby in order to use NextDNS, otherwise queries to the secondary DNS servers will quickly reach ratelimits. NextDNS developers designed NextDNS to "promote" the DoH concept which is what their client uses. however they do provide subpar DoT servers.

DoT on Asus routers has not been reliable for me. I use the NextDNS client and it works great.

Interesting thread... I switched the other way around from CLI to DoT with NextDNS recently. I have used NextDNS CLI for years, but a few weeks back it started to fail every 30 minutes. A few minutes past the hour/half hour lasting for maybe 30-60 seconds where no queries were resolved and dnsmasq flooded the systemlog with warnings. Very annoying...

Now I switched to DoT and it works without those issues. Will try do disable Round Robin as suggested to see if it makes any difference. The only thing I see is many DNS-retransmissions (Yellow dots below) when sniffing, but can't figure out why.

 

[ColinTaylor]

The only thing I see is many DNS-retransmissions (Yellow dots below) when sniffing, but can't figure out why.

To see a retransmission you'd have to have previously sent a TCP request (rather than the more normal DNS UDP) to the server, and for there to have been no response. The TCP timeout before retransmission is usually about 2 seconds but it depends on the circumstances. Using DNNSEC is often the reason for the query using TCP.

 

[SomeWhereOverTheRainBow]

To see a retransmission you'd have to have previously sent a TCP request (rather than the more normal DNS UDP) to the server, and for there to have been no response. The TCP timeout before retransmission is usually about 2 seconds but it depends on the circumstances. Using DNNSEC is often the reason for the query using TCP.

Great analysis. I definitely agree. These are some of the things I observed as well with wireshark.

@iJorgen
As ColinTaylor has indicated, and part of what I have been mentioning, the process is overall a sensitive process.

 

[iJorgen]

To see a retransmission you'd have to have previously sent a TCP request (rather than the more normal DNS UDP) to the server, and for there to have been no response. The TCP timeout before retransmission is usually about 2 seconds but it depends on the circumstances. Using DNNSEC is often the reason for the query using TCP.

All DNSsec settings are inactive in the router, since NextDNS say they perform the check on their side.

I took a better screenshot showing it's UDP traffic, but still a burst of 2-3 DNS-retransmissions within milliseconds. Strange...
It's not noticeable on daily use, but always curious why things happen. ;-)

 

[A Purohit]

I turned on DOT on my router yesterday. It seems to be running fine so far (setup to cloudflare 1 and 2 servers).

Is there a way to test and ensure it's really running as DOT? Is there a way to get timings and see how long it's taking to do these lookups (ie, to compare with non-DOT setups)?

 

[SomeWhereOverTheRainBow]

I turned on DOT on my router yesterday. It seems to be running fine so far (setup to cloudflare 1 and 2 servers).

Is there a way to test and ensure it's really running as DOT? Is there a way to get timings and see how long it's taking to do these lookups (ie, to compare with non-DOT setups)?

Running tcpdump package provided by entware is one way to test it is working.

 

[A Purohit]

Running tcpdump package provided by entware is one way to test it is working.

I was hoping to see a way that didn't require me to setup JFFS, entware, etc... nothing simpler available?

 

[SomeWhereOverTheRainBow]

I was hoping to see a way that didn't require me to setup JFFS, entware, etc... nothing simpler available?

Setup a doublenat where you can monitor the traffic in between. Or use cloudflares glorious help page.

1.1.1.1 â One of the Internetâs Fastest, Privacy-First DNS Resolver

âï¸âï¸ Browse a faster, more private internet.

1.1.1.1

 

[SomeWhereOverTheRainBow]

I was hoping to see a way that didn't require me to setup JFFS, entware, etc... nothing simpler available?

Here is my help thread for you to review.

https://www.snbforums.com/threads/dot-study-mbm-dot-study.57725/

Perhaps you will find it useful as well.

 

[A Purohit]

Awesome, the Cloudflare help page is perfect and says I'm running DOT:

Though it also seems to say I'm running DOH as well, which I did not configure...

Well, I'm going to leave it alone. I don't have time to tinker on this further, but it seems DOT is working well, so I wanted others to know that. I'm running this on an AC68U with 386.5_2 firmware.

 

[SomeWhereOverTheRainBow]

Awesome, the Cloudflare help page is perfect and says I'm running DOT:

View attachment 41706

Though it also seems to say I'm running DOH as well, which I did not configure...

Well, I'm going to leave it alone. I don't have time to tinker on this further, but it seems DOT is working well, so I wanted others to know that. I'm running this on an AC68U with 386.5_2 firmware.

Are you using adguardhome for DoT and DoH? I know it is possible to get this result if that is what you are doing.

 

[Tech9]

Cloudflare help page is perfect and says I'm running DOT

Yes, but only if you use Cloudflare servers.

 

[SomeWhereOverTheRainBow]

Yes, but only if you use Cloudflare servers.

I concur. The only true and best way to see DoT in action is with tcpdump and using Wireshark to examine queries from pcap files.

 

[A Purohit]

Ahh, that was the trick - I'm using Firefox which has DOH enabled by default, so that's why I was getting a DOH result.

If I switch to Chrome, I only see DOT enabled, as expected.

Good catch!