Hello there. This is a question for devs or anyone else familiar with the codebase
I want to get rid of the "pi.hole" hostame entirely, so it does not resolve to anything, unless I add it to the DNS system somewhere.
My network has it's own internal DNS (I have a small intranet for various internal services) and the Pi-hole VM has it's own hostname and PTR record behind a local domain. There's no reason for an extra domain to exist, it serves absolutely no purpose. Other than to bother me with it's existence
I had a (very) quick peak in the code and I do not see any visible option to disable the extra resolution logic for this hard-coded hostname (only change the IP address which it resolves to). Did I miss anything or is modifying the code the only way to completely get rid of the "pi.hole" domain ?
I can patch-out the resolution logic myself and rebuild the FTL, that's not a problem for me.
But I wanted to ask beforehand if there's a better way to do it without modifying the code. I really do not want to have to rebuild the FTL server after every update.
If nothing else, it does allow us to provide working URLs when trying to guide you to a certain UI information or interaction, and it also allows respective diagnostic lookups we request in troubleshooting to resolve uniformly across Pi-hole installations. EDIT: This is particularly true in more complex situations where the machine hosting Pi-hole would be part of several subnets, which potentially would require many hostname to IP address associations otherwise, and would make replying with the correct contextual IP a trifle difficult if handling that by hosts definitions.
I already had PIHOLE_PTR set to HOSTNAMEFQDN (the option to resolve it's own FQDN) and it worked fine. Having Pi-hole resolve it's own FQDN isn't of much use to me though as I already have a BIND server handling internal DNS.
Also, setting PIHOLE_PTR option does not disable the "pi.hole" domain, it still resolves and there's no option to disable this without recompiling since this behavior is hard-coded.
Thankfully, the FTL code is relatively easy to read and the "pi.hole" domain code was not hard to disable by just commenting it out. It was a surprise to me how much extra code was added just to handle a single hard-coded domain.
Is there a technical reason why the hard-coded "pi.hole" domain was implemented this way ?
Why not keep it simple and just use the hosts file ? Pi-hole can already resolve entries from it's server machine's /etc/hosts file even for remote clients and can even emulate PTR (reverse) records.
I can just add "pi.hole" to server's /etc/hosts and it will work just fine without any hardcoding.
The reason is that it allows Pi-hole to reply dynamically with the most suitable IP address for the requesting client. The reply will be
127.0.0.1 if requested over lo,
192.168.0.123 if requested over eth0,
10.100.0.12 if requested over wg0, etc.
Doing this via a HOSTS file is surely doable, too, however, it is complicated and error-prone considering volatile interfaces, especially with VPNs going up and down while FTL is constantly running.
This is somewhat mentioned in the code region your have checked, however, looking from this angle, I do see that one might only be able to get this interpretation from the comment when one already approximately knows what is happening:
It is probably most obvious when looking at the immediately related debug output:
Thanks for the thorough explanation. I didn't dig that deep into how the actual resolution logic works, my goal was to simply disable the hard-coded domain with as little changes to the code as possible so I can easily apply the same patch after an update.
The logic does indeed make sense if you run Pi-hole on multiple interfaces, especially if they have dynamic IPs. In my case, I only have a single network interface with a static IP address so disabling the code will likely do no harm (Do correct me if I'm wrong !).
What I still don't understand though is why the "pi.hole" domain resolution is hard-coded to always work, even if the server has a domain name assigned. Some users may not want to expose the fact that they are running DNS filtering software.
Also hard-coded DNS smells badly to me. The domain name should at the very least be made configurable. It would also be nice to have an option to disable the hard-coded domain resolution logic entirely and treat the server's domain just like any other domain (that's what I did with my changes).
The domain is only used for administration purposes, DNS clients do not need it or use it.
We discussed this internally and came to the conclusion that allowing to change the hard-coded domain isn't what we want for reasons already mentioned above by @Bucking_Horn. Furthermore, there was the argument many/most routers do the same and offer some hard-wired domains like speedport.ip or fritz.box pointing to themselves. Pi-hole basically does the same.
I've stumbled upon your discussion when searching for a way to disable the hard coded domain. I strongly disagree with your conclusions. Cheap router OEM firmwares aren't exactly the best examples to follow. Also, they likely use really simple ways to make their DNS names work, not hard-coded strings in C code. I would be surprised if it is something more than just an entry in dnsmasq's configuration file.
It should be relatively trivial to add a single configuration option and use that instead of a hard-coded string constant. Non-techie users (the great majority of those who ask for help) will never change the default domain anyway, so there won't be any harm.
This way you will not alienate power users who want more control over their DNS.
The beauty of GPL is that the code is freely available. I can make changes and rebuild your code if I want to. But I would very much prefer not to do it.
As another data point, I'm grateful for Pi-hole's ability to resolve pi.hole itself across available interfaces. I find it to be a very useful fixed point of reference to test whether or not Pi-hole is correctly acting as the DNS on a network. In particular, keeping it enabled and hard-coded within Pi-hole itself, and out-of-band with respect to the standard OS services, makes the result that much more trustworthy.
In the end this seems quite some controversial topic even though - interestingly enough - this is the first time this request has come up. I have since then heard not that many voices but those who spoke up had quite diverging opinions both in this thread but also via DM.
Overall, I don't think we should change something right now. However, note that we are pretty advanced in the next-gen Pi-hole v6.0 development where you will have a setting
which could easily be understood as being the (currently hard-coded) domain in question here. I could even imagine that setting this variable to an empty string disables the hard-coded domain and also serving the web interface on this domain (even if it is still pointing to your Pi-hole via other means). Serving via IP still seems reasonable in this case.
I'm not yet really convinced about this extension and am still collecting opinions here on this proposed change. I'm sorry, the process surely seems to be a long one on this, however, I want to make sure we are not introducing something we "regret" having done next/in a few years from now.
I agree it's never a good idea to rush with changes. Well, unless you have a security vulnerability.
My personal opinion is that there should be as little non-configurable hard-coded functionality as possible. A DNS server should not have domains permanently "baked" into it. Having a pre-defined "default" domain for accessing the admin console IS useful, but the way this domain is currently implemented isn't the best.
But other users and developers may have different opinions and I will respect them.
As I've mentioned before, the beauty of FOSS is that anyone is free to modify the code to better suit their needs. If ultimately you decide not to include an option, I can always tweak the code to remove the domain.
