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.
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.
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://1.1.1.1/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 1.1.1.1 and DoT, when it's off it consistently recognizes, even thou in both cases it displays AS name as Cloudflare.
# 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/1.1.1.1' ## --- 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
On "/etc/config/network"
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 (1.1.1.1)
Just make a duplicate of the file "/etc/stubby/stubby.yml.default", pick the desired resolver then rename the file to "stubby.yml"
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
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).
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.
I believe option dns '127.0.0.1 1.1.1.1 1.0.0.1' works as this, first tries 127.0.0.1 if it fails or timeouts then tries 1.1.1.1, 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).
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.
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, 1.1.1.1/help detects the connection to cf, but not DoT.
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.
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
What’s important in this case is if the server response is NOERROR or SERVFAIL. In case of servfail which the common DNSSEC reply in case of validation fail, you aren’t able to open the site.