PTR-Records

General Beta 5.0
1

Please ensure that you are running the latest version of the beta code.
Pi-hole version is v4.3.2-391-ge0b3405 (Latest: v4.3.2)
AdminLTE version is v4.3.2-360-g88da85f (Latest: v4.3.2)
FTL version is vDev-a90f14b (Latest: v4.3.1)

Problem with Beta 5.0:
My Pihole is flooded by *.in-addr.arpa-Requests, answerd by N/A or NX-Domain.

image
image726×908 58.5 KB

Perhaps a bug?

My architecture:
Router: 192.168.2.1
Gateway: 192.168.3.1
Pihole: 192.168.3.5
Pihole managed Subnet (DHCP/DNS):
DHCP-Range:192.168.3.100-192.168.3.199
static IPs: 192.168.3.2-192.168.3.99
DNS-Forwarder: 127.0.0.1#5353 (unbound)

Debug-Token: fv3z7gb98d

Ps.: most of these queries are initiated by the Gateway-Server

image
image1784×1400 309 KB

image
image1766×1270 299 KB

2

Do you have Conditional Forwarding on?

3

no, I don't have.

4

No, this should also have been there before switching to v5.0 beta since

so this seems to be completely outside the scope of Pi-hole.

Pi-hole itself is generating one PTR per client once an hour to ensure it always knows the most recent client host name for displaying.

5

The clients ask the Gateway, the Gateway request the Pihole. Why answers Pihole with NXDOMAIN or N/A when the PTR should be correct?

6

Pi-hole is providing its answers as received by its upstream DNS.

A reverse lookup for 51.145.143.28 -as provided by your screenshot- does also result in NXDOMAIN on my machine.

As your gateway seems to issue those requests, try to find out why it does so.

I also noticed:

Your router seems to be on a different subnet than your gateway - is that by intention?

7

Yes, it is. I use NethServer for Proxy/Web filter, Firewall, DPI, Net monitoring ...
192.168. 2 .0/24 = RED
192.168. 3 .0/24 = GREEN

I recognized the documented behavior after parallel fresh installation oh my Pihole-System and Nethserver. As upstream DNS-Server I use unbound with qname-minimisation: yes for a long time.

8
So we have established that Pi-hole is initating PTR requests once per hour, per client.

You should be able to verify those requests on your network as well:
They are orginating from localhost on the hour.

And we have checked that Pi-hile is indeed providing the correct answer for your queries.

And your screenshots also show reverse lookups for local address ranges to be resolved correctly.

You have further confirmed that your network makes use of several subnets, as you intended.

Conclusion sticks that there would be nothing wrong with Pi-hole, but rather: