It used to work with "178.168.192.in-addr.arpa". That doesn't look like something I would put there, so I guess this was an old default? If I replace it with 192.168.178.0/24 everything works as expected.
was also wrong (read as: not as mentioned by the documentation) before, however, the old way of doing it may have tolerated this, I'm not sure and checking it seems an unjustified amount of work.
Glad that it's working now for you 
with CIDR notation, we can now support also broader networks in conditional forwarding, such as 10.0.0.0/8.
The network that my pi-hole runs in was broken until I found time to repair it. While repairing it I couldn't Google. My servers didn't install security updates because they didn't have DNS.
Why do you think breaking backwards compatibility like this is okay?
That's not what I'm saying. I said
Tolerating something incorrect - and then even unintentionally - and then stopping to tolerate this isn't really a breaking change.
Don't get me wrong, I'm sorry for the inconvenience you experienced and we're really hard at trying to avoid this. However, I really haven't foreseen such a value being in this field because we never said anywhere that this is possible. If I'd have known it before, I'd have installed a suitable migration script for your legacy setting (like we always try to do).
Well, 178.168.192.in-addr.arpa is reverse DNS for 192.168.178.0/24. Nobody thinks of that when you ask for a network. It must have been a default in the pihole UI at some point.
Maybe other people can confirm this.
I doubt it could have been any kind of "default" with the uncommon 192.168.178.0/24 segment.
I perfectly agree with
but searching for older posts with "conditional forwarding", I can only find posts with screenshots clearly suggesting that an IP address should have been put there before:
https://www.reddit.com/r/pihole/comments/dj7pns/conditional_forwarding_doesnt_seem_to_be_working/
If I search git history with git log -S arpa this shows up:
# Example of routing PTR queries to nameservers: this will send all
# address->name queries for 192.168.3/24 to nameserver 10.1.2.3
#server=/3.168.192.in-addr.arpa/10.1.2.3
From pi-hole/dnsmasq.conf.original at e5f9663a0e6ed55cc62ffc19532c8b5977bd8a3a · pi-hole/pi-hole · GitHub
--rev-server=<ip-address>/<prefix-len>[,<ipaddr>][#<port>][@<source-ip>|<interface>[#<port>]]This is functionally the same as --server, but provides some syntactic sugar to make specifying address-to-name queries easier. For example --rev-server=1.2.3.0/24,192.168.0.1 is exactly equivalent to --server=/3.2.1.in-addr.arpa/192.168.0.1
For --rev-server you don't need the .in.addr.arpa and the reverse order.
This is the "default" subnet FritzBoxes use.
The remedy has already been explained, but how did that offending rev-server entry get in there?
Did you change Conditional Forwarding recently?
I can verify this happened to me as well.
Using simple CIDR "rev-server=192.168.0.1/24" allows the dnsmasq service to stay alive.
My guess to it's cause is that setupvars.conf was using very old data. Although it's also possible The page which contains forwarding info was updated recently too.
1 Like
The latest code change regarding rev-server was
1 Like
No, it's not. 178.168.192.in-addr.arpa is reverse for 192.168.178.0, no CIDR or netmask is implied or guaranteed.
I think the critical part of read REV_SERVER_CIDR from environment by BastiG · Pull Request #3761 · pi-hole/pi-hole · GitHub is:
CONDITIONAL_FORWARDING_REVERSE` originally contained the name of the reverse DNS zone. With this PR the documentation (over at https://github.com/pi-hole/docker-pi-hole, particularly https://github.com/pi-hole/docker-pi-hole/blob/master/README.md#environment-variables) should be updated to show an example value of `192.168.0.0/24` (or any other network address in CIDR notation) instead of `0.168.192.in-addr.arpa`
So, make sure to update CONDITIONAL_FORWARDING_REVERSE in your docker-compose file, if you use that.
3 Likes
Hello, i am replying to say i had this exact problem since 27-11-2020 2:30
I did not touch anything in my pihole, i didnt even log in for weeks. my FTL just stopped working suddenly.
changing the '178.168.192.in-addr.arpa' to 192.168.178.0/24 and restarting dns resolver fixed the issue
still, the issue of how FTL suddenly stopped working or how it was changed remains a mystery to me.
1 Like
My pi server has been running for a long time. I haven't changed anything in at least a year.
192.168.178.0 is a class C network. According to Wikipedia that has a default mask of /24. With classless networking you can use another mask, but /24 is certainly implied.
At any rate, I don't know why that is relevant. Nobody uses the in-arpa notation, so if it's in a lot of pi-hole config files, it must've been a default at some point.
Cool, how did you find that entry? I wonder why git log -S doesn't pick it up.
It never was a default, as Conditional Forwarding is enabled on user request only.
Pre-5 Pi-holes wrote a different format to setupVars.conf, but support for that has been removed since. It seems that this affected some docker setups, but the patch mentioned by ingmarstein does not seem to consider previous installations correctly.
Thanks for that link, yubiuser.
That code indeed pulls the value from
CONDITIONAL_FORWARDING_REVERSE=178.168.192.in-addr.arpa
but applies a conversion meant to deal with
REV_SERVER_TARGET=192.168.178.1
As a result, any existing CONDITIONAL_FORWARDING_REVERSE entry as correctly set by a previous version of Pi-hole will be converted to an incorrect REV_SERVER_CIDR.
This may affect all updates from Pi-hole v4 installations that have Conditional Forwarding enabled, or any younger that still have those older CONDITIONAL_FORWARDING_REVERSE entries present for whatever reasons.
EDIT: Corresponding issue is CONDITIONAL_FORWARDING_REVERSE may prevent Pi-hole from starting after update · Issue #3880 · pi-hole/pi-hole · GitHub
My setup is plain Raspbian without docker.