[Tutorial] DNS-over-TLS with dnsmasq and stubby (no need for unbound)

Installing and Using OpenWrt Network and Wireless Configuration
85

/etc/stubby/stubby.yml

# Note: by default on OpenWRT stubby configuration is handled via
# the UCI system and the file /etc/config/stubby. If you want to
# use this file to configure stubby, then set "option manual '1'"
# in /etc/config/stubby.

AFAIK
Setting option manual to 1 just does what it's says in the stubby.yml file, your problem is not about which file you are using for configuration but actually the whole configuration, because if you set to manual '1' then you have to set all configuration option on stubby.yml since all configuration in /etc/config/stubby is being ignored (except for option manual).

86

I ran the commands at the bottom of the post and I am not able to get a Yes for the "Using DNS over TLS" section on the Cloudflare page.

https://1.1.1.1/help

87

As far as I can tell, that Cloudflare page returns false negatives.

1 Like
88

This is issue has been discussed further up in this topic, for some reason their own website seems to fail at this detection when you're using DNS-over-TLS on the router and not on the device you're accessing the webpage, I've tried to run this test directly on the router using cURL but the webpage uses javascript to do this detection.

I don't know exactly what the the JS is doing but it might detect that between the router and the computer the DNS resolution isn't over TLS, which is true.

1 Like
89

took me a while to figure this out:

you may need to add the router's ip address:

listen_addresses:
  - 127.0.0.1@5453
  - 0::1@5453
  - 192.168.0.1@5453

if I set:
dnssec GETDNS_EXTENSION_TRUE
I am no longer able to resolve any dns requests.
if I change that to:
dnssec_return_status: GETDNS_EXTENSION_TRUE
the syslog shows: STUBBY: DNSSEC Validation is ON
But test sites like:
https://rootcanary.org/test.html or http://dnssec.vs.uni-due.de/
do show errors, And: https://cmdns.dev.dns-oarc.net/ gives me a C Rating for cloudflare ipv4 servers.

If I remove the setting GETDNS_EXTENSION_TRUE entirely
the syslog shows: STUBBY: DNSSEC Validation is OFF
but the test sites are mostly positve, and the DNS rating goes up to B.

also only this setup returns the authenticated data flag from dig:

dig pir.org +dnssec +multi
...
flags: qr rd ra ad;
...

not sure what I should think about this.

90

Hi all..

So, after a fair amount of time, I had lousy connectivity and large bursts of this Stubby error in the syslog:

Thu May 30 17:11:57 2019 daemon.info dnsmasq[3554]: using nameserver ::1#5453
Thu May 30 17:11:57 2019 daemon.info dnsmasq[3554]: using local addresses only for domain lan
Thu May 30 17:11:57 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:11:57 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:11:57 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:11:57 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:11:57 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:11:57 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:11:58 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports

I also have had some errors around the ath10k driver, so that might be a different part of different problem. I'll handle that in another thread, probably...

After huge blocks of the above, I see a few other things :slight_smile:

Thu May 30 17:12:14 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:12:14 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:12:14 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:12:14 2019 daemon.notice netifd: Network device 'eth1' link is up
Thu May 30 17:12:14 2019 daemon.notice netifd: Interface 'wan' has link connectivity
Thu May 30 17:12:14 2019 daemon.notice netifd: Interface 'wan' is setting up now
Thu May 30 17:12:14 2019 daemon.notice netifd: Interface 'wan6' has link connectivity
Thu May 30 17:12:14 2019 daemon.notice netifd: Interface 'wan6' is setting up now
Thu May 30 17:12:14 2019 kern.info kernel: [ 2021.293020] r8169 0000:03:00.0 eth1: link up
Thu May 30 17:12:14 2019 daemon.notice netifd: wan (8496): udhcpc: started, v1.30.1
Thu May 30 17:12:14 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:12:14 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:12:14 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:12:14 2019 daemon.notice netifd: wan (8496): udhcpc: sending discover
Thu May 30 17:12:15 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:12:15 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:12:15 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:12:15 2019 daemon.err stubby[3661]: Could not sched

and finally some kind of lease from I'm not sure what... from my cable box's domain? !?!?

Thu May 30 17:12:19 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:12:19 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:12:19 2019 daemon.notice netifd: wan (8496): udhcpc: sending select for 192.168.100.11
Thu May 30 17:12:19 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:12:19 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:12:19 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:12:19 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:12:19 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:12:19 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:12:19 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:12:19 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:12:19 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:12:19 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:12:19 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:12:19 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:12:19 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:12:19 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:12:19 2019 daemon.err stubby[3661]: Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports
Thu May 30 17:12:20 2019 daemon.notice netifd: wan (8496): udhcpc: lease of 192.168.100.11 obtained, lease time 122
Thu May 30 17:12:20 2019 daemon.notice netifd: Interface 'wan' is now up

I followed the setup here, and it had seemed to be working OK, at least as much as I can tell by just trying some of the test links, and not resorting to Wireshark... Rebooting seems to clear things up, till it starts acting up again. Can anyone tell me what's up here?

91

Uh, did I TL;DR myself with the long log entries?

92

OK did some reading on my own. Found an old thread elsewhere seeming to relate this to stubby starting up and trying to connect before there's something to connect to.

I've been having issues with the wifi radios either dropping, resetting, or just going unresponsive, with nothing to kernel emergency warnings in the logs. BUT, this seems to be coinciding with an unexplained WAN link dropout, (eth1 is my wan) not my wifi in my separate AP C7. I haven't seemed to see any eth dropouts.

My wan, stubby and main routing is thru a separate x86 box. Both are running their respective snapshots, 4-20-19.
(should have known better than to trust that date?)

93

Stubby can't reach upstream because your wan interface is down.

94

Someone updated the wiki it's pretty comprehensive and clean now

https://openwrt.org/docs/guide-user/services/dns/dot_dnsmasq_stubby

Edit: only missing thing is that one should disable use remote/peer dns if wan is dhcp to avoid dns leak. Can someone add it I don't know how

1 Like