Pi-hole forwarding *.0.0.0.10.in-addr.arpa PTR queries

[Aydo]

Please follow the below template, it will help us to help you!

Hardware: Raspberry Pi 4
OS: Debian 11 Bullseye 64-bit
Pi-hole v5.8.1
AdminLTE v5.10.1
FTL 5.13

Expected Behaviour:

To my knowledge Pi-hole should not forward lb._dns-sd._udp.0.0.0.10.in-addr.arpa PTR queries. After reading /etc/dnsmasq.d/06-rfc6761.conf which states that RFC 6761 requests that PTR requests for private IP range should not be forwarded and that the dnsmasq option bogus-priv provides that. Which the dnsmasq man page is consistent with and states:
Bogus private reverse lookups. All reverse lookups for private IP ranges (ie 192.168.x.x, etc) which are not found in /etc/hosts or the DHCP leases file are answered with "no such domain" rather than being forwarded upstream. The set of prefixes affected is the list given in RFC6303, for IPv4 and IPv6. As far as I can tell both RFC's are similar.

Pi-hole's logs show about 167 PTR queries per day being forwarded to upstream DNS.

13:33:09: query[PTR] lb._dns-sd._udp.0.0.0.10.in-addr.arpa from 10.0.0.55
13:33:09: forwarded lb._dns-sd._udp.0.0.0.10.in-addr.arpa to 2606:4700:4700::1001
13:33:09: reply lb._dns-sd._udp.0.0.0.10.in-addr.arpa is NXDOMAIN
13:33:29: query[PTR] lb._dns-sd._udp.0.0.0.10.in-addr.arpa from 10.0.0.53
13:33:29: forwarded lb._dns-sd._udp.0.0.0.10.in-addr.arpa to 2606:4700:4700::1001
13:33:29: reply lb._dns-sd._udp.0.0.0.10.in-addr.arpa is NXDOMAIN
13:34:21: query[PTR] lb._dns-sd._udp.0.0.0.10.in-addr.arpa from 10.0.0.54
13:34:21: forwarded lb._dns-sd._udp.0.0.0.10.in-addr.arpa to 2606:4700:4700::1001
13:34:21: reply lb._dns-sd._udp.0.0.0.10.in-addr.arpa is NXDOMAIN
13:34:46: query[PTR] lb._dns-sd._udp.0.0.0.10.in-addr.arpa from 10.0.0.51
13:34:46: forwarded lb._dns-sd._udp.0.0.0.10.in-addr.arpa to 2606:4700:4700::1001
13:34:46: reply lb._dns-sd._udp.0.0.0.10.in-addr.arpa is NXDOMAIN

Pi-hole is not DHCP, so I don't have a leases file, but here is my hosts file:

127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

127.0.1.1       pihole

# DNS
1.1.1.1         v4-1
1.0.0.1         v4-2
2606:4700:4700::1111    v6-1
2606:4700:4700::1001    v6-2

I do have a 10-custom.conf in dnsmasq.d for hostname mapping. It follows dnsmasq's host-record option for hostname resolution

host-record=hostname,10.X.X.X,2603:8000:XXXX:XXXX::XXXX

Is there something I'm missing in the RFC's or am I correct in expecting Pi-hole to automatically return NXDOMAIN for those queries?

Debug Token:
https://tricorder.pi-hole.net/v0txdKPU/

[Bucking_Horn]

It seems possible to meet your expected behaviour by adding respective custom configurations for the private reverse domains (e.g. local=/10.in-addr.arpa/)., but it's the behaviour of dnsmasq's bogus-priv that you are putting under scrutiny here, and whether that is intended and/or can be expected to be the "configuration option (...) to enable upstream resolution of such names" as mentioned in RFC6761, section 6.1.4.

@Aydo

lb._dns-sd._udp.0.0.0.10.in-addr.arpa

Although it looks similar, the above is not a reverse lookup for a private IP.

It is an RFC6763 DNS service discovery request (in your case, for the legacy browsing domain) as used by zeroconf clients, often in conjunction with wide area mDNS (like Apple's Bonjour or Linux' avahi), to gather informaton about services in your network, e.g. to allow discovery of AirPrint printers in the same subnet even if they'd reside in another network segment.

While this means that dnsmasq's documentation is in line with its actual implementation, your expectation of dnsmasq returning NXDOMAIN immediately seem not entirely unjustified, inasmuch RFC6761 states that "caching DNS servers SHOULD, by default, generate immediate (positive or negative) responses for all such queries (...) to avoid unnecessary load on the root name servers and other name servers", where "all such queries" refers to the private range in-addr.arpa domain names "and any names falling within these domains", which would include your DNS-SD request.

However, this is not a requirement (as it reads SHOULD, not MUST).

As this is discussing behaviour of dnsmasq, your concern should probably raised in the official dnsmasq mailing list) as well.

That said, as pihole-FTL is based on dnsmasq, Pi-hole's developers have added improvements or extensions that have been submitted as patches for upstream dnsmasq on occasions when feasible.
It would still depend on the code that's affected, i.e. pihole-FTL or dnsmasq, and on dnsmasq acceptance in case of the latter.