conditional forwarding with non-natural CIDR block

[yfhyou]

Versions

• Pi-hole: v5.15.5
• AdminLTE: v5.18.4
• FTL: v5.21

Platform

• OS and version: Ubuntu 22.04.2 LTS

• Platform: Docker

Expected behavior

Using a conditional forwarding server of 100.64.0.0/10 should add all the corresponding /16 domains

100.64.0.0/16
100.65.0.0/16
...
...
100.127.0.0/16

Actual behavior / bug

dnsmasq only outputs for 100.64.0.0/16
dnsmasq[2003181]: using nameserver 100.100.100.100#53 for domain 64.100.in-addr.arpa

Steps to reproduce

Add an additional file to /etc/dnsmasq.d directory 98-custom-options.conf
Include rev-server=100.64.0.0/10
Start pihole.

Debug Token

No specific debug token, but issue is outlined in detail here:
https://discourse.pi-hole.net/t/conditional-forwarding-issues-w-tailscale/61522

Additional context

This issue was resolved in the dnsmasq program with revision 2.87. Docker tag 2022.10 has the dnsmasq version where the update occurred

Update embedded dnsmasq to v2.87 by @DL6ER in pi-hole/FTL#1449

The addtional dnsmasq config file with rev-server=100.64.0.0/10,100.100.100.100 using docker 2022.10 works as expected. The pihole.log output is as expected using this image.

Mar  3 10:06:36 dnsmasq[359]: using nameserver 100.100.100.100#53 for domain tail1de2d.ts.net
Mar  3 10:06:36 dnsmasq[359]: using nameserver 100.100.100.100#53 for domain 64.100.in-addr.arpa
Mar  3 10:06:36 dnsmasq[359]: using nameserver 100.100.100.100#53 for domain 65.100.in-addr.arpa
Mar  3 10:06:36 dnsmasq[359]: using nameserver 100.100.100.100#53 for domain 66.100.in-addr.arpa
Mar  3 10:06:36 dnsmasq[359]: using nameserver 100.100.100.100#53 for domain 67.100.in-addr.arpa
Mar  3 10:06:36 dnsmasq[359]: using nameserver 100.100.100.100#53 for domain 68.100.in-addr.arpa
Mar  3 10:06:36 dnsmasq[359]: using nameserver 100.100.100.100#53 for domain 69.100.in-addr.arpa
Mar  3 10:06:36 dnsmasq[359]: using nameserver 100.100.100.100#53 for domain 70.100.in-addr.arpa
Mar  3 10:06:36 dnsmasq[359]: using nameserver 100.100.100.100#53 for domain 71.100.in-addr.arpa
Mar  3 10:06:36 dnsmasq[359]: using nameserver 100.100.100.100#53 for domain 72.100.in-addr.arpa
Mar  3 10:06:36 dnsmasq[359]: using nameserver 100.100.100.100#53 for domain 73.100.in-addr.arpa
Mar  3 10:06:36 dnsmasq[359]: using nameserver 100.100.100.100#53 for domain 74.100.in-addr.arpa
Mar  3 10:06:36 dnsmasq[359]: using nameserver 100.100.100.100#53 for domain 75.100.in-addr.arpa
Mar  3 10:06:36 dnsmasq[359]: using nameserver 100.100.100.100#53 for domain 76.100.in-addr.arpa
Mar  3 10:06:36 dnsmasq[359]: using nameserver 100.100.100.100#53 for domain 77.100.in-addr.arpa
Mar  3 10:06:36 dnsmasq[359]: using nameserver 100.100.100.100#53 for domain 78.100.in-addr.arpa
Mar  3 10:06:36 dnsmasq[359]: using nameserver 100.100.100.100#53 for domain 79.100.in-addr.arpa
Mar  3 10:06:36 dnsmasq[359]: using nameserver 100.100.100.100#53 for domain 80.100.in-addr.arpa
Mar  3 10:06:36 dnsmasq[359]: using nameserver 100.100.100.100#53 for domain 81.100.in-addr.arpa
Mar  3 10:06:36 dnsmasq[359]: using nameserver 100.100.100.100#53 for domain 82.100.in-addr.arpa
Mar  3 10:06:36 dnsmasq[359]: using nameserver 100.100.100.100#53 for domain 83.100.in-addr.arpa
Mar  3 10:06:36 dnsmasq[359]: using nameserver 100.100.100.100#53 for domain 84.100.in-addr.arpa
Mar  3 10:06:36 dnsmasq[359]: using nameserver 100.100.100.100#53 for domain 85.100.in-addr.arpa
Mar  3 10:06:36 dnsmasq[359]: using nameserver 100.100.100.100#53 for domain 86.100.in-addr.arpa
Mar  3 10:06:36 dnsmasq[359]: using nameserver 100.100.100.100#53 for domain 87.100.in-addr.arpa
Mar  3 10:06:36 dnsmasq[359]: using nameserver 100.100.100.100#53 for domain 88.100.in-addr.arpa
Mar  3 10:06:36 dnsmasq[359]: more servers are defined but not logged

Each needed /24 block is added individually.

2022.11 uses the next tagged dnsmasq version and does not work. It goes back to the wrong reverse server as shown in the actual behavior above.

Update embedded dnsmasq to v2.88test3 by @DL6ER in pi-hole/FTL#1469

This may be a dnsmasq bug, not pihole, but additional testing that I'm not sure how to do would be needed.

[pralor-bot]

This issue has been mentioned on Pi-hole Userspace. There might be relevant details there:

https://discourse.pi-hole.net/t/conditional-forwarding-issues-w-tailscale/61522/16

[DL6ER]

This bug was introduced in dnsmasq at commit pi-hole/dnsmasq@1db9943. Proposed fix is pi-hole/dnsmasq#13

[DL6ER]

My proposed bugfix has been merged (see https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2023q1/016913.html). You could change to the bleeding-edge dnsmasq branch to see if this fixes the issue also on your Pi-hole using

sudo pihole checkout ftl update/dnsmasq

Please make sure to go back to master using

sudo pihole checkout ftl master

after the next release to ensure you are back in sync with the releases. You could also stay on the branch but please be aware that things may break here as it follows dnsmasq development closely so regressions may only be detected later during the testing phase. However, development is typically stable and the quality is typically very high so the risks of something braking is low in reality.

[yfhyou]

Amazing. Can I test it using docker? Would the same commands work? I'm guessing they would not inside the container.

[dschaper]

You should be able to run docker container exec -it <container_name> pihole checkout ftl update/dnsmasq or docker exec -it bash <container_name> and run the command from the prompt.

[yfhyou]

Can confirm it worked for me!

Mar 14 09:51:20 dnsmasq[651]: using nameserver 100.100.100.100#53 for domain tailxxxxx.ts.net
Mar 14 09:51:20 dnsmasq[651]: using nameserver 100.100.100.100#53 for domain 64.100.in-addr.arpa
Mar 14 09:51:20 dnsmasq[651]: using nameserver 100.100.100.100#53 for domain 65.100.in-addr.arpa
Mar 14 09:51:20 dnsmasq[651]: using nameserver 100.100.100.100#53 for domain 66.100.in-addr.arpa
Mar 14 09:51:20 dnsmasq[651]: using nameserver 100.100.100.100#53 for domain 67.100.in-addr.arpa
Mar 14 09:51:20 dnsmasq[651]: using nameserver 100.100.100.100#53 for domain 68.100.in-addr.arpa
Mar 14 09:51:20 dnsmasq[651]: using nameserver 100.100.100.100#53 for domain 69.100.in-addr.arpa
Mar 14 09:51:20 dnsmasq[651]: using nameserver 100.100.100.100#53 for domain 70.100.in-addr.arpa
Mar 14 09:51:20 dnsmasq[651]: using nameserver 100.100.100.100#53 for domain 71.100.in-addr.arpa
Mar 14 09:51:20 dnsmasq[651]: using nameserver 100.100.100.100#53 for domain 72.100.in-addr.arpa
Mar 14 09:51:20 dnsmasq[651]: using nameserver 100.100.100.100#53 for domain 73.100.in-addr.arpa
Mar 14 09:51:20 dnsmasq[651]: using nameserver 100.100.100.100#53 for domain 74.100.in-addr.arpa
Mar 14 09:51:20 dnsmasq[651]: using nameserver 100.100.100.100#53 for domain 75.100.in-addr.arpa
Mar 14 09:51:20 dnsmasq[651]: using nameserver 100.100.100.100#53 for domain 76.100.in-addr.arpa
Mar 14 09:51:20 dnsmasq[651]: using nameserver 100.100.100.100#53 for domain 77.100.in-addr.arpa
Mar 14 09:51:20 dnsmasq[651]: using nameserver 100.100.100.100#53 for domain 78.100.in-addr.arpa
Mar 14 09:51:20 dnsmasq[651]: using nameserver 100.100.100.100#53 for domain 79.100.in-addr.arpa
Mar 14 09:51:20 dnsmasq[651]: using nameserver 100.100.100.100#53 for domain 80.100.in-addr.arpa
Mar 14 09:51:20 dnsmasq[651]: using nameserver 100.100.100.100#53 for domain 81.100.in-addr.arpa
Mar 14 09:51:20 dnsmasq[651]: using nameserver 100.100.100.100#53 for domain 82.100.in-addr.arpa
Mar 14 09:51:20 dnsmasq[651]: using nameserver 100.100.100.100#53 for domain 83.100.in-addr.arpa
Mar 14 09:51:20 dnsmasq[651]: using nameserver 100.100.100.100#53 for domain 84.100.in-addr.arpa
Mar 14 09:51:20 dnsmasq[651]: using nameserver 100.100.100.100#53 for domain 85.100.in-addr.arpa
Mar 14 09:51:20 dnsmasq[651]: using nameserver 100.100.100.100#53 for domain 86.100.in-addr.arpa
Mar 14 09:51:20 dnsmasq[651]: using nameserver 100.100.100.100#53 for domain 87.100.in-addr.arpa
Mar 14 09:51:20 dnsmasq[651]: using nameserver 100.100.100.100#53 for domain 88.100.in-addr.arpa
Mar 14 09:51:20 dnsmasq[651]: more servers are defined but not logged

Reverse DNS requests are answered as expected by 100.100.100.100 for the 100.64.0.0/10 subnet
Appreciate you making this change and in dnsmasq too!

[alexvy86]

Another confirmation that this worked for the same issue. Thanks for the fix @DL6ER ! I'll revert to the master branch and wait for the next release.

[DL6ER]

The next version of FTL has been released. Please update and run

pihole checkout master

to get back on-track. The fix/feature branch you switched to will not receive any further updates.

Thanks for helping us to make Pi-hole better for us all!

If you have any issues, please either reopen this ticket or (preferably) create a new ticket describing the issues in further detail and only reference this ticket. This will help us to help you best.

[alexvy86]

Updated to docker tag 2023.03.0 and all is good now.