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

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/

1 Like

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?

I know it's a bit late but in case anybody is still interested, I had the same problem after each reboot i.e., no internet because no DNS just like @jbrossard said, stubby's status after reboot says active with no instances, so I restarted stubby and voila internet is working again. In order to make this work without logging in and restarting stubby is to write a simple procd init script and enable it at startup and give it a S95 priority.

Also, I had to write a firewall rule to intercept all port 53 request using the same rule described here --> [https://openwrt.org/docs/guide-user/firewall/fw3_configurations/intercept_dns](https://DNS Hijacking) in order to get a Yes in DNS over TLS in 1.1.1.1/help.

That is very helpful.

Hi all

I have set up DoT but under the WAN settings page noticed "Use DNS servers advertised by peer" was still checked.

I have now un-checked. Is that correct?

I have tested 1.1.1.1/help and DoT is working but I just wanted to clean up this page

Also i don't see 0::1#5453 and 127.0.0.1#5453 mentioned anywhere on CloudFlare's website - how do these addresses make it go through CloudFlare DoT ?

It goes through a 3rd party first ?

That is incorrect, you will find the unit will occasionally fail to come up properly on boot.

1 Like