Conditional Forwarding Bug or am I stupid?

Expected Behaviour:

Normally I just put in IP Range of my network and IP of my DHCP Server, but no input is working:

I tried this:

And this:

But I will always get this:

or this:

No change in the error if I put a domain name in or not.

  • my pihole runs in a LXC container on proxmox (without docker)
  • Hardware is perfect

Actual Behaviour:

Why is my entry not a valid IPv4 address?

Debug Token:

https://tricorder.pi-hole.net/0TpPS54F/

The issue reported by the 2 red alerts above is the same: you tried to add 192.168.9.1/24 (including the /24) as server IP.

The Server IP column accepts only IPs (192.168.9.1, without the network range).

Please try this again, but make sure the Server IP is just an IP:

Also, make sure you check the checkbox, to enable the line, like this:

revservers

Are you checking the "Enabled" box on the left? If so, I cannot reproduce the behavior you see. Even when I don't check the box, it doesn't give an error but does not add the line (since I didn't enable, I suppose).

EDIT: Oh yeah, what @rdwebdesign said. :slight_smile:

I recommend to not use "test" as a DNS search/suffix domain bc that one is reserved:

$ cat /etc/pihole/dnsmasq.conf
[..]
# RFC 6761: Caching DNS servers SHOULD recognize
#     test, & invalid
# names as special and SHOULD NOT attempt to look up NS records for them, or
# otherwise query authoritative DNS servers in an attempt to resolve these
# names.
server=/test/
server=/invalid/

Configure any of below ones:

lan
intranet
internal
private
corp
home
home.arpa

Of which the last one is the most secure one and intended for private use:

EDIT: Oh below my revServers for my 10.0.0.0/24 network plus DHCP server at 10.0.0.2:

$ sudo pihole-FTL --config dns.revServers
[ true,10.0.0.0/24,10.0.0.2,home.dehakkelaar.nl ]

Actually that's .internal since a couple of years : ICANN approves use of .internal domain for your network :slight_smile:

But basically whatever floats your boat from the list you have posted as far as I am concerned...

No, home.arpa is registered and internal is not:

$ xargs -n1 whois <<< 'lan. intranet. internal. private. corp. home. home.arpa.'
No whois server is known for this kind of object.
No whois server is known for this kind of object.
No whois server is known for this kind of object.
No whois server is known for this kind of object.
No whois server is known for this kind of object.
No whois server is known for this kind of object.
[..]
domain:       HOME.ARPA
[..]
contact:      technical
name:         Internet Assigned Numbers Authority (IANA)
organisation: Internet Corporation for Assigned Names and Numbers (ICANN)
[..]
remarks:      This domain is administered as part of the .ARPA zone
remarks:      management, described at https://iana.org/domains/arpa

Then I am hereby officially confused and happy I have never switched from .lan to .internal just because I don't like it cosmetically :grimacing:

There is also the mDNS RFC appendix G:

Appendix G.  Private DNS Namespaces

   The special treatment of names ending in ".local." has been
   implemented in Macintosh computers since the days of Mac OS 9, and
   continues today in Mac OS X and iOS.  There are also implementations
   for Microsoft Windows [B4W], Linux, and other platforms.

   Some network operators setting up private internal networks
   ("intranets") have used unregistered top-level domains, and some may
   have used the ".local" top-level domain.  Using ".local" as a private
   top-level domain conflicts with Multicast DNS and may cause problems
   for users.  Clients can be configured to send both Multicast and
   Unicast DNS queries in parallel for these names, and this does allow
   names to be looked up both ways, but this results in additional
   network traffic and additional delays in name resolution, as well as
   potentially creating user confusion when it is not clear whether any
   given result was received via link-local multicast from a peer on the
   same link, or from the configured unicast name server.  Because of
   this, we recommend against using ".local" as a private Unicast DNS
   top-level domain.  We do not recommend use of unregistered top-level
   domains at all, but should network operators decide to do this, the
   following top-level domains have been used on private internal
   networks without the problems caused by trying to reuse ".local." for
   this purpose:

      .intranet.
      .internal.
      .private.
      .corp.
      .home.
      .lan.

Thank you all very much, it seems like I was just stupid.

I also did try without a domain name, but this did not work either.

I think the checkbox I did not check was the problem.

And yea I know the red error read the one IP not correctly, idk why.

I think there is a small bug in the error checking on that page.
If your first attempt is invalid, you will receive an error message. Then (without reloading the page), you try using the correct value, but the function sends both versions, causing the same error message. Reloading the page fix the issue.

I will fix the code.

Thank you very much!