Pi-hole server lose awareness of it self

I installed Pi-hole on a running Raspbian beside some other services. The local network services (DNS local/global and DHCP) are hosted by a AVM FRITZBox. The network clients get via DHCP the adress of the Raspbian/Pi-hole server as DNS. Afterwards the Raspbian/Pi-hole know the FRITZBox as DNS.

The system is running fine.

After some days of uptime only the name of the Raspbian system suddenly could not longer be resolved by other LAN clients. The host could only approached with the IP adress.
Rebooting the whole system solve the problem for the next couple days.

What happens here?
Could somebody give me a hint how to solve this odd behavior?

Thank you in advance!

When things go wrong, could you run below two commands on the client thats not resolving to Pi-Hole anymore and post result here ?

  • Replace "IP_ADDRESS_OF_PI_HOLE" with the actual IP address of your Pi-Hole box.
    ** Linux clients will need the package "dnsutils" installed eg "sudo apt-get install dnsutils".

nslookup pi.hole


nslookup pi.hole IP_ADDRESS_OF_PI_HOLE

After I encounter this problem twice , I setup a test server:
RPi 1, Raspbian lite, Pi-hole only, same settings like the other, hostname: PiHole

This server has exactly the same problem after some days uptime.

C:>ipconfig /all

DHCP aktiviert. . . . . . . . . . : Ja
IPv4-Adresse . . . . . . . . . . :
Subnetzmaske . . . . . . . . . . :
Standardgateway . . . . . . . . . :
DHCP-Server . . . . . . . . . . . :
DNS-Server . . . . . . . . . . . :

Everything looks fine.

C:>ping PiHole
Ping-Anforderung konnte Host "PiHole" nicht finden. Überprüfen Sie den Namen, und versuchen Sie es erneut.

Host is not available.

C:>nslookup PiHole
Server: PiHole

*** Keine internal type for both IPv4 and IPv6 Addresses (A+AAAA)-Einträge für PiHole verfügbar.

C:>nslookup PiHole
Server: PiHole

Name: PiHole.fritz.box

nslookup returns different results. The first result is alot more common and says "No (A+AAAA)-entrys for IPv4 and IPv6 for PiHole available."

C:>nslookup pihole
Server: PiHole

*** Keine internal type for both IPv4 and IPv6 Addresses (A+AAAA)-Einträge für pihole verfügbar.

C:>nslookup pihole
Server: PiHole

Name: pihole.fritz.box

Same thing with this command.

Try to get used to addressing your pi with "pi.hole".
This "pi.hole" DNS record comes with every Pi-Hole setup.
You can try it with:

nslookup pi.hole

*Dont omit the dot like you did on my last request!

And check if giving your Pi a FQDN (Fully Qualified Domain Name) like "pihole.fritz.box" fixes anything:


You can check hostname on Pi short &full with:

hostname; hostname -s; hostname -f

Here is an example of my Pi:

$ hostname; hostname -s; hostname -f

Weird thing is, that name "pihole.fritz.box" is already registered publicly if I do a lookup against google DNS

 $ nslookup pihole.fritz.box
Address 1: google-public-dns-a.google.com

Name:      pihole.fritz.box
Address 1:

I dont know what Fritz is all up to :wink:

Aha I get it:

$ nslookup RANDOM_87d6fs87d6f87dsfdasg.fritz.box

Non-authoritative answer:
Name:   RANDOM_87d6fs87d6f87dsfdasg.fritz.box

Everything resolves to that localhost IP address
Dont know what for.
EDIT: I guess its Fritz's own mysterious black hole :wink:

Thank you very much for your time and effort!
> Try to get used to addressing your pi with "pi.hole".
> This "pi.hole" DNS record comes with every Pi-Hole setup.

I don't think that hardwired records are a proper solution. The host pi.hole was reliable resolved, but without the complete "fritz.box" domain. I assume this value was directly returned by the Pi-hole server not the FRITZBox.

> And check if giving your Pi a FQDN (Fully Qualified Domain Name) like "pihole.fritz.box" fixes anything:

Both systems had no entry in /etc/hosts except for the localhost. I added a line for the IP Adress and make known the full and short domain name. On the test server I additionally changed the hostname to the FQDN (pihole.fritz.box). I had to restart both systems. Now I have to wait until the error occur.

> Everything resolves to that localhost IP address
> Dont know what for.
> EDIT: I guess its Fritz's own mysterious black hole

The name/domain (fritz.box) of the FRITZBox can be changed. Do you think this could be a solution/necessary?

Why this error occur not until after some days of uptime?
Why is only the host of Pi-hole affected?

See "pi.hole" more as like an alias for the actual hostname.
And "pi.hole" should always resolve to the proper IP address when querying Pi even if you made a mess of your naming scheme.

Yes as a last resort you could put entries in the "/etc/hosts" file like so: pihole.fritz.box pihole

Make sure you reload dnsmasq afterwards:

sudo service dnsmasq reload

Setting a FQDN is always the preferred method.
If you check Pi-Hole Advanced DNS settings, you'll notice Pi-Hole can distinct between FQDN's and non FQDN's and forward DNS requests upstream accordingly.

Its at least something to try.
Knowing now what Fritz does with its "fritz.box" sub domains (resolving unknown to , I would not choose that domain name for my network.
EDIT: But I might be wrong as I have no idea why Fritz does this.

One reminder, clients like your Windows machine cache DNS records so do below one allot:

ipconfig /flushdns

"" explained:


I found a similar article (in german) https://www.heise.de/newsticker/meldung/Neue-Top-Level-Domain-box-bringt-manche-Netze-durcheinander-3491185.html
It's about the new TLD ".box" which collides with the FRITZBox own local DNS-suffix "fritz.box".

But I don't think this causes my problem.
Only the host of Pi-hole could not longer be resolved. All other Clients, obviously all *.fritz.box, behave normal.

Thats because FritzBox creates DNS records for the clients at the DHCP stage.
When clients acquire a new DHCP lease from FritzBox, at this stage, they advertise their own hostname to the router.
As Pi-Hole probably is setup with a static IP, not acquired via DHCP, probably no DNS records were created on FritzBox.
Check it out by querying FritzBox directly on a Windows client:

nslookup pihole.fritz.box

On Pi-Hole, in "/etc/hosts" try put a hash in front of below line:

# pihole.fritz.box

And add a line: pihole.fritz.box pihole

And reload dnsmasq:

sudo service dnsmasq reload

I experienced with own setup that Pi-Hole would alternate resolving to Pi-Hole IP address, or the address on a Windows client:

C:\>nslookup noads
Server:  noads.dehakkelaar.nl

Name:    noads.dehakkelaar.nl

Thank you very much for your patience and support.
I think I understand now the problem. Because the Pi-hole server has a static IP setup the DHCP and DNS service of the FRITZBox doesn't know the client. The Pi-hole server has to resolve his own hostname. If a valid entry in /etc/hosts is missing or some missleading entrys are pressent, the host could not be reliable resolved.

My /etc/hosts now looks like this:

>       localhost
> #      pihole
>    pihole.fritz.box pihole
> ::1             localhost ip6-localhost ip6-loopback
> ff02::1         ip6-allnodes
> ff02::2         ip6-allrouters

I am confident that this solve the problem.
Again, thank you very much!

But this problem should appear on every installation where Pi-hole attach on external DHCP und DNS services. Maybe the developers should look into it and maybe make or guess changes in /etc/hosts during the installation process.

Even a neater solution if you return the "/etc/hosts" file back again to default :

echo 'no-hosts' | sudo tee /etc/dnsmasq.d/no-hosts-file.conf

sudo service dnsmasq restart

Ok, this tells the DNS to irgnore /etc/hosts. Because it could be changed manually or by other circumstances.

But the local DNS need to know about "pihole.fritz.box" & "pihole" refer to and return this properly to requesting clients. Where is this information local gathered?

As we discovered the "main" local DNS at the FRITZBox doesn't know the host.

Lets forget Pi-Hole is running a DNS service.
The "/etc/hosts" file main purpose is for telling processes, running on its own host, how to resolve certain hostnames to IP addresses without using a DNS server (suppose the DNS server is down).
Its not intended for other clients on the network to be used for resolution.
So this entry would make perfect sense: pihole.fritz.box

If a local process is asking to resolve "pihole.fritz.box" via the hosts file, it will get "" returned which is an IP address on its own loopback interface.
Everything on the loopback interface stays internal and is not broadcasted over the physical network interfaces like eth0, wlan0 etc.
Do you now see the advantage of using a loopback IP addresses for the processes to communicate internally to each other ?

Having loopback IP addresses as DNS records in your dnsmasq service is pointless for resolving to for example another host.
But these loopback IP addresses as DNS records could be used for other purposes like for example whats implemented on FritzBox routers:


These records are added to dnsmasq:

$ cat /etc/pihole/local.list noads.dehakkelaar.nl pi.hole

Ok this make sense, because the name resolution is then a part of Pi-hole not done by the host itself.
I restored the /etc/hosts file:

Told Pi-hole to ignore /etc/hosts:

Made the entry in /etc/pihole/local.list:

And restarted the service:

I'm confident that this is the right solution.

Noooo dont do that!
Pi-Hole needs to populate this file " /etc/pihole/local.list" for you.
I believe if you run "pihole -r" for reconfiguring, you will be asked for a hostname and you can change it if you want (set it to a FQDN to avoid trouble and have a short name covered as well).
Chances are that first time you run Pi-Hole updates, the entries you made in that file will be overwritten.

EDIT: Did you see me having a short name in that file from my examples ?

It still works for me:

$ nslookup noads
Address 1: noads.dehakkelaar.nl

Name:      noads
Address 1: noads.dehakkelaar.nl

This means the solution should be to use a FQDN hostname (in /etc/hostname) and tell Pi-hole to ignore /etc/hosts?

Yes but dont forget to change it too in the "/etc/hosts" file for the loopback IP 127....
And reboot just to make sure the new hostname propagates through the system.