And yes, for me, I'm using DNSSEC and the page you posted shows as not connected to 184.108.40.206, but these other two sites clearly show Cloudflare local servers. I suggest you post in their forums about this.
One limitation of this approach, which is already mentioned, that I noticed is that the router itself doesn't use this dns path. The way it affects me is that sometimes I use my router as a simple socks proxy over ssh. i.e., I do ssh -D 1080 router, and point my browser to the socks proxy. In that scenario dns goes to ISP's dns.
Just change the DNS config for the WAN interfaces like shown below.
Then DNS resolution of the router will also go through dnsmasq -> stubby if it is available.
If not DNS requests will go to the other DNS servers (in this example also cloudflare) so the router can sync time etc. during boot until dnsmasq and stubby are running.
config interface 'wan' option peerdns '0' option dns '127.0.0.1 220.127.116.11 18.104.22.168' config interface 'wan6' option peerdns '0' option dns '::1 2606:4700:4700::1111 2606:4700:4700::1001'
Yes, I recommend this if you install stubby to ram, I have a similar setup myself.
If you install normally, it's safer to override all DNS network setting with the loopback connection as the static DNS server.
I will not recommend this setting. There is a great possibility of PLAIN dns request made directly to 22.214.171.124 & 126.96.36.199 without any TLS encryption.
Do you have a different recommendation then? The only non encrypted DNS requests in this setup will the one made by the router itself if it can't reach stubby, however, this situation is required if you are using the install to RAM option.
Now, if you install stubby normally, in a persistent way, I suggest that you set 127.0.0.1 and ::1 as the only static DNS servers in the network configuration.
I think I can confirm that there's an issue with cf's https://188.8.131.52/help website, I've setup a stubby on a Windows 10 VM to test that site with DNSSEC on and off, so a setup that is completely different in terms of operating system, except for stubby.
In the default setup of stubby I only changed the upstream servers to be only cloudflare, turned off round robin, and tried with DNSSEC on and off and the results are the same, when DNSSEC is on the site fails to recognize the connection to 184.108.40.206 and DoT, when it's off it consistently recognizes, even thou in both cases it displays AS name as Cloudflare.
This is what I do
# option resolvfile '/tmp/resolv.conf.auto' ## --- Make sure you disable (apply "#" in front) this to ignore isp's supplied dns # option cachesize '1024' ## --- If your router have a big RAM, you can enable this option with dnsmasq-full installed option noresolv '1' ## --- This will prevent the use of isp's dns list server '/pool.ntp.org/220.127.116.11' ## --- Your router date & time must be correct in order to have sucessful tls init list server '127.0.0.1#5453' ## --- Default stubby service port
config interface 'wan' option ifname 'eth1' option proto 'pppoe' option username 'username' option password 'password' option peerdns '0' ## --- This will prevent the use of isp's dns option dns '127.0.0.1' ## --- this will make sure the router itself can do "ping google.com"
If you have extra ROM+RAM you can assign some of RAM capacity for dns cache.
Bonus: How to install dnsmasq-full
cd /tmp opkg update opkg download dnsmasq-full ## --- 1st we need to download dnsmasq-full opkg install dnsmasq-full ## --- Installation will fail as dnsmasq-full files are conflicting with exisiting dnsmasq opkg remove dnsmasq ## --- You will have no access to internet after this opkg install /tmp/dnsmasq-full(press Tab) ## --- Internet access will be restored after this
Bonus: You don't have to install ca-bundle/ca-certificates if you don't use cloudflare's (18.104.22.168)
Just make a duplicate of the file "/etc/stubby/stubby.yml.default", pick the desired resolver then rename the file to "stubby.yml"
- Go to https://www.dnsleaktest.com/ or
- On your router, go to status/realtime/connections
make sure ALL dns requests :53 from clients are ONLY goes into the router (NOT directly to internet)
and dns requests via tls :853 is ONLY goes to configured resolver or
- Analyse your wan outgoing port :53 with wireshark
The point of this is to have working DNS resolution for the router itself during boot and shortly after when dnsmasq and stubby aren't running yet (e.g. downloading blocklists for adblock, time sync, opkg stuff, ...).
DNS requests of the connected clients will still be going through dnsmasq and stubby, the settings are for the WAN interfaces only.
As soon as all services are running the requests made by the router will also go through dnsmasq and stubby. Plain requests will only be made if dnsmasq is not running but only for the router itself not the clients. The requests made by the clients will simply fail.
You can ofcourse also assign certain domains like "pool.ntp.org" to a certain resolver (like you did) to ensure a smooth boot process. But if you do that they will always be plain DNS requests since dnsmasq will not use stubby.
I also had issues with adblock failing to download some lists if it had to wait for dnsmasq and stubby to be running. So i switched to this config it at seems to work fine so far.
DNS requests made by the router during boot -> unencrypted
DNS requests made by the clients during boot -> failing
DNS requests made by the router when dnsmasq/stubby is up -> encrypted
DNS requests made by the clients when dnsmasq/stubby is up -> encrypted
You may also try to tweak the starting priorities of the services a bit to ensure dnsmasq / stubby are running earlier. But I don't see a need to mess with that.
If you really want to make sure all requests from within your LAN will go through the router, you can intercept connections to port 53 with iptables and redirect them (or block them outright).
You right about dns leak during ntp requests.
But I failed to mention that I reduced it by setting
config timeserver 'ntp' option enabled '1' option enable_server '1' list server 'pool.ntp.org'
iptables -t nat -A PREROUTING -p udp --dport 123 -j REDIRECT --to-ports 123
These will force lan clients to use ONLY the router provided ntp service
I've tried it my self, if I do it as above.
One of the example of dns leak is when we open up http://your-router-ip/cgi-bin/luci/admin/status/realtime/connections
Some dns requests made (round robin?) are PLAIN [one.one.one.one:53]. I think its because our router's luci try to resolve all IPs displayed to be presentable as domain names.
Yes, it's likely luci/netstat doing name resolving, which is the router itself making these requests and not clients of the network.
option dns '127.0.0.1 22.214.171.124 126.96.36.199' works as this, first tries 127.0.0.1 if it fails or timeouts then tries 188.8.131.52, etc. However this sequence does not affect the clients, clients only go through dnsmasq if they do not set static DNS servers (127.0.0.1 also goes trough dnsmasq).
https://www.dnsleaktest.com/ shows there is no leakage on clients.
About routing DNS requests, in the future browsers and apps will likely have built-in DNS-over-HTTPS which will make DNS lookup traffic undistinguishable from web traffic, also unreroutable, but totally encrypted.
Yeah not a fan of every application bringing their own solution for DNS resolution so I hope it won't be the default and can be disabled.
DNS over HTTPS is also planned for stubby 0.3 so we'll have that covered too: https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+Stubby#DNSPrivacyDaemon-Stubby-KeyFeatures
Maybe we'll even have operating system support by default for DNS over TLS / DNS over HTTPS at some point.
Yes, I'm looking forward to implement DoH with stubby and maybe write a turorial on that too.
This routes it to cf, but not over TLS from what I can tell. i.e., If i connect to my router via ssh -D 1080 router for the sock proxy, the dns goes to regular cf. dnsleaktest detects several servers, although all of them cf (which is how regular cf behaves). With dns over tls, dnsleaktest detects only 1 server. Also, 184.108.40.206/help detects the connection to cf, but not DoT.
Then this might not work for your use case with the SSH proxy.
Try setting only '127.0.0.1' and '::1' as your DNS servers on the WAN infterfaces and remove the ones form your ISP (option peerdns '0').
This should make sure that all DNS requests made by the router itself go through dnsmasq / stubby.
The downside of this is that the router will be unable to to perform DNS resolution until dnsmasq and stubby are running.
I am using the config I posted myself and "dnsleaktest" + "220.127.116.11/help" show the correct results.
But I am not using the router as SSH proxy.
cloudflare's support for dnssec seems problematic. It seems to break for some sites. Are any of you able to do nslookup login.comcast.net from a client ? I get a SERVFAIL with cf+dnssec. It works with quad9+dnssec, and cf without dnssec.
[user@v-fed-1 ~]$ dig login.comcast.net +dnssec @18.104.22.168 +short login.g.comcast.net. CNAME 5 3 7200 20180830172144 20180823141644 26550 comcast.net. KDBvpzYCCFvgJbLhpcoQUHUGlUAiPprwfsKSQnrOKZ12e7JtInUxIRYz VCXXv2Eh1L+VQMrBaSCLt1voaFtEVu0Jheo2W7Ybw5ChK04YszhlRPqy 2Dh7YN0VZ7ASfKKOkmiPQRlueGbR16+omGoG7Wj24VhDday6XncM99bw GPg= 22.214.171.124 [user@v-fed-1 ~]$ dig login.comcast.net +dnssec @126.96.36.199 +short login.g.comcast.net. CNAME 5 3 7200 20180830172144 20180823141644 26550 comcast.net. KDBvpzYCCFvgJbLhpcoQUHUGlUAiPprwfsKSQnrOKZ12e7JtInUxIRYz VCXXv2Eh1L+VQMrBaSCLt1voaFtEVu0Jheo2W7Ybw5ChK04YszhlRPqy 2Dh7YN0VZ7ASfKKOkmiPQRlueGbR16+omGoG7Wj24VhDday6XncM99bw GPg= 188.8.131.52 [user@v-fed-1 ~]$ dig login.comcast.net +dnssec @184.108.40.206 +short login.g.comcast.net. CNAME 5 3 7200 20180830172144 20180823141644 26550 comcast.net. KDBvpzYCCFvgJbLhpcoQUHUGlUAiPprwfsKSQnrOKZ12e7JtInUxIRYz VCXXv2Eh1L+VQMrBaSCLt1voaFtEVu0Jheo2W7Ybw5ChK04YszhlRPqy 2Dh7YN0VZ7ASfKKOkmiPQRlueGbR16+omGoG7Wj24VhDday6XncM99bw GPg= 220.127.116.11
This is over regular dns. I meant client using dns over tls as described in this thread. It seems to fail when cf is the server, and stubby has dnssec_return_status: GETDNS_EXTENSION_TRUE. Change your server to 192.168.1.1 in your dig or nslookup