DNS-over-TLS causes 'Disconnected' on reboot

[blitzkrieg]

Hi all.
As per title, i'm on AC86U and 384.11_2.
Internet is somehow 'Disconnected' upon reboot if DoT is applied, doesn't matter Strict or Opportunistic. If DoT is applied after reboot, DNS queries resolves normally.
Is there any 'special' settings I'm missing? DNSSEC support is disabled by the way.

 

[bbunge]

Turn off Network Monitoring.

Sent from my SM-T380 using Tapatalk

 

[blitzkrieg]

Turn off Network Monitoring.

Sent from my SM-T380 using Tapatalk

Oh, it wasn't even checked to begin with. Or is there 'another' Net mon?

 

[martinr]

Anything change if on the WAN page you set to No, tge setting Connect to DNS Server automatically, and insert the same 2 DoT DNS server IP addresses into DNS Server 1 and Server 2?

 

[FTC]

Hi, this could be another instance of the 'No WAN' connected up on reboot that was caused by starting of services too early and before ntp synchronyzation. I say so because one of the possible reported bypasses was to make sure a 'fast enough' dns to be configured (probably related to faster achieved ntpd synchronization at boot), and I assume that using DoT somehow makes name resolution a bit more slow at boot. You can also check if openvpn is configured and try to reboot without it started. (may also fix the problem)... Optionally and to verify this is the problem you can wait around 20 minutes to see if WAN connection suddently gets established after boot.

If this is the case then know that MERLIN has coded a 'fix' (i.e delay at boot to let time for this synchronization) that I think is already implemented in 384.12 alpha 2, or if you do not want to run alpha code, then just apply some delay into the post_mount script before starting openvpn service.

 

[Kingp1n]

Hi all.
As per title, i'm on AC86U and 384.11_2.
Internet is somehow 'Disconnected' upon reboot if DoT is applied, doesn't matter Strict or Opportunistic. If DoT is applied after reboot, DNS queries resolves normally.
Is there any 'special' settings I'm missing? DNSSEC support is disabled by the way.

It may be that u have the WAN: Use local caching DNS server as system resolver default to 'No' option in Other Settings set to 'Yes'? Change it No and monitor.

 

[blitzkrieg]

Anything change if on the WAN page you set to No, tge setting Connect to DNS Server automatically, and insert the same 2 DoT DNS server IP addresses into DNS Server 1 and Server 2?

umm, it works for non-port443 DNS addresses, but for port 443 DNS' it'll spit out the same 'Disconnected'.
umm Maybe port 443 DNS' at fault here?

It may be that u have the WAN: Use local caching DNS server as system resolver default to 'No' option in Other Settings set to 'Yes'? Change it No and monitor.

It was already defaulted to 'Yes'..

Hi, this could be another instance of the 'No WAN' connected up on reboot that was caused by starting of services too early and before ntp synchronyzation. I say so because one of the possible reported bypasses was to make sure a 'fast enough' dns to be configured (probably related to faster achieved ntpd synchronization at boot), and I assume that using DoT somehow makes name resolution a bit more slow at boot. You can also check if openvpn is configured and try to reboot without it started. (may also fix the problem)... Optionally and to verify this is the problem you can wait around 20 minutes to see if WAN connection suddently gets established after boot.

If this is the case then know that MERLIN has coded a 'fix' (i.e delay at boot to let time for this synchronization) that I think is already implemented in 384.12 alpha 2, or if you do not want to run alpha code, then just apply some delay into the post_mount script before starting openvpn service.

Ahh ok this make sense. Guess i'll wait for the next 'fix' before enabling DoT then.

 

[dave14305]

It was already defaulted to 'Yes'..

Change it to No. That is the new default in the next version anyway. It allows your router to boot and start services without relying on DoT.

 

[blitzkrieg]

Change it to No. That is the new default in the next version anyway. It allows your router to boot and start services without relying on DoT.

Tried, nah still 'Disconnected' after reboot. Just noticed this only happens for port 443 DNS addresses.. doesn't matter Yes or No for 'WAN: Use local caching'

 

[martinr]

Tried, nah still 'Disconnected' after reboot. Just noticed this only happens for port 443 DNS addresses.. doesn't matter Yes or No for 'WAN: Use local caching'

Do you mean DNS lookups for HTTPS domains?

 

[dave14305]

Tried, nah still 'Disconnected' after reboot. Just noticed this only happens for port 443 DNS addresses.. doesn't matter Yes or No for 'WAN: Use local caching'

If you mean one of the few DoT resolvers using port 443, it shouldn't come into play if you've really set the "Wan: Use local caching" to No. Please post the content of your /etc/resolv.conf file from the router.

 

[Grisu]

... or if you do not want to run alpha code, then ...

you can use beta code released an hour ago

 

[miroco]

Maybe a fallback resolver could solve this problem? A resolver used only during the boot phase until the router manage to reach an NTP-server. Since cryptography (DoT) is dependent on accurate time and accurate time require a resolver. It sounds like a Catch 22.

 

[blitzkrieg]

Do you mean DNS lookups for HTTPS domains?

I meant port 443 DNS addresses:

If you mean one of the few DoT resolvers using port 443, it shouldn't come into play if you've really set the "Wan: Use local caching" to No. Please post the content of your /etc/resolv.conf file from the router.

and yep double checked it to No:

cat /etc/resolv.conf
nameserver 127.0.1.1

 

[dave14305]

I meant port 443 DNS addresses: View attachment 18132


and yep double checked it to No:
View attachment 18133

cat /etc/resolv.conf
nameserver 127.0.1.1

Ok, so that implies you have no “regular” WAN DNS servers configured (non-DoT). The router needs that setup.

 

[blitzkrieg]

Ok, so that implies you have no “regular” WAN DNS servers configured (non-DoT). The router needs that setup.

ahh. Now DoT works after reboot. So we do have to specify a 'regular' DNS under Wan DNS Settings.

 

[dave14305]

ahh. Now DoT works after reboot. So we do have to specify a 'regular' DNS under Wan DNS Settings.

I expect in your case if you had no WAN DNS servers setup, DoT/Stubby could not resolve the tls names associated with your chosen DoT servers because it points to WAN DNS (/tmp/resolv.conf) at that point since DoT is still initializing.

The router still needs old DNS during boot, so it has to point somewhere, even the ISP DNS via DHCP.