Confused by multiple DNS settings; advice for best practices/conflict avoidance?

Hi, recently upgraded the firmware on my TP-link archer A7 V5 and really appreciate the power and security improvements the openWRT firmware offers over the manufacturers.

That said I'm a bit confused by the multiple DNS settings and want to make sure I'm using that power in a way that makes sense.

I have Wan & Wan 6 set to Quad9. On the advice of a different set up tutorial, I installed and configured HTTPS-DNS-proxy which has its own DNS config. I set Quad9 as primary and ad-guard as secondary there. I also installed and enabled adblock, which wants me to specify a DNS backend in some of its settings? Furthermore it also has a force local DNS setting there, which might be helpful for mobile devices, but as now I've got three, if I enable that, it's not clear to me what I would be forcing?

Also interested in running IPband, as it offers straightforward geo-blocking, but unsure if I have to worry about that conflicting with any of the above?

can anyone help explain how these various DNS settings relate to one another and what best practice for having things run as smoothly as possible would be?

There are a lot of packages added and it is not easy to say which one has precedence over the others. Let's have a look at the configuration:

Please run the following commands (copy-paste the whole block) and paste the output here, using the "Preformatted text </> " button:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have

ubus call system board; \
uci export network; \
uci export dhcp; uci export firewall; \
nft list ruleset; \
ls -l  /etc/resolv.* /tmp/resolv.* /tmp/resolv.*/* ; head -n -0 /etc/resolv.* /tmp/resolv.* /tmp/resolv.*/*
3 Likes

Do what @trendy said if you want expert eyes on your config.

But generally speaking, in the default install, the dnsmasq (or more capable dnsmasq-full) is the main OpenWrt package responsible for resolving DNS requests.

The https-dns-proxy, like the name implies, is a little proxy service which takes normal DNS requests, encrypts them on your router so that your ISP or MITM cannot monitor/alter/resell your DNS queries and sends them to the supporting servers which can process encrypted DNS requests. So with the https-dns-proxy, again in the default configuration, your network device sends the request for name resolution to dnsmasq, then dnsmasq hands the request over to https-dns-proxy, which encrypts the request and (in your case) sends it to Quad9 servers, which process the request and send encrypted reply back, https-dns-proxy decrypts it and hands the decrypted reply to dnsmasq which sends it to your network device.

The 3 major adblocking scripts/services available for OpenWrt (adblock, adblock-fast, adblock-lean) again, in default configuration, all work very similarly. They download multiple block-lists in different formats and process them to prepare a single block-list file for dnsmasq, so that when your network device sends a request for the domain which is part of the block-list, the dnsmasq replies that the domain is not found rather than trying to resolve it to the IP address.

There are alternative solutions for adblocking on your network, like AdGuardHome or pi-hole which can be deployed on/in addition to OpenWrt, but then those completely take over the name resolution service and you most likely are not using dnsmasq on your OpenWrt router for name resolution then.

Another option to consider (if you're already using https-dns-proxy) is to use some of the customizable DoH resolvers, where you can combine adblocking and secure DNS in the same service. Some of the servers allow you to specify as extra parameter either:

  • you user ID and then on the DoH server dashboard you can configure what do you want to be blocked
  • a special string which contains the IDs for the block-lists you want used when you send domain name for the resolution

Either way, that offloads your adblocking to the DoH server, if you send the domain name for resolution which is found in any of the block-lists enabled, the DoH server returns the "domain not found" reply which is then handed down to your network device. There are pros and cons to this approach, but unless you want to micro-manage your block/allow-lists, that might work very well to replace either adblock or adblock-lean.

5 Likes

Thanks, this explanation is super helpful.

I also read the linked post.

I think I will post the requested command output just for peace of mind.
It was pretty verbose, and the Windows terminal wasn't a fan, but I got it from my MX laptop.

Thanks for being patient with a newbie, got in a little deeper than I expected.

Where in that output should I be checking for things to redact? Tried to skim through but nothing is jumping out at me.

For the most part, any ip’s outside these ranges:

0.0.0.0/8
10.0.0.0/8
100.64.0.0/10
127.0.0.0/8
172.16.0.0/12
192.0.0.0/2

Any passwords, public/private keys, and MAC addresses. Mainly in Network and DHCP outputs. If in doubt retract it.

2 Likes

Adding a little more specificity to the earlier comment:

The RFC1918 address ranges are:

10.0.0.0/8 (10.0.0.0-10.255.255.255)
172.16.0.0/12 (172.16.0.0-172.31.255.255)
192.168.0.0/16 (192.168.0.0-192.168.255.255)

Loopback is:

127.0.0.0/8 (127.0.0.0-127.255.255.255)

And CG-NAT is:

100.64.0.0/12 (100.64.0.0-100.127.255.255)

Everything other than those ranges should be redacted.

1 Like