See
Yes that is what I was looking for!
Anyone looking for the documentation should go to:
https://docs.pi-hole.net/ftldns/configfile/?h=pi.hole
(maybe add that link in the pihole-FTL.conf file? or create a pihole-FTL.conf.example with all the relevant setting)
The is no mention of documentation on https://pi-hole.net/ and the install button redirects to github and there is no mention of it either.
I did some searches on github, but was unable to find the link, I now see there is a link on the "wiki" page.
1 Like
That would be a weird solution. I just find the whole hardcoded "pi.hole" a bad idea, but that's just my 2ct's. Making it configurable is even a step further.
DNS should be handled by the DNS server not the config file.
When you configure dnsmasq or bind or whatever other DNS server, local records are stored somewhere on disk as well. We just happen to have only one config file for everything.
Pi-hole is typically the only application running on a device and often enough it is even the very first Linux project users ever try. We want to make it as easy as possible for them while still allowing advanced user to disable all these extra-"convenience" features easily.
Most routers do it similarly, like fritz.box or o2.box I remember, and at least in the letter case it couldn't be configured. So while I'm personally also no fans of this, it is not uncommon and makes documentations and install/setup instructions easy for users who don't know how to detect IP addresses or hostnames of devices in their LAN.
Oh I understand the reason behind it, PiHole is one, if not the best "my first linux" project's out there. And making sure the user is able to reach the pi-hole server even when mis-configured and/or having an easy way to reference to the url in documentation like "go to pi.hole" instead of "go to the IP you configured in step 3"
But for more advanced configurations changing the way DNS works and hardcoding hostnames that overwrite other configurations is a potential problem.
Like I said, if it's mentioned in a (new/example) configuration file somewhere it should be okay or just a new configuration value PIHOLE_PTR=true in pihole-FTL.conf so a change can be seen, but I would prefer it's in /etc/dnsmasq.d/00-pihole or somewhere along those lines and let DNS handle it, like the suggestion about a 99-ptr.conf file
It's probably worth mentioning that the hostname as configured on a device is genuinely known on that device only. Most importantly, setting the hostname on a device does by itself not add any DNS records.
Until recently, Pi-hole has written definitions for both your device's hostname as well as pi.hole to its local.list. Without that, you may not have been able to resolve Pi-hole's hostname at all.
While you could expect such a hostname to be resolved in your network or at least on your current link, there is no guarantee that it actually would (click for details)
There are two common mechanisms that would allow hostname resolution in a local network:
(1) An mDNS-aware host may register its name with any other mDNS-capable host on the same link as somehostname.local.
Note that mDNS is not employed by all applications alike, i.e. while you can ping somehostname.local from one mDNS host to another, a browser typically does only use DNS.
mDNS does not work if no mDNS software is installed on a host.
It only ever allows resolution among mDNS-aware hosts.
(2) Your client may register its hostname with a DHCP server during DHPC lease negotation.
The DCHP server may then register that name with its internal DNS server. Note that this is not a requirement - there are routers that do not auto-create DNS entries for DHCP leases. While such a router would be able to list devices by name, its clients would not be able to resolve each others names by DNS means.
Those routers that do register DNS records automatically may allow to edit a device name via their UI, e.g. to change android-9b4c89de95893fab.fritz.box into samsungphone. It would depend on the router whether that would create a new DNS record or alter an existing one.
On a FritzBox, above example would result in your FB returning two names for a reverse lookup of that phone's IP address. Mind that Windows nslookup may return just the first name.
The DHCP-based DNS approach does not result in resolution of a host's name if
(a) a host device doesn't register its name via DHCP
(b) a DHCP server does not auto-register respective DNS records
Pi-hole has always supplied DNS records for pi.hole, so the hard-coding part has not changed. It seems not unreasonable to me that Pi-hole would add its own name to its DNS records.
The difference between Pi-hole releases seems to be that now Pi-hole is limiting reverse lookups to replying just pi.hole, while at the same time improving by doing so for all known IP addresses, not just the ones from local.list.
Pi-hole would still respect hostname definitions for forward resolution requests, but does not auto-create the respective DNS records any more.
In general, it would be recommended that a reverse lookup should only return the single canonical name for a given IP. It also seems logical that Pi-hole would resume that pi.hole would be canoncial for itself.
Your justified preference would be to use the hostname of your choice, which seems to be what DL6ER is suggesting.
As other DNS servers also return multiple names for a given IP address, it may also be an option to answer all known hostnames instead.
The order may be significant here to achieve the previous behaviour of certain client software (e.g. Windows nslookup).
(emphasis above is mine).
I like your suggestion of linking that documentation, jeroenvdb - maybe local.list would be an obvious choice?
I discovered this because remote logging for my pihole server pi (which I've set to use hostname) switched to pi.hole.
PTR_PIHOLE=false in pihole-FTL.conf seems to have no effect.
Creating 99-ptr.conf with ptr-record=10.1.0.10.in-addr.arpa,pi (my pi's address is 10.0.1.10) gets me closer:
$ nslookup 10.0.1.10
10.1.0.10.in-addr.arpa name = pi.
10.1.0.10.in-addr.arpa name = pi.hole.
But rsyslog apparently prefers the second, so no dice.
You did restart Pi-hole's DNS resolver?
I believe so.
Full session:
root@pi:~# cat /etc/pihole/pihole-FTL.conf
AAAA_QUERY_ANALYSIS=no
PRIVACYLEVEL=0
root@pi:~# nslookup 10.0.1.10
10.1.0.10.in-addr.arpa name = pi.hole.
root@pi:~# emacs /etc/pihole/pihole-FTL.conf
root@pi:~# cat /etc/pihole/pihole-FTL.conf
AAAA_QUERY_ANALYSIS=no
PRIVACYLEVEL=0
# https://discourse.pi-hole.net/t/how-to-disable-pi-hole-dns-record/49606/6
PTR_PIHOLE=false
root@pi:~# pihole restartdns
[✓] Restarting DNS server
root@pi:~# nslookup 10.0.1.10
10.1.0.10.in-addr.arpa name = pi.hole.
root@pi:~#
I believe you've discovered a typo in the posts here. 
According to the doc draft, it should read
PIHOLE_PTR=false
EDIT: I'll try to amend that above.
1 Like
Yup, working now. Thanks!
All the Pi-Hole documentation is still in draft? If I go to: https://pi-hole.net/, then click "install pi-hole" then scroll up on github so the menu bar is visible, then click "Wiki" it states: Note that the most recent documentation can he found here: https://docs.pi-hole.net, then click the link and go to: "https://docs.pi-hole.net/" (without the deploy-preview) and if I then look at FTLDNS -> Configuration, or use the search function and search for "pi.hole" I can see " PIHOLE_PTR=true option there.
So the option is there and documented, it's just hard to find. (hence my suggestion to make a link from pi-hole.net to docs.pi-hole.net and in the mentioned config files, since you now host the documentation yourself there is less change of a link not working)
I have never seen pi.hole in any configuration or DNS reply (maybe in a default configuration, but that's years ago), and it might have shown as "unknown" for some users. Until the recent change.
I'm not really sure what you mean. With mDNS, sure, it's all UDP and broadcast.
But the whole point of Pi-hole is a central, robust, caching, adblocking DNS server with a lot of great features and easy to manage. Not mDNS but real DNS, with a server that should reply with a correct forward and reverse DNS.
I have never been in a situation that I had to rely on mDNS for internal DNS resolution for at least 10 years, with Windows domaincontrollers in the past and the last years Pi-Hole since the configuration and features are WAY better.
The hostname for my Pihole was (and was always set) in "Local DNS Records" this ends up in "custom.list" and get's loaded when FTL is restarted.
DNS was set static just like the IP, however this gets overwritten by pi.hole if you DONT explicitly set the PTR_PIHOLE=false in /etc/pihole/pihole-FTL.conf
It was also possible to see the chain of configuration: /etc/dnsmasq.conf loads: /etc/dnsmasq.d/* that loads addn-hosts=/etc/pihole/local.list and addn-hosts=/etc/pihole/custom.list etc.
Until the change, my pihole always returned the correct forward and reverse DNS, so when I went looking at the configuration files, there is NO mention of pi.hole, however my pihole is suddenly replying with this new name.
So the situation is now:
/etc/hostname has no effect (I'm not really sure that's the correct behavior, but fine)
/etc/pihole/custom.list has no effect and there is no mention of a DNS record pi.hole (the correct IP and matching hostname are in there, but are ignored)
/etc/pihole/local.list has no effect and there is no mention of a DNS record pi.hole (whats the purpose for this file?)
So my point is: it should be more clear. It's your project and what you do with with it and how you implement it. But leaving out critical information (or overwriting customized settings) might lead to confusion when looking at configuration files or a webinterface.
A long time ago the pi reply'd with server: unknown/IP, not sure what happened, some config file or something I messed up, but a DNS server that does not know it's own name.... yeah. So, I add the IP and hostname in the webinterface via "Local DNS Records" verify: awesome, forward and reverse DNS works like I expect with the address and IP as configured.
But somehow this all changed after the last update and the pi has decided to change his name to pi.hole. So now:
If you want to set the DNS record of a host within the network you can set it via
/etc/pihole/custom.listor in the webinterface via "Local DNS Records" EXEPT if you want a hostname for the Pihole itself, then you have to setPIHOLE_PTR=falseandPIHOLE_PTR=<HOSTNAME>* in/etc/pihole/pihole-FTL.conf
*not yet implemented
Dont get me wrong, I understand the reasons behind it and I have fought with a lot of docker containers over the years to get them to work like advertised.
But if you put more settings in pihole-FTL.conf and can't rely on proper DNS resolution and configuration files of dnsmasq what can you trust?
Default: pi.hole: yes, but make it a toggle button on the webinterface 'Let FTL handle pi.hole record' so it can work like before the change. (don't overwrite custom.list)
No.
We decided to make this behavior internal because the hostname being defined in local.list had two severe drawbacks: If you have multiple IPs available at your device, only one of then was picked. But, more important, if the addresses change (for many users the IPv6 prefix changes daily), then this record would become useless. Even more, AAAA pi.hole would point to an address that may be ancient and not reachable.
Hence, we decided to move this inside FTL where the currently used IP addresses are available for replying.
local.list is now being used to automatically add DNS records when OpenVPN is installed as well on the system (the wisdom is taken from /etc/openvpn/ipp.txt and updated on gravity runs).
We could add a hint (comment) about internal handling of pi.hole to the local.list file if you'd consider this helpful. dnsmasq can do a lot but it cannot do some things, hence,
is limiting us. I'm not really seeing what the issue is with replying on dnsmasq config lines and Pi-holes config as well? Before this change, the IP address was taken from setupVars.conf, now it is automatically determined. One config file less in the chain, actually.
For Pi-hole v6.0 we will have a full (automatically generated) config file with comments and everything, see here:
(this post is old and does not contain PIHOLE_PTR but you get the idea)
No, this
went live yesterday.
hardcoded dns records are a terrible idea from 2 major perspectives; infosec, and--perhaps more important to a pihole crowd--the viability of this project. why would you want to advertise to clients that they live on a network with dns-based blocking in place?
dan@Viking-1:~$ dig @192.168.88.20 +short version.bind txt chaos
"dnsmasq-pi-hole-2.86"
This includes: version, author, copyright, cachesize, cache insertions, evictions, misses & hits, auth & servers
It has always been there, with the exception that it was only available for one single IP address in the past whereas it now extends to all addresses. This not to justify it. However, it is not a hard-coded as in "you cannot change it" option. It is a run time option and you can easily change it to deliver the hostname for all the interfaces (next version) or easily disable it.
The option to change it to the hostname seems to make a lot of sense to me. Otherwise, when there is no accompanying record in /etc/hosts, an IP address of the host may not have a hostname at all. As I said, advanced users are able to switch off all the Pi-hole featured intended to be convenience features.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.