Hi there,
After some months running flawlessly, today my pihole device stopped working. When connecting to the admin interface there was an error that started overnight:
DNSMASQ_CONFIG FTL failed to start due to error at line 46 of /etc/dnsmasq.d/01-pihole.conf
Went to conf file, and line 46 is:
rev-server=1.168.192.in-addr.arpa,192.168.1.1
Any idea on what could be going on? Where to start checking?
This is a line specifying a server for conditional forwarding. Did you enable that (Settings/DNS)?
The syntax seems to be wrong, it should be something like
rev-server=192.168.0.1/24,192.168.0.1
(See Man page of DNSMASQ)
You could try to disable CF in the webinterface, save and re-enable it if you need it.
Same problem! Home network stopped working, eventually traced to this line in the pi-hole logs:
FTL failed to start due to error at line 52 of /etc/dnsmasq.d/01-pihole.conf
Line 52 is:
rev-server=1.168.192.in-addr.arpa,192.168.1.1
If I comment this rev-server line out, it works. Running Raspbian 9.
Based on yubiuser's suggestion, it does look related to Conditional DNS forwarding. I use to that resolve the local "fritz.box" domain. If I save these settings in the pihole admin website, this error shows up:
Conditional forwarding subnet ("178.168.192.in-addr.arpa") is invalid!
This field requires CIDR notation for local subnets (e.g., 192.168.0.0/16).
Please use only subnets /8, /16, /24, and /32.
The settings have been reset to their previous values
Did you use CIDR notation for that field? Usually it is /24. So in your case 192.168.1.1/24
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:
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
--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.
The latest code change regarding rev-server was
https://github.com/pi-hole/pi-hole/pull/3761
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 buzz-tee · 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.
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.
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.