How to disable pi.hole DNS record

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

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

Server: pi.hole

Non-authoritative answer:
Addresses: 2a00:1450:400e:802::200e

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

This was changed in our most recent release this week:

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?

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.

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. =! pi.hole
pi.hole =!
How do I override the hostname "pi.hole" to something else?

This is not okay:

Server: pi.hole

Name: pi.hole

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

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

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


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

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

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


Yes that is what I was looking for!
Anyone looking for the documentation should go to:
(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 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 or 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 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,pi (my pi's address is gets me closer:

$ nslookup name = pi. 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

root@pi:~# nslookup	name = pi.hole.

root@pi:~# emacs /etc/pihole/pihole-FTL.conf

root@pi:~# cat /etc/pihole/pihole-FTL.conf


root@pi:~# pihole restartdns
  [โœ“] Restarting DNS server
root@pi:~# nslookup	name = pi.hole.


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

According to the doc draft, it should read

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:, 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:, then click the link and go to: "" (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 to 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)