Home > Uncategorized > DNS Over TLS on OpenWrt 18.06

DNS Over TLS on OpenWrt 18.06

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, 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 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.

  1. Refresh the package list: opkg update
  2. Install the stubby package: opkg install stubby
  3. Start stubby: /etc/init.d/stubby start
  4. Set stubby to start automatically at boot: /etc/init.d/stubby enable
  5. Use stubby as the DNS server by editing /etc/config/dhcp
    In the config dnsmasq section, add (or change the values of, if these settings already exist) these settings:

    • option noresolv '1'
    • list server ''
  6. 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, edit /etc/stubby/stubby.yml.

Now you can restart assured that your DNS queries can’t be seen by 3rd parties.

CC BY-SA 4.0 DNS Over TLS on OpenWrt 18.06 by Craig Andrews is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Categories: Uncategorized Tags:
  1. September 25th, 2018 at 04:47 | #1
    In OpenWRT 18.06.1, the default configuration file is /etc/stubby/stubby.yml
  2. October 26th, 2018 at 16:21 | #3
    When useing openwrt-adblock with “DNS Backend”: dnsmasq, does it (adblock) remain functional?
    • October 30th, 2018 at 14:30 | #4
      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?
  3. October 31st, 2018 at 14:05 | #5
    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.

  4. Mark
    February 11th, 2019 at 21:24 | #6
    option noresolv ‘1’ is tje culprit

    Change to option noresolv ‘0’

    • February 13th, 2019 at 12:21 | #7
      According to https://openwrt.org/docs/guide-user/base-system/dns_configuration

      noresolv boolean 0 -R Don’t read upstream servers from /etc/resolv.conf

      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”

  5. Mark Visitante
    February 11th, 2019 at 23:53 | #8
    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 (


  6. February 28th, 2019 at 23:26 | #10
    Thanks Craig, this worked perfectly.

    I added the following to /etc/config/dhcp

    option noresolv ‘1’
    option proxydnssec ‘1’
    list server ‘’

  7. March 15th, 2019 at 21:34 | #11
    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.
    • March 18th, 2019 at 09:43 | #12
      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.
  8. JAMES
    April 25th, 2019 at 10:35 | #13
    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?

  9. JAMES
    April 25th, 2019 at 10:45 | #14
    Ah, I needed to set option proxydnssec ‘1’ as mentioned in the comments. Dig now works on the router with option noresolv ‘1’
  10. JAMES
    April 25th, 2019 at 14:13 | #15
    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.

  11. JAMES
    April 25th, 2019 at 15:21 | #16
    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

    uci set network.wan.peerdns=’0′
    uci set network.wan.dns=’′
    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.

  12. Dan
    June 14th, 2019 at 12:21 | #17
    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!
  13. Hamish M
    July 17th, 2019 at 01:17 | #18
    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.

  1. August 10th, 2018 at 11:46 | #1