DNS over TLS with Dnsmasq and Stubby fails

Dear community

I followed the instructions on DoT with Dnsmasq and Stubby which seems to be updated on 2023/03/14, however all DNS queries fail to be resolved. I believe stubby is the issue but I am asking for your help in troubleshooting. Version of OpenWRT is 23.05.0-rc2 (I do understand that this is not considered yet stable, but was hoping we can forego this detail).

I followed the troubleshooting step of restarting all services and rebooting, but that didn't solve the issue
logread -e dnsmasq; netstat -l -n -p | grep -e dnsmasq produces the below output:

Thu Aug 10 11:18:59 2023 user.notice dnsmasq: DNS rebinding protection is active, will discard upstream RFC1918 responses!
Thu Aug 10 11:18:59 2023 user.notice dnsmasq: Allowing 127.0.0.0/8 responses
Thu Aug 10 11:18:59 2023 daemon.info dnsmasq[1]: started, version 2.89 cachesize 1000
Thu Aug 10 11:18:59 2023 daemon.info dnsmasq[1]: DNS service limited to local subnets
Thu Aug 10 11:18:59 2023 daemon.info dnsmasq[1]: compile time options: IPv6 GNU-getopt no-DBus UBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-nftset no-auth no-cryptohash no-DNSSEC no-ID loop-detect inotify dumpfile
Thu Aug 10 11:18:59 2023 daemon.info dnsmasq[1]: UBus support enabled: connected to system bus
Thu Aug 10 11:18:59 2023 daemon.info dnsmasq[1]: using nameserver 127.0.0.1#5453
Thu Aug 10 11:18:59 2023 daemon.info dnsmasq[1]: using nameserver ::1#5453
Thu Aug 10 11:18:59 2023 daemon.info dnsmasq[1]: using only locally-known addresses for test
Thu Aug 10 11:18:59 2023 daemon.info dnsmasq[1]: using only locally-known addresses for onion
Thu Aug 10 11:18:59 2023 daemon.info dnsmasq[1]: using only locally-known addresses for localhost
Thu Aug 10 11:18:59 2023 daemon.info dnsmasq[1]: using only locally-known addresses for local
Thu Aug 10 11:18:59 2023 daemon.info dnsmasq[1]: using only locally-known addresses for invalid
Thu Aug 10 11:18:59 2023 daemon.info dnsmasq[1]: using only locally-known addresses for bind
Thu Aug 10 11:18:59 2023 daemon.info dnsmasq[1]: using only locally-known addresses for lan
Thu Aug 10 11:18:59 2023 daemon.err dnsmasq[1]: failed to load names from /etc/hosts: No such file or directory
Thu Aug 10 11:18:59 2023 daemon.info dnsmasq[1]: read /tmp/hosts/dhcp.cfg01411c - 0 names
Thu Aug 10 11:19:04 2023 daemon.info dnsmasq[1]: exiting on receipt of SIGTERM
Thu Aug 10 11:19:04 2023 daemon.info dnsmasq[1]: started, version 2.89 cachesize 1000
Thu Aug 10 11:19:04 2023 daemon.info dnsmasq[1]: DNS service limited to local subnets
Thu Aug 10 11:19:04 2023 daemon.info dnsmasq[1]: compile time options: IPv6 GNU-getopt no-DBus UBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-nftset no-auth no-cryptohash no-DNSSEC no-ID loop-detect inotify dumpfile
Thu Aug 10 11:19:04 2023 daemon.info dnsmasq[1]: UBus support enabled: connected to system bus
Thu Aug 10 11:19:04 2023 daemon.info dnsmasq-dhcp[1]: DHCP, IP range 192.168.1.100 -- 192.168.1.249, lease time 12h
Thu Aug 10 11:19:04 2023 daemon.info dnsmasq[1]: using nameserver 127.0.0.1#5453
Thu Aug 10 11:19:04 2023 daemon.info dnsmasq[1]: using nameserver ::1#5453
Thu Aug 10 11:19:04 2023 daemon.info dnsmasq[1]: using only locally-known addresses for test
Thu Aug 10 11:19:04 2023 daemon.info dnsmasq[1]: using only locally-known addresses for onion
Thu Aug 10 11:19:04 2023 daemon.info dnsmasq[1]: using only locally-known addresses for localhost
Thu Aug 10 11:19:04 2023 daemon.info dnsmasq[1]: using only locally-known addresses for local
Thu Aug 10 11:19:04 2023 daemon.info dnsmasq[1]: using only locally-known addresses for invalid
Thu Aug 10 11:19:04 2023 daemon.info dnsmasq[1]: using only locally-known addresses for bind
Thu Aug 10 11:19:04 2023 daemon.info dnsmasq[1]: using only locally-known addresses for lan
Thu Aug 10 11:19:04 2023 daemon.err dnsmasq[1]: failed to load names from /etc/hosts: No such file or directory
Thu Aug 10 11:19:04 2023 daemon.info dnsmasq[1]: read /tmp/hosts/dhcp.cfg01411c - 4 names
Thu Aug 10 11:19:04 2023 daemon.info dnsmasq-dhcp[1]: read /etc/ethers - 0 addresses
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      2172/dnsmasq
tcp        0      0 192.168.1.1:53          0.0.0.0:*               LISTEN      2172/dnsmasq
tcp        0      0 192.168.4.218:53        0.0.0.0:*               LISTEN      2172/dnsmasq
tcp        0      0 fe80::dea6:32ff:febd:91fa:53 :::*                    LISTEN      2172/dnsmasq
tcp        0      0 fdf8:3b0c:6ab3::1:53    :::*                    LISTEN      2172/dnsmasq
tcp        0      0 fe80::dea6:32ff:febd:91f8:53 :::*                    LISTEN      2172/dnsmasq
tcp        0      0 fe80::d237:45ff:fed2:6a14:53 :::*                    LISTEN      2172/dnsmasq
tcp        0      0 ::1:53                  :::*                    LISTEN      2172/dnsmasq
udp        0      0 192.168.4.218:53        0.0.0.0:*                           2172/dnsmasq
udp        0      0 127.0.0.1:53            0.0.0.0:*                           2172/dnsmasq
udp        0      0 192.168.1.1:53          0.0.0.0:*                           2172/dnsmasq
udp        0      0 0.0.0.0:67              0.0.0.0:*                           2172/dnsmasq
udp        0      0 fe80::dea6:32ff:febd:91fa:53 :::*                                2172/dnsmasq
udp        0      0 ::1:53                  :::*                                2172/dnsmasq
udp        0      0 fe80::d237:45ff:fed2:6a14:53 :::*                                2172/dnsmasq
udp        0      0 fdf8:3b0c:6ab3::1:53    :::*                                2172/dnsmasq
udp        0      0 fe80::dea6:32ff:febd:91f8:53 :::*                                2172/dnsmasq

logread -e stubby; netstat -l -n -p | grep -e stubby produces the below output:

Thu Aug 10 11:19:11 2023 daemon.err stubby[2486]: [08:19:11.529380] STUBBY: Read config from file /var/etc/stubby/stubby.yml[08:19:11.529956] STUBBY: Stubby version: Stubby 0.4.3
Thu Aug 10 11:19:11 2023 daemon.err stubby[2486]: [08:19:11.530433] STUBBY: DNSSEC Validation is OFF
Thu Aug 10 11:19:11 2023 daemon.err stubby[2486]: [08:19:11.530653] STUBBY: Transport list is:
Thu Aug 10 11:19:11 2023 daemon.err stubby[2486]: [08:19:11.530845] STUBBY:   - TLS
Thu Aug 10 11:19:11 2023 daemon.err stubby[2486]: [08:19:11.531032] STUBBY: Privacy Usage Profile is Strict (Authentication required)
Thu Aug 10 11:19:11 2023 daemon.err stubby[2486]: [08:19:11.531226] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!)
Thu Aug 10 11:19:11 2023 daemon.err stubby[2486]: [08:19:11.531422] STUBBY: Starting DAEMON....
tcp        0      0 127.0.0.1:5453          0.0.0.0:*               LISTEN      2486/stubby
tcp        0      0 ::1:5453                :::*                    LISTEN      2486/stubby
udp        0      0 127.0.0.1:5453          0.0.0.0:*                           2486/stubby
udp        0      0 ::1:5453                :::*                                2486/stubby

What should be my next step?

is dnsmasq set to forward all requests to stubby, on localhost:5453, it appears to be at least ?

or disable dnsmasqs DNS, and reconfigure stubby to run on port 53
or set dnsmasq to only bind to 127.0.0.1, while stubby binds to 192.168.*

and check if stubby actually works.

but why stubby, and not dns-over-https ?

1 Like

Yeah, to @frollic 's point, try this first:

$ nslookup google.com 127.0.0.1:5453
Server:         127.0.0.1:5453
Address:        127.0.0.1:5453

Non-authoritative answer:
Name:   google.com
Address: 2607:f8b0:4007:818::200e

Non-authoritative answer:
Name:   google.com
Address: 142.250.72.174

Here's my stubby and dnsmasq config, been working forever.

/etc/config/stubby:

config stubby 'global'
        option manual '0'
        option trigger 'wan'
        list dns_transport 'GETDNS_TRANSPORT_TLS'
        option tls_authentication '1'
        option tls_query_padding_blocksize '128'
        option appdata_dir '/var/lib/stubby'
        option edns_client_subnet_private '1'
        option idle_timeout '10000'
        option round_robin_upstreams '1'
        list listen_address '127.0.0.1@5453'
        list listen_address '0::1@5453'
config resolver
        option address '9.9.9.9'
        option tls_auth_name "dns.quad9.net"
config resolver
        option address 149.112.112.112
        option tls_auth_name "dns.quad9.net"
config resolver
        option address 2620:fe::9
        option tls_auth_name "dns.quad9.net"
config resolver
        option address '2620:fe::fe'
         option tls_auth_name "dns.quad9.net"

Snippet from /etc/config/dhcp:

config dnsmasq
        option domainneeded '1'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option expandhosts '1'
        option authoritative '1'
        option quietdhcp '1'
        option leasefile '/tmp/dhcp.leases'
        option localservice '1'
        option ednspacket_max '1232'
        option local '/lan/'
        option domain 'lan'
        option noresolv '1'
        option dnssec '1'
        option confdir '/tmp/dnsmasq.d'
        list server '127.0.0.1#5453'
        list server '::1#5453'
        list interface 'br-lan'
        option cachesize '10000'

@efahl,

Your stubby conf is identical to mine. I replaced some resolvers just to make sure that this wasn't the problem (not that 1.1.1.1 was ever NOT going to work, but still) - not fixed

Your dhcp snippet differs by having these extra options:

        option quietdhcp '1'
        option dnssec '1'
        option confdir '/tmp/dnsmasq.d'
        list interface 'br-lan'

though none did the trick. I really don't know what is going on, since I have used pretty much the same configuration and it was working on a previous installation (earlier OpenWRT version, but I don't think it matters).

@frollic :
The DoH with Dnsmasq and https-dns-proxy guide works like a charm and is easier to follow, script, understand and write down instructions for myself for, for later openWRT installations. I wonder if there's any benefit to using the stubby approach, I am maybe not that technical to understand. Is the same level of security guaranteed? What about DNSSEC, Secure DNS, and/or Secure SNI?

Enable Log queries on DNS server configuration page and then check the system log after making a DNS query.

1 Like

No idea, haven't used Stubby, but it looks like a DoT resolver :frowning:

It uses HTTPS, if it's enough for your online banking, it should be ok for DNS lookups too.

My issue is mostly solved. I have only the questions below:

  1. To use DNS over HTTPs, (as per the guide) is it enough to just install the https-dns-proxy package and be done with it? Do I need to do something else?
  2. How do I verify that DNS over HTTPs is working (besides sniffing packets upstream)? I do not know what to expect from the nslookup openwrt.org localhost command. My output is as follows:
Server:		localhost
Address:	[::1]:53

Non-authoritative answer:
Name:	openwrt.org
Address: 2a03:b0c0:3:d0::1af1:1

Non-authoritative answer:
Name:	openwrt.org
Address: 139.59.209.225

The issue is aggravated by the fact that browsers ALREADY use some form of DNS encryption

  1. Do I need to enable DNSSEC? I have been reading that it may cause intermittent (?) issues which are the hardest to troubleshoot, and it does not offer any security once you do have DoH. Should I add the below options to /etc/config/dhcp ?
        option dnssec '1'
        option dnsseccheckunsigned '1'

provide it with some BS IP or DNS name for the resolver, if everything starts failing, you'll know.

yes, mostly DoH, and they bypass the settings in the router.

But you can disable it, in the browser settings.

There's also https://openwrt.org/docs/guide-user/firewall/fw3_configurations/intercept_dns for the devices you can't control.

  • Monitor https-dns-proxy instance logs to ensure dns lookups are there.
  • Use bogus resolver URL and ensure that dns resolution is broken. :wink:

The https-dns-proxy supports canary flags/domains for mozilla and icloud private relay, as well as dns hijacking. It can also drop requests for port 853 which is used by some DoT resolvers to make them fall back to use router's DNS service.

2 Likes

What an amazing package. I don;t even need the DNS Hijacking rule on my firewall anymore. Nice to have everything packaged up in one place

OK, I think I've figured mostly everything out. Thanks to everyone for your help!

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.