Sometimes there are some garbage requests in my network in the form of <fqdn>.<searchdomain> (e.g. google.com.lan), and since I don't use my Pi-hole as a DHCP server, they will get forwarded to my router. Those requests will obviously not return anything (NXDOMAIN), so it's just a waste of resources.
To prevent the forwarding of them, I wrote this RegExp, which checks for disallowed characters in the hostname (I previously also checked if hostname>63 but tests showed that that never happens):
[^a-z0-9-].*\.lan$;reply=nxdomain
If you use Conditional Forwarding, Pi-hole should automatically do what this RegExp is doing and filter out these pointless requests.
Anything *.localdomain like something.lan is usually a Windows client. Windows will add the local domain to a lookup if there is not a response back for the initial lookup. Not much you can do about it.
Yeah, I figured that the client is retrying with the search domain. But you agree that it's pointless to forward those requests, right?
You would specify office.lan in REV_SERVER_DOMAIN. If you need both, I don't know. Maybe a checkbox or the ability to specify multiple REV_SERVER_DOMAINs.
That's not how it works:
You'd have to use the local domain aka search domain aka search suffix for Conditional Forwarding - in the above example, that would be .lan.
If it would have been .office.lan instead, you'd also see respective queries for google.com.office.lan.
You could decide to configure Pi-hole to forbid any forwards for the local domain.
In fact, this is what Pi-hole would enforce if its acting as DHCP server and Never forward Non-FQDNs is ticked.
If you decide to assert this also when your router or another device is acting as DHCP server (by way of custom dnsmasq configuration), this would in turn force you to manually define all your local names in Pi-hole, as CF may never be able to to retrieve results from your DHCP server anymore.
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.
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 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.
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.
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.
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.
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.
