DNS over TLS encrypts DNS queries so no one between you and the DNS server you’re using (which, by default using these steps, will be Cloudflare’s 1.1.1.1), can tell what DNS queries/responses are being exchanged.
DNS over TLS provides confidentiality but not integrity or authenticity. For those, you need to setup DNSSEC which I’ve described how to do on OpenWrt in another post.
By setting up DNS over TLS on your OpenWrt router, you protect your entire network as all clients will perform DNS requests using your OpenWrt router’s DNS server which in turn will use DNS over TLS to perform the actual resolution.
Setting up DNS over TLS using Stubby on OpenWrt 18.06 and 19.07 is remarkably easy. You can use the LuCI web interface to perform these steps or shell command over ssh; I’m providing the commands here.
- Refresh the package list:
opkg update - Install the
stubbypackage:opkg install stubby - Start stubby:
/etc/init.d/stubby start - Set stubby to start automatically at boot:
/etc/init.d/stubby enable - Use stubby as the DNS server by editing
/etc/config/dhcp
In theconfig dnsmasqsection, add (or change the values of, if these settings already exist) these settings:option noresolv '1'list server '127.0.0.1#5453'
- Restart dnsmasq so the changes take effect:
/etc/init.d/dnsmasq restart
If you’d rather use a different DNS over TLS server than Cloudflare’s 1.1.1.1, edit /etc/stubby/stubby.yml.
Now you can restart assured that your DNS queries can’t be seen by 3rd parties.
DNS Over TLS on OpenWrt 18.06, 19.07, and 21.01 by Craig Andrews is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
In OpenWRT 18.06.1, the default configuration file is /etc/stubby/stubby.yml
Thanks for that – I’ve updated the text accordingly.
Question:
When useing openwrt-adblock with “DNS Backend”: dnsmasq, does it (adblock) remain functional?
I believe so – I don’t see why it wouldn’t. However, I don’t use that approach so I can’t say for sure. If you do, can you report back with the results?
Thanks for the very useful info, Craig.
I’m not a networking genius, but I’ve successfully installed stubby on several standalone workstations, but when I try to (follow all the instructions here, and) restart dnsmasq, I get:
udhcpc: started, v1.28.3
udhcpc: sending discover
udhcpc: no lease, failing
… and the router fails to offer any working connections to hosts. Any hints on where I might have gone wrong?
Thanks again.
option noresolv ‘1’ is tje culprit
Change to option noresolv ‘0’
According to https://openwrt.org/docs/guide-user/base-system/dns_configuration
We do not want to read upstream servers from /etc/resolv.conf – that’s the whole point of this article. We want to use the explicitly configured upstream server specified in “list server” and that only happens if you use “option noresolv 1”
If you have stubby,yml correct:
In /etc/config/dhcp:
option noresolv ‘1’
option proxydnssec ‘1’
The noresolve ‘1’ stops dnsmasq from resolving dns queries from local clients.
Change t to noresolv ‘0’ to make dns resolving work again.
The proxydnssec ‘1’ allows dnsmasq to proxy the dnssec from stubby to the clients since stubby only resolves dns internally to the router itself (127.0.0.1).
Source:
https://github.com/openwrt/packages/blob/master/net/stubby/files/README.md
Your description of noresolv is incorrect. It stops the use of upstream, DHCP provided DNS servers specified in /etc/resolv.conf – and that’s exactly what we want to do. “option noresolv 1” is correct. See https://openwrt.org/docs/guide-user/base-system/dns_configuration and this is also mentioned in https://github.com/openwrt/packages/blob/master/net/stubby/files/README.md
Setting proxydnssec ‘1’ is an alternative to having dnsmasq perform dnssec validation which is the approach I recommend. See https://candrews.integralblue.com/2018/08/dnssec-on-openwrt-18-06/
Thanks Craig, this worked perfectly.
I added the following to /etc/config/dhcp
option noresolv ‘1’
option proxydnssec ‘1’
list server ‘127.0.0.1#5453’
Is there any reason this would break port forwarding? I am having a very strange issue. Some ports forward but 80 and 443 do not.
I can’t imagine why DNS settings would impact port forwarding. Furthermore, I’m using this setup on my router and have many port forwards other than 80 and 443 working.
Using this setup Dynamic DNS stops working on the router itself. The issue is drill no longer works on the router:
Error: error sending query: No (valid) nameservers defined in the resolver
I’m able to get around this by setting option “noresolve” back to “0”
Is there a better way to get DDNS working?
@JAMES
Ah, I needed to set option proxydnssec ‘1’ as mentioned in the comments. Dig now works on the router with option noresolv ‘1’
@JAMES
After a reboot I found that DDNS doesn’t work again.
I’m leaving it with “option noresolv ‘0’” as this is the only way I can get DDNS to work, and since /etc/resolv.conf only contains the loopback address I don’t see how this is an issue anyway.
I’m sorry for all of the posts. But I found the problem. For the router to be able to perform DNS lookups itself you have to follow all of the steps in the section “Disable sending DNS requests to ISP provided DNS servers” in https://github.com/openwrt/packages/blob/master/net/stubby/files/README.md
tl;dr
uci set network.wan.peerdns=’0′
uci set network.wan.dns=’127.0.0.1′
uci set network.wan6.peerdns=’0′
uci set network.wan6.dns=’0::1′
uci commit && reload_config
If I do that, I can have “option noresolv ‘1’”, and DDNS works, as the router can use drill to do lookups.
This guide was a HUGE help! THANK YOU. I recently installed OpenWRT on my Linksys AC2600 and had no luck following the directions of many other articles explaining how to set cloudflare as the DNS. My networking skills are not very sophisticated, but a few google searches on SSH commands and this article did the trick. Thanks again!
I found that Stubby didn’t start working for a couple of minutes after boot until the kernel eventually outputs “random: crng init done”.
I installed the haveged package which speeds up the crng init, and then Stubby is working after a couple of seconds.
Nice Work
I found I needed to add the below before it would work properly with Openwrt OpenWrt 19.07.4
opkg install ca-certificates
That’s not necessary;
stubbydepends onca-certificatesso if you installstubby, you’ll haveca-certificates.See https://github.com/openwrt/packages/blob/567a378dc1a1c4400e1aab69054925fa22b3bc68/net/stubby/Makefile#L38
Hi!
First things first: Thank you for this guide. It helped a lot on learning about OpenWRT and it worked like a charm.
But, as my network knowledge is not so great, I have a question about the modification of the /etc/config/dhcp file in the section config dnsmasq: where you type list server ‘127.0.0.1#5453’… shouldn’t we also add an entry for the ip6 server like list server ‘0::1#5453’ ? Or am I just saying nonsense?
Thank you again.
Ben
You definitely could, but it really doesn’t matter in practice.
127.0.0.1 is always going to be available and work, and always do the same thing as ::1.