[Tutorial] [No CLI] Configuring DNS over TLS with LuCI using Stubby and Dnsmasq

Thanks for tutorial ) one question, I'm getting this on cloudflare test page: "We weren’t able to detect whether you were using a DNS resolver over secure transport. Contact your DNS provider or try using 1.1.1.1 for fast & secure DNS."
Only once it worked, even 1.1.1.1/help worked, but after router reboot 1.1.1.1/help says "no" everywhere

excellent tutorial. it worked on my first try. i just tweak
tls_min_version: GETDNS_TLS1_3
and delete
tls_max_version

Thanks, it's working!!
Btw i still get orange status on DNSSEC at https://www.cloudflare.com/ssl/encrypted-sni/

I actually tried the wiki instructions and it actually caused my DNS to not work anymore, however when I tried the ones listed here it worked perfectly

Esni support is browser issue

https://tools.ietf.org/html/draft-ietf-tls-esni-07

Strange issue here, my Roomba will not connect to the cloud when using DNS over TLS with Stubby and dnsmasq. It works fine when I set my dns back from stubby to 8.8.8.8 or 1.1.1.1
I've tried with Adblock completely disabled as well.
It also works fine with DNS over TLS when I'm using unbind instead of following this tutorial. I have other issues with that configuration that seem more daunting to resolve at the moment, hence wanting to stick with dnsmasq and stubby.
Has anyone else seen this issue or have any idea how to fix it?

had a similar issue with an iot device, use tcpdump against your roomba to find what domain is trying to resolve/connect to and add it to /etc/config/dhcp at the end of

config dnsmasq
   ...
   ...
   list server /roombadoamin.com/1.1.1.1

or 8.8.8.8 as you prefer. after some time it started working again without this, provider o manufacturer fault? just guessing. maybe this should be splitted in a new topic.

1 Like

Thank you! That solved my problem right away.

For anyone else having this issue, the offending domain entry wound up being:

/a2uowfjvhio0fa.iot.us-east-1.amazonaws.com/1.1.1.1

And since we're in a [No CLI] thread, you can add this entry from LuCI at the end of Step 6:
Under Network -> DHCP and DNS, click the "General Settings" tab, add to the end of "DNS forwardings" list.

  1. Go to Network -> Interfaces. Click the edit button for WAN, go to advanced settings, and uncheck "Use DNS servers advertised by peer" and in "Use custom DNS servers" set it to 127.0.0.1. Then press Save & Apply. Repeat this same step for the WAN6 interface, using 0::1 instead of 127.0.0.1.

Is this step needed? I setup my custom DNS servers to Cloudflare and Google, and then followed this guide, which doesn't change the custom DNS servers on the Network -> Interfaces tab, yet I still show as using secure DNS and DNSSEC.

2 Likes

That step is in reality a really bad idea. OpenWrt needs access to DNS while booting up, and setting it to use Stubby, which may not be up and running yet, will result in random weird issues when booting.

I had terrible weird issues (no Internet access, no DNS, etc.) until I changed the custom DNS servers back to Quad9, at which point the router booted up perfectly every time. The ONLY downside is the DNS traffic from the router itself is not DNS over TLS, and I couldn't care less. I'm happy that my network clients are using DNS over TLS.

3 Likes

What if, instead of 127.0.0.1, we put Cloudflare and Google's DNS services after unchecking "Use DNS servers advertised by peer"?

2 Likes

That would work too. Be aware the router's own DNS lookups to Cloudflare or Google would not be using DNS over TLS.

2 Likes

You are absolutely right.

It is not possible for Stubby to be UP during boot or just right after boot because of the race condition with SYSNTPd service.
Clock on device should be synced via NTP for Stubby to be able to establish SSL/TLS connection to the upstream DNS provider.

Blocking internet connectivity at boot time by directing WAN DNS to unfunctional local DNS service leads device to inability to perform NTP sync and thus to inability for DNS/Stubby to function properly too.

In absence of correct time on device it is not possible to verify SSL/TLS certificate chain during handshake to upstream DNS provider (some certificates may be 'not yet valid' etc).

For further details take a look at https://openwrt.org/docs/guide-user/base-system/dhcp_configuration#race_conditions_with_sysntpd

2 Likes

@AjkayAlan Based on the post from @open.nya please remove what is currently step 4:

  1. Go to Network -> Interfaces. Click the edit button for WAN, go to advanced settings, and uncheck "Use DNS servers advertised by peer" and in "Use custom DNS servers" set it to 127.0.0.1. Then press Save & Apply. Repeat this same step for the WAN6 interface, using 0::1 instead of 127.0.0.1.

I can verify this step causes lots of grief. That configuration step has also been removed from https://candrews.integralblue.com/2018/08/dns-over-tls-on-openwrt-18-06/

Thanks again @open.nya, @jbrossard, and @thekiefs - I have updated the post to remove the step based on your feedback.

3 Likes

Hi, i follow your configuration to set up DNS over TLS. I have some trouble with put a check mark next to "Ignore resolve file".

if i do that i loose resolution for local hostname.
do you face with this issue ?

regards

[EDIT]
after reboot and running the following command

/etc/init.d/stubby enable
/etc/init.d/stubby start
/etc/init.d/dnsmasq restart

every seems to be fine (even with the check mark next to "Ignore resolve" file).

1 Like

Note that when NTP has not had opportunity to be set correctly, such that TLS fails, then the correct fix is to set stubby to be using opportunistic TLS mode - see: https://dnsprivacy.org/wiki/display/DP/Configuring+Stubby#ConfiguringStubby-OpportunisticDoTtoyourlocalresolver

config stubby 'global'
       option manual '0'
       option trigger 'wan'
       # option triggerdelay '2'
       list dns_transport 'GETDNS_TRANSPORT_TLS'
       list dns_transport 'GETDNS_TRANSPORT_UDP'
       list dns_transport 'GETDNS_TRANSPORT_TCP'
       option tls_authentication '0'
...

With this configuration, DNS will work with the specified servers over TCP/UDP until NTP is correctly set, at which point it will then use TLS.

Full Configuration please

Does anyone know if turning this on disables the unifi statistics listed for the Ubiquiti switch/AP system?