DNS over TLS breaks wireless but not LAN

[Hawker]

Just updated to 386.3_2 on a AC-88U from an 384 build - router was reset and memory cleared after (was not stable after update until I did this).
I have tried to enable DNS over TLS using CloudFair 1.1.1.1 on port 853.
The addresses are 1.1.1.1 and 1.0.0.1. TLS Host Name and SPKI Fingerprint are blank (Is this correct?).
Everything works fine to for the computers connected to the router via Ethernet. However my cell phone reports "connected without internet". When I disable this feature then the cell phone connects properly.

What am I doing wrong or is there a bug in this feature?
Is this any help?

https://developers.cloudflare.com/1.1.1.1/dns-over-tls

I would also like to use Level 3 as the 2ndary DNS 209.244.0.3 but unsure if it supports this.


Thanx Hawker

 

[dave14305]

The TLS Hostname needs to be cloudflare-dns.com, as you would get if you chose Cloudflare from the Address dropdown menu. 853 is unnecessary since it is the default port anyway.

 

[eibgrad]

On the face of it, this doesn't make sense. The wireless and wired users are all assigned to the same underlying bridge (br0). And DNSMasq doesn't have any way of distinguishing wireless from wired because of it. This is one of those cases where I say "reboot everything" and try again.

 

[bbunge]

I would leave Level3 out of your DNS picture. Use 1.1.1.1 and 1.0.0.1 for the DNS Server 1 and 2. Better yet use 1.1.1.2 and 1.0.0.2 as those anycast addresses filter malware domains. Also change the IP's in DoT from 1.1.1.1 to 1.1.1.2 and 1.0.0.1 to 1.0.0.2. Also enable DNS Filter to Router.

As for the phone it likely is using MAC randomizing and possibly DoH. Suggest turning off the MAC randomizing and DoH.

 

[Treadler]

Host name for the Cloudflare 1.0.0.2 & 1.1.1.2 is, security.cloudflare-dns.com.

 

[Hawker]

Partial update.
Thanx for all the hep.
I tried all the settings suggested here, and removed Level 3. It still worked on Ethernet but not my phone via wireless (Android Samsung S10+ if it matters).
I then saw this thread

DNS over TLS can't seem to verify

I can't seem to get verification that DNS-over-TLS works. I've followed the wiki, and these are my settings: However, both tenta.com and 1.1.1.1/help report that DNS-over-TLS is not working: What am I doing wrong?

www.snbforums.com

And noticed they had DNS-Over-TLS Profile set to Opportunistic and not strict. Changing that fixed the problem.
I don't understand what that is, seems I would want strict yes?

@bbunge changing Prevent Auto Client DOH didn't do anything. Not sure where the Mac randomizing setting is? Is this a phone thing or Merlin? Where?

 

[Treadler]

Partial update.
Thanx for all the hep.
I tried all the settings suggested here, and removed Level 3. It still worked on Ethernet but not my phone via wireless (Android Samsung S10+ if it matters).
I then saw this thread

DNS over TLS can't seem to verify

I can't seem to get verification that DNS-over-TLS works. I've followed the wiki, and these are my settings: However, both tenta.com and 1.1.1.1/help report that DNS-over-TLS is not working: What am I doing wrong?

www.snbforums.com

And noticed they had DNS-Over-TLS Profile set to Opportunistic and not strict. Changing that fixed the problem.
I don't understand what that is, seems I would want strict yes?

@bbunge changing Prevent Auto Client DOH didn't do anything. Not sure where the Mac randomizing setting is? Is this a phone thing or Merlin? Where?

As I understand it, ‘strict’ forces DoT use. ‘Opportunistic’ works when it feels like it.
I would suggest you should now be good to go without altering anything else…..

 

[eibgrad]

Something still doesn't add up here. As I said before, DNSMasq has no ability to distinguish wireless from wired. All requests are handled identically. If the wireless now works w/ that change to Opportunistic, then presumably it's falling back to Do53 (209.244.0.3), which defeats the purpose. But the idea that the wired is using DoT, but the wireless is forced back to Do53 makes no sense. Why would that be?? Wired or wireless, it's the same DNS queries.

P.S. Theoretically, it might be that *everything* is falling back to Do53. That's why I don't think Opportunistic is a satisfactory answer.

 

[dave14305]

And noticed they had DNS-Over-TLS Profile set to Opportunistic and not strict. Changing that fixed the problem.

Is your router getting proper time synced? Strict requires proper time to negotiate the TLS handshake.

Something still doesn't add up here. As I said before, DNSMasq has no ability to distinguish wireless from wired. All requests are handled identically. If the wireless now works w/ that change to Opportunistic, then presumably it's falling back to Do53 (209.244.0.3), which defeats the purpose. But the idea that the wired is using DoT, but the wireless is forced back to Do53 makes no sense. Why would that be?? Wired or wireless, it's the same DNS queries.

P.S. Theoretically, it might be that *everything* is falling back to Do53. That's why I don't think Opportunistic is a satisfactory answer.

Agreed. First need to establish if DoT is working at all. And if any other configs are in play (e.g Guest #1 on br1 or br2).

 

[eibgrad]

FYI. When you chose Strict, then Stubby (which is doing the actually DoT) only contains the TLS transport option in its config file. OTOH, if you choose Opportunistic, then it add the TCP and UDP transports as well (i.e., Do53), and (apparently) falls back to what's in Automatic or Custom DNS (specifically, /tmp/resolve.conf).

Stubby config file when Strict

admin@lab-merlin1:/tmp/etc# cat /etc/stubby/stubby.yml
resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 128
appdata_dir: "/var/lib/misc"
resolvconf: "/tmp/resolv.conf"
edns_client_subnet_private: 1
round_robin_upstreams: 1
idle_timeout: 9000
tls_connection_retries: 2
tls_backoff_time: 900
timeout: 3000
listen_addresses:
  - 127.0.1.1@53
upstream_recursive_servers:
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 1.0.0.1
    tls_auth_name: "cloudflare-dns.com"

Stubby config file when Opportunistic

admin@lab-merlin1:/tmp/etc# cat /etc/stubby/stubby.yml
resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
  - GETDNS_TRANSPORT_UDP
  - GETDNS_TRANSPORT_TCP
tls_authentication: GETDNS_AUTHENTICATION_NONE
tls_query_padding_blocksize: 128
appdata_dir: "/var/lib/misc"
resolvconf: "/tmp/resolv.conf"
edns_client_subnet_private: 1
round_robin_upstreams: 1
idle_timeout: 9000
tls_connection_retries: 2
tls_backoff_time: 900
timeout: 3000
listen_addresses:
  - 127.0.1.1@53
upstream_recursive_servers:
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 1.0.0.1
    tls_auth_name: "cloudflare-dns.com"

And DNSMasq is redirecting *all* queries, wired or wireless, to the Stubby local process (127.0.1.1) on port 53.

admin@lab-merlin1:/tmp/etc# cat /tmp/resolv.dnsmasq
server=127.0.1.1

 

[Hawker]

Something still doesn't add up here. As I said before, DNSMasq has no ability to distinguish wireless from wired. All requests are handled identically. If the wireless now works w/ that change to Opportunistic, then presumably it's falling back to Do53 (209.244.0.3), which defeats the purpose. But the idea that the wired is using DoT, but the wireless is forced back to Do53 makes no sense. Why would that be?? Wired or wireless, it's the same DNS queries.

P.S. Theoretically, it might be that *everything* is falling back to Do53. That's why I don't think Opportunistic is a satisfactory answer.

Everything here is my concerns as well. WTF would wired work and wireless doesn't because your understanding matching my, admittedly limited, understanding.
It feels like Opportunistic is asking for it to not really be working.
I had guessed that before the wired was getting DNS Level 3 direct - no TLS and Wireless was Cloud fare and hence the problem. But now that both are cloudfair that can't be the issue.

Using the thread I linked, I was able to get the same verified results at that poster in that when I disabled Dnssec 1.1.1.1 verified correctly. But I don't really understand what disabling Dnssec or why I know then it works enabled.

Not sure the best way to "establish if DoT is working at all".
I had already disabled VPN, Guest and AiMesh networks as a trouble shooting with no change. I'm not really doing much fancy so no clue what setting it could be. Clealry a previous person had the same issue, which makes me wonder if DNS over TLS even works at all or if I just don't have it configured correctly.

There also seems to be some debate on if host name should be security.cloudflare-dns.com or cloudflare-dns.com
I guess I need to try that when I have time to look into this more.

I don't really have the understanding to get your further posts or what you are implying. My background is an Electronics Engineer, not computers and I don't speak Linux and barely know C. Could use a translator ;-) so I'm a bit out of my comfort/understanding zone here.
Anything else I should try?

Here is a new screenshot.

Totally unrelated but there seems to be a bug in the Merlin pull down menu. Those pull downs work in Firefox but not in Seamonkey, which is still a Geko engine. Very annoying to have to chance browsers to configure the router.

 

[netware5]

It is not correct to say "working on LAN, but not working on wireless" based only on mobile phone experience. To make such statement you should test with wireless connected laptop for example. Most probably the issue rests with the mobile phone. It could be an Android or mobile phone vendor's issue.

 

[bluepoint]

Everything here is my concerns as well. WTF would wired work and wireless doesn't because your understanding matching my, admittedly limited, understanding.
It feels like Opportunistic is asking for it to not really be working.
I had guessed that before the wired was getting DNS Level 3 direct - no TLS and Wireless was Cloud fare and hence the problem. But now that both are cloudfair that can't be the issue.

Using the thread I linked, I was able to get the same verified results at that poster in that when I disabled Dnssec 1.1.1.1 verified correctly. But I don't really understand what disabling Dnssec or why I know then it works enabled.

Not sure the best way to "establish if DoT is working at all".
I had already disabled VPN, Guest and AiMesh networks as a trouble shooting with no change. I'm not really doing much fancy so no clue what setting it could be. Clealry a previous person had the same issue, which makes me wonder if DNS over TLS even works at all or if I just don't have it configured correctly.

There also seems to be some debate on if host name should be security.cloudflare-dns.com or cloudflare-dns.com
I guess I need to try that when I have time to look into this more.

I don't really have the understanding to get your further posts or what you are implying. My background is an Electronics Engineer, not computers and I don't speak Linux and barely know C. Could use a translator ;-) so I'm a bit out of my comfort/understanding zone here.
Anything else I should try?

Here is a new screenshot.

Totally unrelated but there seems to be a bug in the Merlin pull down menu. Those pull downs work in Firefox but not in Seamonkey, which is still a Geko engine. Very annoying to have to chance browsers to configure the router.

Follow @dave14305 suggestion not to input the TLS port(853) when adding the DOT servers but only the Address and TLS Hostname. Stubby assigns the port automatically.

 

[Hawker]

Ok so back to the drawing board but I think this time I'm fully resolved.
I tried a few wireless devices, some had issues others did not. Still not sure why. It always worked wired.

I also tried every combination of 1.0.0.1 & 1.1.1.1 / 1.0.0.2 & 1.1.1.2 security.cloudflare-dns.com / cloudflare-dns.com with and without the 853 in the port. All with Strict turned on.
The only thing that worked for all devices was 1.0.0.1 & 1.1.1.1 with cloudflare-dns.com and 853 entered. If 853 was not entered it did not work.
I was unable to get 1.0.0.2 & 1.1.1.2 with security.cloudflare-dns.com to work even with 853 entered.

After more startpage searches (no google in this house) I found many others had also found that the 1.1.1.1 "regular" worked but not the 1.1.1.2 / security so at this point I gave up on that and I'm feeling better since strict is enabled and it works on all my devices.

Thanx for all your help.
Not everything spoken made sense the first read but the more I got into this the more I understood.

 

[bbunge]

Ok so back to the drawing board but I think this time I'm fully resolved.
I tried a few wireless devices, some had issues others did not. Still not sure why. It always worked wired.

I also tried every combination of 1.0.0.1 & 1.1.1.1 / 1.0.0.2 & 1.1.1.2 security.cloudflare-dns.com / cloudflare-dns.com with and without the 853 in the port. All with Strict turned on.
The only thing that worked for all devices was 1.0.0.1 & 1.1.1.1 with cloudflare-dns.com and 853 entered. If 853 was not entered it did not work.
I was unable to get 1.0.0.2 & 1.1.1.2 with security.cloudflare-dns.com to work even with 853 entered.

After more startpage searches (no google in this house) I found many others had also found that the 1.1.1.1 "regular" worked but not the 1.1.1.2 / security so at this point I gave up on that and I'm feeling better since strict is enabled and it works on all my devices.

Thanx for all your help.
Not everything spoken made sense the first read but the more I got into this the more I understood.

Interesting. I ran Cloudflare Secure 1.1.1.2/1.0.0.2 with security.cloudflare-dns.com and cloudflare-dns.com. Both worked.
If you want to see what Stubby is doing open a terminal to your router and enter stubby -l You will see it connecting to the upstream resolvers or not. And it will alternate between your resolver choices. Use Ctrl+c to cancel the view.
I have had some concern about running DNSSEC in Dnsmasq as Stubby can also do DNSSEC validation. But I have finally come to the understanding that the way Merlin has it set up makes it easier to run just DNSSEC without DoT which is what I am doing now to Quad9. The Quad9 anycast resolvers are 10 times farther away from me than Cloudflare. And I'm not all that convinced that Cloudflare Secure is doing as good a job filtering malware than Quad9. And my performance resolving addresses is a bit quicker now.
If you do a search on DoT and Stubby in this forum you can see the testing effort some of us did and the discoveries made to get DoT to work on Asus routers. In the beginning it was an Entware add on! Some fun!!!

 

[shauno100]

I am not sure DoT is even working properly, I have CloudFlare 1.1.1.1 and 1.0.0.1 (cloudflare-dns.com) in my TLS server list but when I go to https://tenta.com/test/?utm_source=blog it shows that TLS is disabled.

It would appear an SPKI fingerprint is required for this to properly encrypt the DNS queries but CloudFlare don't provide the fingerprint from what I can see.

Is anybody able to shed light on this please? And also has anyone tested their DNS over TLS at the above website I mentioned? Curious to see what results others get.

 

[Treadler]

I am not sure DoT is even working properly, I have CloudFlare 1.1.1.1 and 1.0.0.1 (cloudflare-dns.com) in my TLS server list but when I go to https://tenta.com/test/?utm_source=blog it shows that TLS is disabled.

It would appear an SPKI fingerprint is required for this to properly encrypt the DNS queries but CloudFlare don't provide the fingerprint from what I can see.

Is anybody able to shed light on this please? And also has anyone tested their DNS over TLS at the above website I mentioned? Curious to see what results others get.

Interesting.

I’m using Quad9 ipv4 & IPv6 DoT, the Tenta test says TLS enabled = false.

When I ssh into the router & “stubby -l”, it indicates I am using DoT.

Go figure……..

 

[shauno100]

Interesting.

I’m using Quad9 ipv4 & IPv6 DoT, the Tenta test says TLS enabled = false.

When I ssh into the router & “stubby -l”, it indicates I am using DoT.

Go figure……..

Yeah it's weird, i tried the below code via SSH which i found online to try and get the SPKI for Cloudflare and it worked, i then set the SPKI fingerprint in AsusWRT Merlin GUI and DNS is still working but the tenta site still says "TLS Disabled", so it's either incorrect info from the website or this isn't working properly. I also tried the below code against Quad9 9.9.9.9 and got the SPKI but setting it broke the DNS.

echo | openssl s_client -connect 1.1.1.1:853 2>/dev/null | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64

 

[Treadler]

Yeah it's weird, i tried the below code via SSH which i found online to try and get the SPKI for Cloudflare and it worked, i then set the SPKI fingerprint in AsusWRT Merlin GUI and DNS is still working but the tenta site still says "TLS Disabled", so it's either incorrect info from the website or this isn't working properly. I also tried the below code against Quad9 9.9.9.9 and got the SPKI but setting it broke the DNS.

echo | openssl s_client -connect 1.1.1.1:853 2>/dev/null | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64

IMHO, ignore the Tenta info.