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.
- 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.
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.
What if, instead of 127.0.0.1, we put Cloudflare and Google's DNS services after unchecking "Use DNS servers advertised by peer"?
That would work too. Be aware the router's own DNS lookups to Cloudflare or Google would not be using DNS over TLS.
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
@AjkayAlan Based on the post from @open.nya please remove what is currently step 4:
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.
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).
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.
Ok thanks @jbrossard !
But now under "IPv4 Upstream" on the Overview page, I see 2 DNS addresses which are my ISP DNS.
This only happens when I keep this checked below. When "Use DNS servers advertised by peer" is un-checked I don't see my ISP DNS addresses
Also do I keep DNS weight = 0?
You should see your ISP's DNS servers. Keep DNS weight = 0.
If you followed the setup properly, the clients on your LAN will get DNS resolution through Stubby, while the router itself will use your ISP's DNS servers. This is necessary so the router will boot properly.
Ok thanks I understand now.
Is an alternative to add CloudFlare to WAN interface ? Like below
Thus if Stubby has issues with DoT, the backup is still CloudFlare ?
Yes, that will work, I do the same (I use Quad9 addresses).
