Solved DNS-over-TLS and chroot (NextDNS DOT issue)

[papypaprika]

Hi Merlin community,

I'm a longtime user of Merlin, initially on RT-AC66u, and now RT-AX86u running Merlin 386.3_2.

I'm trying to improve security of my setup and I'm since recently using DNS over TLS. I've opted for NextDNS, though I'm not using their cli client, I prefer to use manually their DNS addresses tied to my fixed IP address.

I have been using a chrooted debian on my router (based on instruction from hqt.ro) without any issue in the past (before using DoT).

I have now an issue getting my chrooted debian accessing internet when using DNS over TLS. A simple apt update says:

 "Err:1 http://deb.debian.org/debian stable InRelease. Temporary failure resolving 'deb.debian.org'"

I attach a screenshot of my Wan page setup, in case you see anything suspicious.

When not using DNS over TLS, I have no issue having my chrooted debian accessing internet.

Any ideas what could be the issue?

Note that:
LAN -> DNS servers are empty.
"Wan: Use local caching DNS server as system resolver (default: No)" on Tools -> Other settings is set to No.

Thank you for your help !!

 

[bbunge]

Plenty of reading out on the web about issues with NextDNS and DoT. Especially if you do not do things their way and use their clients. You may do just as well using NextDNS with DNSSEC enabled. Or dumping NextDNS for Quad9 or Cloudflare Secure. I am currently running Quad9 with DNSSEC on my router and a Pi-Hole (running just malware blocking lists). I am getting a bit better performance this way resolving hosts than running DoT on the router.
If you are interested you can run DoT (Stubby) as a front end to Pi-Hole. You can also enable Stubby to do DNSSEC on the Pi or Merlin.
As a final shot - DNS filtering is not what it is cracked up to be and can never be as secure as other means. IP based filtering is much better but almost impossible to implement on consumer grade routers.

 

[papypaprika]

Thank you @bbunge.

Will try another DoT provider.

As a temporary solution for those interested, a not so elegant solution is to copy /etc/resolv.conf to /opt/debian/etc/resolv.conf

 

[papypaprika]

I can confirm that changing the DoT DNS provider (to Quad9 here rather than NextDNS) solves my connectivity issue.

I renamed the title of the post in case the NextDNS team keeps an eye on this forum.

Thank you very much @bbunge for taking the time to answer and propose a solution.