How to disable pi.hole DNS record

Help Community Help
1

The issue I am facing:
Custom set DNS record for the pihole dns changed from dns. to "pi.hole"
I want to change it back, but I can't find any mention of this "pi.hole" record in any configuration file?

I found this entry: Deleting pi.hole-DNS entry
but my local.list is empty and contains the text "### Do not modify this file, it will be overwritten by pihole -g" and indeed it does that.

The entry is set in custom.list (both forward and reverse DNS for other entry's in this list work without any issues) but it does not resolve correctly.

[root@piholedns ~]# nslookup pi.hole
Server: 127.0.0.1
Address: 127.0.0.1#53

Name: pi.hole
Address: 127.0.0.1
Name: pi.hole
Address: ::1

H:>nslookup google.com
Server: pi.hole
Address: 10.0.100.10

Non-authoritative answer:
Name: google.com
Addresses: 2a00:1450:400e:802::200e
142.251.36.14

Details about my system:
RockyLinux 8.4, VM

What I have changed since installing Pi-hole:
I updated from pihole 2.85 to 2.86 and pihole-FTL from v5.8.1 to v5.9

2

This was changed in our most recent release this week:

3

I have seen that entry, but where is this 'pi.hole' hostname derived from? It's not the hostname, it's not in any configuration file, not from "ip a" and it's conflicting with custom.list.
So where is it stored? Or how can I change it?

5

This is in pihole-FTL now.

This PR makes FTL automatically reply with the appropriate IP address to both pi.hole and the machine's hostname. The address FTL replies with can be overwritten using the REPLY_ADDR4/6 settings.

6

In pihole-FTL? Where? Where can I change it?
REPLY_ADDR4 and REPLY_ADDR6 have no effect.

The reply is with the correct IP, just not the correct hostname.
10.0.100.10 =! pi.hole
pi.hole =! 10.0.100.10
How do I override the hostname "pi.hole" to something else?

This is not okay:

H:>nslookup 10.0.100.10
Server: pi.hole
Address: 10.0.100.10

Name: pi.hole
Address: 10.0.100.10

H:>nslookup pi.hole
Server: pi.hole
Address: 10.0.100.10

Name: pi.hole
Addresses: fe80::250:56ff:febd:83af
10.0.100.10

8

It depends on what you consider the correct hostname. Before, Pi-hole responded with pi.hole to PTR requests for the one IP address defined in setupVars.conf. Now, this has been extended to work for any valid local IP address. This, arguably, makes more sense.

What you can do is setting

PIHOLE_PTR=false

to the file /etc/pihole/pihole-FTL.conf (create if it does not exist) and run

pihole restartdns

When there is nothing in /etc/hosts for the requested IP address, this will result in NXDOMAIN.

The documentation for this flag is still in draft mode as final adjustments are made to the wording.

I still don't think this is wrong, it just depends on what you expect for PTRs to the Pi-hole. We could extend the PIHOLE_PTR setting to also accept another option to make it:

  • PIHOLE_PTR=true = reply with pi.hole to all local IP PTRs
  • PIHOLE_PTR=HOSTNAME (new!) = reply with the device's hostname to all local IP PTRs
  • PIHOLE_PTR=false = don't force reply to local IP PTRs
    (note that PIHOLE_PTR=HOSTNAME is just a proposal and not available in the current release)

What do you think?

1 Like
9

Furthermore, I forgot to mention that you can always overwrite the PTR response using, for instance,

ptr-record=1.0.0.127.in-addr.arpa,testlocal

in a custom config file like /etc/dnsmasq.d/99-ptr.conf

10

See

11

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
12

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.

13

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.

14

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.

15

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

16

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?

23

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.

24

You did restart Pi-hole's DNS resolver?

25

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:~#
26

I believe you've discovered a typo in the posts here. :wink:

According to the doc draft, it should read
PIHOLE_PTR=false

EDIT: I'll try to amend that above.

1 Like
28

Yup, working now. Thanks!

29

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.list or in the webinterface via "Local DNS Records" EXEPT if you want a hostname for the Pihole itself, then you have to set PIHOLE_PTR=false and PIHOLE_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)