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

[Green_man]

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?

[trendy]

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:

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.*/*

[stangri]

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.

[Green_man]

Thanks, this explanation is super helpful.

@stangri

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

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.

@trendy

Remember to redact passwords, MAC addresses and any public IP addresses you may have

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

[RuralRoots]

@Green_man

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.

[psherman]

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.

[agarg]

Superb explanation. I am glad that I "searched the forum" to land up with a succinct ready reply.

I am curious about the further mechanics on the DNS resolution. Assuming that my dhcp server on the interface is using option 6 example 6,192.168.1.1 to tell the devices to use this interface address for dns queries, bulk of the dns queries from the devices will land up with dnsmasq. Now for the dnsmasq (assuming not using doh and adblock), I specify 4 dns servers:

8.8.8.8
9.9.9.9
1.1.1.1
8.8.4.4

How will the dnsmasq handle the queries? Fire request to all four and forward the first response back to device? Or it will send to the first (8.8.8.8) and give it a second to respond and then forward to the second (9.9.9.9) and give this one another second and upon no response thus far from any then go to the third and then thereafter the fourth?

Is this some simple and predictable or there is some complex algo heuristic?
Thanks.

[stangri]

As far as I remember there's a setting for dnsmasq (in OpenWrt it's called strictorder) which configures it to follow strict resolvers order, which is set to 0 by default, so by default dnsmasq sends requests to all configured resolvers and sends back the first response it receives.

PS: Wiki: https://openwrt.org/docs/guide-user/base-system/dhcp

[dave14305]

Without all-servers enabled in dnsmasq, it will only send a query to all configured servers every 50 queries or 20 seconds (whichever comes first). Then it will use the fastest server from that “test”, until, the next interval.

https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/forward.c;h=8207a7ed76aee8fedba96ea71d1aebd5493cc9a3;hb=HEAD#l427

[egc]

strictorder does not work very reliable in my testing it really gives up quickly so in the end you are using most of your DNS servers, so for me strictorder is not a very useful setting

[agarg]

Fascinating. Thanks for pointing it out. Amazing stuff done three times a minute while we sip on our coffee!