IMO that would still be better than just generating pointless traffic between Pi-hole and DHCP server. And it's not even just the traffic; those garbage request also slow down the whole blocking process which will result in unnecessary delays. But I can see how that can be annoying to setup (even though you would only have to do it once).
I don't even know if office.lan is a realistic scenario because those people are probably using their Pi-hole as DHCP server anyway since I doubt many routers would even allow you to use such a configuration (mine doesn't even allow me to change the search domain).
Either we have to come up with a better solution or just refer to this RegExp somewhere. At the end of the day, it's just wasteful not to.
You should not overrate this issue.
Search domain expansion is a client side thing - it is expected to happen, and it is happening regardless of Pi-hole being your DNS server or not.
Whether Pi-hole would block, answer or forward your requests - it is a client side software that issues them and waits for them to finish. The most Pi-hole would do here is add its own latency to the lookup.
I say "client side software" because it's important to note that a majority of those requests will be prompted by manual nslookups - e.g. a browser would rarely choose to add the search domain.
The waste you anticipate may thus be much smaller than you fear it to be. 
Unfortunately, the issue is much more severe on my end. I'm using Transmission with a multitude of different BitTorrent trackers and it will try to resolve some of the dead ones four times (A, AAAA, A+search domain, AAAA+search domain) every minute.
Anyway, I've created a quick mockup of what such a setting would look like:
Again, it is the client (software) that issues those requests to begin with.
You'd gain the most unburdening effect if you'd find a way to stop the client from issuing those requests in in the first place.
"Block garbage requests ..."
Den een sin Uhl...
Whether a domain would be 'Garbage' lies in the eye of the beholder.
I'd very much presume we'd have far more users complaining about failing resolution for local hostnames than for increased DNS query volumes of their Bittorrent clients (isn't the default for BitTorrent trackers to check every 30 minutes?).
If you are intent on forcably disabling search domain expansion, I'd first recommend to solve the issue on the machine that creates it, i.e. to configure the software accordingly, or if that's not possible, to disable or remove the search domain from your TransmissionBT client machine.
If that's not feasible (e.g. because it is not supported, or because it is a joint purpose host where other parts require search domain expansion), you could apply aforementioned custom dnsmasq configuration by creating a new config file containing:
local=/mylocaldomain/
Restart Pi-hole afterwards for that setting to take effect.
Doing so means accepting the consequences: Depending on your exact setup, expect resolution to fail for local FQDN hostnames (e.g. myphone.fritz.box).
Note that some (Windows) components may append a plain hostname by the local domain by default, e.g. expect ping myphone to fail as well, even if there's seemingly only a plain hostname involved.
Wtf is that even supposed to mean? Of course the client is issuing those requests.
Okay, so I could write a script which does a DNS request for the tracker domains and removes them (tracker die and come back again so I would then have to readd them), so when Transmission does it's own DNS request it wouldn't try to resolve the dead ones. Do you realize how stupid that sounds? Doing a DNS request to not do a DNS request?
It's a garbage request. It's the client doing a last ditch effort. It's wasting time, resources and electricity.
Don't focus on the client, it was just an example. I have similar request all over my log, it's just that the trackers were the worst offenders.
Say what now? With all due respect (I know you're just trying to help), you reply was pointless and if this forum had a downvote button, you would've earned one by now. I'm suggesting a free optimization, which would benefit literally everyone, and all you say is not helpful at all.
I can just keep using my RegExp and live with that, but it though that this would be neat little thing that the whole community could benefit from. Why am I being met with such resistance? Please refrain from commenting unless you have something meaningful to say.
I didn't recommend to write any scripts.
I suggested you investigate if you could configure your client software to avoid those request, or to strip the search domain from the configuration of the host that runs your TranmissionBT software, or -in case both of those were not possible- to apply a custom dnsmasq configuration to your Pi-hole.
It's up to you how to respect that advice.
1 Like
You are receiving candid feedback. The feature request remains open, currently at 2 votes.
- This request is not about Transmission. I wouldn't have created a thread in Feature Request if I needed help with my BitTorrent client.
- I can't fix that because the trackers are added when they're alive and then they die while the torrent remains active.
It's feedback yeah, but it's of the unhelpful kind. The only useful feedback was from yubiuser, where they asked about the ability to resolve <hostname>.<subsearch>.<search>, which I already acknowledged by saying that it's highly unlikely do be an issue in the real world but warned about in my mockup nonetheless. The rest of this thread was not worth reading and will definitely get in the way once a dev shows up who wants to implement this.
We read everything.
That being said, it's not likely to be implemented. The cost to doing it is way more than the benefit of the possibly nanoseconds of gain. Let DNS do DNS and answer what clients have asked for. If the clients are misbehaving then fix the client.
1 Like
Or you could be like me and the others that use .lan as a TLD and have hundreds of computer.lan, client.lan, server.lan entries and would need to manually enter all of those to not be blocked.
The risk and increased load of support to implement this just isn't worth it to me.
Cost = free (it's a checkbox).
Benefit = in the houndreds of milliseconds (measured my DHCP server).
You use your Pi-hole as a DHCP server right? Then this FR is indeed not directed at you.
Nope, my router is my DHCP server and it uses EDNS0 to forward the queries to Pi-hole.
Cost = we have to code it and then support it.
I'm a developer, if you'd like me to ignore it then I'm happy to.
It costs you nothing to refer to my RegExp in the wiki. As a matter of fact, give me the edit rights and I'll create the entry myself right now since it's so much trouble for you.
Hundreds of milliseconds response time from the DHCP server either means it's forwarding the query upstream itself or it is really slow at responding. Or a combination of both. I don't think it should happen. For me, average upstream delay us on the order of 20 ms, I'm not sure what you numbers would be?
Some information bits are missing for me, maybe they just got lost whilst I was reading this discussion. Conditional forwarding is used. But what did you configure as local domain in REV_SERVER_DOMAIN
as this will have an influence here. It distinguished whether the request is rather block (a) some arbitrary domain or (b) the exact domain defined in REV_SERVER_DOMAIN.
For case (b) I could imagine a checkbox like "Forward local domain hostnames` (defaulting to ticked).
If the DHCP server is working correctly, it should also resolve hostnames appended by the local domain. I guess we're only talking about non-existant hostnames here? Please refresh my memory, there was a lot of text to read here early this morning.
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
^lb\._dns-sd\._udp\..+\.in-addr\.arpa$;reply=nxdomain
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%.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.