Name resolution of locally significant names works except for Pi-hole's own hostname

Hello! I use Pi-hole as a docker-image on TrueNAS. I configured it and it works fine mostly for my DHCP and DNS needs. However, I have two seemingly small issues, which I couldn't resolve even after research here and it other places.

I think those two issues are connected perhaps, so I will describe them in this post together.

I use a bunch of DNS-names which resolve externally to a public IP address, but internally (using the "Local DNS"/"DNS Record" function with locally significant private IP addresses. This works fine for most of the names, except the one name which refers to the same name which the host holds which Pi-Hole is running on.

Also, I observe that under "Settings/DHCP/Pi-hole domain name" the domain name that I configure there is not preserved over restarts of the container. All other configuration of Pi-Hole is preserved.

Summary of facts:
"fractal" is the hostname of Pi-Hole, "fp.on.at" is the domain, "fractal.fp.on.at" is the FQDN which should be resolved locally to a private IP. Instead, it is resolved to the public IP served by public upstream DNS. The Pi-hole domain name cannot be set to fp.on.at persistently.

Expected Behaviour:

I expect to resolve this one name to the given private IP adress configured in Pi-Hole.

Actual Behaviour:

Instead, it is resolved to the public IP served by public upstream DNS.

Debug Info:

When I check pi-hole.log, it looks fine:
Feb 1 22:37:47: query[A] fractal.fp.on.at from 192.168.0.45 Feb 1 22:37:47: /etc/pihole/custom.list fractal.fp.on.at is 192.168.0.2

It seems, the info is overridden by something else? However, the client (Ubuntu) has configured Pi-Hole only as DNS via DHCP from Pi-Hole. When I clear the cache and ping the name, it works for the first time. But for the second time, it's pointing to the outside IP again.

Thanks for any advice

Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

pihole -d

or do it through the Web interface:

Tools > Generate Debug Log

I recreated the problem and then created the debug-log:
https://tricorder.pi-hole.net/aLLgiGIt/

Your container shows lan as your domain (the Pi-hole container's default).

In addition, your Local DNS records are A records exclusively.

Consequently, a client requesting A and AAAA records for fractal.fp.on.at will receive the A record as shadowed by your local DNS record, but the AAAA record will be resolved publically, returning the pubic IPv6 addresses - and your IPv6-capable clients would then prefer to use them, instead of those private range IPv4s.

To address this, you should edit your Pi-hole container's docker-compose or docker run script and set its PIHOLE_DOMAIN environment variable to fp.on.at, and its DNS_BOGUS_PRIV to true, see also Pi-hole's documentation on Docker environment variables.
The former will persist your Pi-hole's DHCP server domain, and together with an enabled DHCP server, the latter will keep resolution for *fractal.fp.on.at strictly local, i.e. respective AAAA requests won't be forwarded upstream, but replied with NODATA.
Settings should take effect after you've destroyed your existing Pi-hole container and created a fresh one.

First, thanks for taking the time and looking into the issue. :pray:

With your advice, I could fix the issue with PIHOLE_DOMAIN being non-persistant over restarts of the container. I wasn't aware that some settings have to be done via environment-variables and not the GUI.

I also set DNS_BOGUS_PRIV to true as you suggested.

However, the problem with fractal.fp.on.at not being resolved (while all other host-records from the same domain are being returned by Pi-hole correctly) is still present.

The user-experience is slightly different comparing a Ubuntu-client (where the problematic name gets resolved to 127.0.0.1, which is wrong) and Windows (where it is not resolved at all).

Consulting the pi-hole.log, I see this:

Feb 2 12:42:10: query[A] fractal.fp.on.at.fp.on.at from 192.168.0.45
Feb 2 12:42:10: config fractal.fp.on.at.fp.on.at is NXDOMAIN 
Feb 2 12:42:10: query[AAAA] fractal.fp.on.at.fp.on.at from 192.168.0.45
Feb 2 12:42:10: config fractal.fp.on.at.fp.on.at is NXDOMAIN 
Feb 2 12:42:10: query[A] fractal.fp.on.at.on.at from 192.168.0.45
Feb 2 12:42:10: cached fractal.fp.on.at.on.at is NXDOMAIN 
Feb 2 12:42:10: query[AAAA] fractal.fp.on.at.on.at from 192.168.0.45
Feb 2 12:42:10: cached fractal.fp.on.at.on.at is NXDOMAIN **Feb 2 12:42:10: query[A] fractal.fp.on.at from 192.168.0.45
Feb 2 12:42:10: Pi-hole hostname fractal.fp.on.at is 0.0.0.0

You can see that the name fractal.fp.on.at is being appended the DNS-suffix "fp.on.at" a second time, which is not pretty. But I can live with that.

After that, the client asks without appending the domain name a second time. This time, Pi-hole returns NXDOMAIN, and another message says "Pi-hole hostname fractal.fp.on.at is 0.0.0.0". This in spite of the fact that I explicitily set the DNS-record for that name otherwise.

For me it seems that Pi-hole does not want to serve the host-record that I set if it matches its own hostname.

This is the debug log with the current configuration: https://tricorder.pi-hole.net/JC41FHEY/

Some of them are mutually exclusive, e.g. you can either set Pi-hole's upstream DNS servers via UI or through env vars.

Could you share your docker compose or docker run script?

That is normal client behaviour, not something that Pi-hole can control:
A client may opt to append local/search domains to any given domain, e.g. nslookup may do so, resulting in at least 4 DNS requests (for A and AAAA with and without search domain appended).

Is fractal the name of the machine hosting your Pi-hole?
If so, that may be explained by another missing environment variable.

When inspecting your debug log, I overlooked that you haven't set your container's IPv4 address - apologies for that:

-rw-rw-r-- 1 pihole root 157 Feb  1 21:32 /etc/pihole/pihole-FTL.conf
   MACVENDORDB=/macvendor.db
   LOCAL_IPV4=0.0.0.0

To address this, you should set FTLCONF_LOCAL_IPV4 to your host's IPv4 address.

You should probably note that TrueNAS is not supported by Pi-hole - specifically, the Pi-hole team does not develop nor endorse a TrueNAS Pi-hole app that some users have reported to use.

If that TrueNAS Pi-hole app is just a wrapper around Pi-hole's official Docker image, then it should run, provided the container is configured correctly.

If you are running that TrueNAS app, you may want to inform the developers of that app that they are missing out on proper configuration and/or documentation of their Pi-hole container.

Many thanks for your support - with your latest recommendation to set FTLCONF_LOCAL_IPV4 I could fix the behaviour and now it works fine.

I'm aware that there is no official Pi-hole app for TrueNAS, however to my knowledge they just incorporate the official docker image of Pi-hole into their system. They use docker, but I cannot provide a docker compose or run script. It's completely controllable via the GUI. However, I plan to move all the apps to Portainer at some point, where I will have to write the docker-compose yaml for myself.

Glad it's sorted. :slight_smile:

Could you perhaps share a screenshot of that UI, including FTLCONF_LOCAL_IPV4 specifically?

That may help other TrueNAS Pi-hole app users who come here for advice, but often struggle to comply with our requests to provide information on their docker configuration as usually done by scripts, or to apply our advice to adopt Pi-hole container environment variables.

Sure I can. Please see the screenshot with the configuration below. I think, however, that the issue i ran into was not so much about the specific integration of Pi-hole in TrueNAS, and would not hit a lot of other TrueNAS users.

I think it has to do with the fact how my interfaces an my server are configured. I bundle two physical interfaces to one logical interface (bond0) using LACP. I then had to apply the IP adress to the logical interface using an alias. Just an idea. I cannot quickly reconfigure switch & NAS to confirm.

1 Like

I was more concerned about having an actual screenshot at all. :wink:
We had some few TrueNAS users searching for advice here, despite the TrueNAS Pi-hole app not being developed by Pi-hole. But when asked for configuration details of their containers, they usually didn't respond, and similarly, they wouldn't know how to apply recommended environment variables.

We now have a screenshot we can refer to.

But it seems that TrueNAS would not expose FTLCONF_LOCAL_IPV4 by default, despite being one of the three Recommended Variables, which may have spared you from your fractal grievances if it had been exposed from the start.

If you have a way to inform the developers of that app that they are missing out on proper configuration and/or documentation of their Pi-hole container, that may help other TrueNAS app users.