TLDR: When blocked, some clients retry solving their domains by appending the search domain (e.g. google.com.fritz.box). This will not return anything but the Pi-hole will still forward it to REV_SERVER_TARGET. This is wasteful, so Pi-hole should implement an internal filter with only forwards legitimate requests in the form of
^(?<hostname>[a-z0-9-]+)\.(?P=REV_SERVER_DOMAIN)$
In the case above, it would detect the dot as an invalid character, so it wouldn't waste time forwarding and trying to resolve this. See my mockup above for how that could look.
Another small opportunity for optimization I came across is:
Type
Domain
Status
Reply
PTR
lb._dns-sd._udp.0.0.168.192.in-addr.arpa
Blocked (external, NXRA)
NXDOMAIN (2.9ms)
PTR
lb._dns-sd._udp.###.###.64.100.in-addr.arpa
OK, answered by localhost#5053
NXDOMAIN (28.6ms)
PTR
lb._dns-sd._udp.lan
Blocked (regex blacklist)
BLOB (0.2ms)
Only the last one got caught in my RegExp (previously it used the BLOCKINGMODE but I changed the OP to reply with NXDOMAIN instead). DNS-SD is not supported in my network, and the devices keep retrying, so instead of forwarding those requests to the upstream server, I just blocked them with
Those request should've been covered by an option similar to Never forward reverse lookups for private IP ranges (which works in conjunction to server=//192.168.0.1).
I also changed the title from Don't forward bad hostnames to Don't forward bad requests.
I use DNS-SD myself for printer, scanner and multimedia discovery (and many others, too), so I wouldn't want to have this enabled by default.
Yes, but this option doesn't apply here. We use dnsmasq's config option bogus-priv to achieve this, however, it blocks only forwarding of address-in-arpas. To be more precise, the function in_arpa_name_2_addr() is called on your domain and when it sees anything non-numeric (like lb), it says: "Not my business - handle as usual", not extracting the address and, hence, not triggering the bogus-priv option.
In the end, this all seems to become more and more tailored and I rather think this should either become part of an existing FAQ like
or maybe even become its own Wiki article where users can properly describe and add their own findings. This way, users can subscribe to these topics and always get informed if new things are added.
I wouldn't want them to be in the Commonly blacklisted domains because they are interfering with "regular" DNS activity and only really intended as an optimization for a subset of users, i.e. not using PI-hole as DHCP and using Conditional Forwarding. I think it's own Wiki article is a decent compromise, but I wasn't even aware of a Commonly blacklisted domains thread (I only knew about the counter part), yet alone a potential Conditional Forwarding blacklist thread (which could be this thread right here). But I guess the "gains" don't really warrant a more prominent solution.
The only downside of doing it like this is that I have a bunch of crap in my Top Blocked Domains now (e.g. tracker.ipv6tracker.ru.lan). And everytime I spot one of those, I have to manually hide them via the API Setting. Not a big deal, but doing that internally, and maybe additionally hiding them from the Query Log, would certainely be helpful. Sometimes, when I'm looking at the Query Log (= last 100 queries), it only goes back 20 seconds or so, which can displace the information I'm looking for (because of all the spam). I did file a bug report for the offending application, but with this simple RegExp, I can cut the requests by 33%.