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


#64

i figured it out. ntp is blocked so the router time/year is wrong. since the time is wrong; the certificates was invalid and could not be established. This probably would not affect most users. Just an fyi.


#65

It looks like google added dns over tls. Should test it.


#66

Well if privacy is your concern... Use Google DNS is bad... VERY BAD...


#68
try https_dns_proxy

opkg update
opkg install https_dns_proxy

I don't understand. This is a response to what?


#69

I assume whoever wrote that was trying to point out that you can just get most of this out of the box with the https_dns_proxy, though there are downsides as it only supports a single https end point out of the box.

Using it with quad9 I've found that there are odd failures also, which as a result occasionally lead to lookup failures that take some time to bleed out of the system due to caching.


#70

Incidentally, I think pointing your internal clients to the in-router NTP server is a very bad idea unless your router also has a rtc chip in it (most don't)

On reboot/power loss your router will often reset itself to some internal zero value which can then cause clock skews to cascade through your network..


#71

Thanks for the tutorial,
I successfully installed stubby on my TP-Link TL-WDR3600 and used it for the past month with Cloudfare 1.1.1.1 and I was very happy with the service. The only drawbacks were a tablet running android 4.1.1 was not able to access the internet, a galaxy S4 running android 5.1 had problems with gmail. Newer phones with android 7 had no problems. I removed it when for some unknown reason my Cisco SPA122 ATA supplied by mynetfone stopped working and I had no voip.

I will try and understand more about settings and options and re-install again in the future.


#72

As an aside, I've found dnsmasq+stubby (or https_dns_proxy) to be far less stable than dnsmasq+dnscrypt (even using the older version 1 servers that is all that openwrt has support for).

In the case of bot DoH or DoT (using https_dns_proxy and stubby), I'm seeing a lot of DNS lookup failures - a lot of which in stubby's case seems to be related to stale connections on the server end that have got cleaned up, meaning that the next query fails.

I've tried playing around with connection time - and AFAICT anyway it's not the router that is clearing it down (either directly or via connection tracking).


#73

I recently had problems with the stubby+dnsmasq setup, using the --proxy-dnssec option in dnsmasq so that stubby would do dnssec. Quite often this setup would stop resolving and I needed to restart both services to get my connection back online. I finally sorted things out by using dnsmasq-full and letting dnsmasq-full do the dnssec. This current setup is working smoothly fast.


#74

Are you sure that DNSSEC-validation is performed by dnsmasq and not your DNS-provider?
Because many public DNS-providers validate DNSSEC by default:
https://en.wikipedia.org/wiki/Public_recursive_name_server


#75

I thought so but now that you asked I'm not so sure...

When I test for DNSSEC (https://cmdns.dev.dns-oarc.net) I see that I have a validation. But since you asked, I'm now wondering that when I setup dnsmasq-full to perform DNSSEC validation, maybe it is validating the connection between dnsmasq and stubby and not the connection between the router and the public DNS provider (Cloudflare in my case).

Not an expert here so any light on the matter will be appreciated.


#76

Change DNS-provider, otherwise you can't test your own DNSSEC-validation:

# dig +short @1.1.1.1 -q www.dnssec-failed.org

# dig +short @9.9.9.10 -q www.dnssec-failed.org
69.252.193.191
68.87.109.242

Or you can just delegate DNSSEC-validation to the DNS-provider.


#77

The default install already enables DNSSEC validation together with DNS via TLS?


#78

Stubby's default install (stubby.yml)? No, by default it does not do DNSSEC.
You have to check stubby.yml anyways, it's this line that gives DNSSEC vvalidation:

dnssec_return_status: GETDNS_EXTENSION_TRUE


#79

Luckily I spotted this thread and now I have configured DNS-over-TLS as per instructions.

Based on the latest stubby.yml.default doc that DNSSEC validation config line may have changed to below.
dnssec: GETDNS_EXTENSION_TRUE

I changed to that and at least the syslog is showing validation is on;
Sat Mar 2 21:56:01 2019 daemon.err stubby[12468]: [13:56:01.401956] STUBBY: DNSSEC Validation is ON

But my question is, what should I look for from WAN interface tcpdump to verify I'm actually using DNSSEC/TLS for my queries?


#80

Yeah, I saw that 'dnssec:' is mentioned on the provided stubby.yml (quoted) but the online documentation says 'dnssec_return_status:', so I'm moderately confused now.


#81

Btw, how did you get that DNSSEC validation message? 'stubby -l' doesn't seem to output that?


#82

I just print syslog with logread to check any messages from Stubby and below was printed out;

Sat Mar  2 21:56:01 2019 daemon.err stubby[12468]: [13:56:01.401318] STUBBY: Read config from file /var/etc/stubby/stubby.yml
Sat Mar  2 21:56:01 2019 daemon.err stubby[12468]: [13:56:01.401956] STUBBY: DNSSEC Validation is ON
Sat Mar  2 21:56:01 2019 daemon.err stubby[12468]: [13:56:01.402270] STUBBY: Transport list is:
Sat Mar  2 21:56:01 2019 daemon.err stubby[12468]: [13:56:01.402416] STUBBY:   - TLS
Sat Mar  2 21:56:01 2019 daemon.err stubby[12468]: [13:56:01.402557] STUBBY: Privacy Usage Profile is Strict (Authentication required)
Sat Mar  2 21:56:01 2019 daemon.err stubby[12468]: [13:56:01.402694] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!)
Sat Mar  2 21:56:01 2019 daemon.err stubby[12468]: [13:56:01.402824] STUBBY: Starting DAEMON....

But answering to myself, you can verify it is using TLS by;

  1. Writing tcpdump to file
    tcpdump -s 0 -i eth0.2 -w /tmp/mycap.pcap
  2. Copy file back to your comp (linux box)
    scp root@192.168.1.1:/tmp/mycap.pcap ./
  3. Use wireshark

Edit: actually at least in my R7800 box with latest master the stubby -l is printing out exactly the same logs as logread from syslog


#83

Ensure, that DNS-traffic is encrypted (853/TCP+TLS), so you can't see plain-text domain names in DNS-queries/replies from/to WAN-interface.