pi-hole/docker-pi-hole

Pihole customs.list corrupted without visbility in local DNS UI

nuvious opened this issue · 2 comments

nuvious commented

This is a: Bug

NOTE: This may be a bug with pi-hole overall but observed in the container.

Details

Initial Behavior Observed

I kept getting a local DNS entry response from my pi-hole and assumed it was a DNS cache issue. I rebooted the container and the issue persisted. The UI showed the intended external IP I updated the domain to but the wrong local IP address was being returned still. I self-host this service which uses a mobile app that only has 1 host entry, which I replaced with the external domain. The app worked when I wasn't on my local network (even through a cloudflare reverse proxy) but I could not access the service on my home network. I tried manually adding the real IP address of the external domain but that did not resolve the issue.

In the docker container (running on Unraid) I had a DNS entry that was pointing to the old internal IP. My entry for the IP looked as follows in the UI:

192.0.2.42 foo.myexternaldomain.com

NOTE: Real external IP replaced with a non-routable RFC 5737 IP

However nslookup on the pi was returning an internal IP still; the old one I used to use:

nslookup foo.myexternaldomain.com 192.168.11.2
Server:  pi.hole
Address:  192.168.11.2

Name:   foo.myexternaldomain.com
Addresses:  192.168.11.162

Note that the actual foo.mydomain.local isn't even being returned properly, the address being reported was from a different service, anotherservice.mydomain.local, that was returning an error when I queried for that local service.

Root Cause

I eventually traced the issue to a corrupted custom.list entry:

192.168.1.60 myservice.mydomain.local
192.168.1.162 anotherservice.mydomain.local192.168.1.122 foo.myexternaldomain.com
192.168.1.60 otherservice.mydomain.local
192.168.1.122 foo.mydomain.local
192.168.1.1 router.myexternaldomain.com
192.0.2.42 foo.myexternaldomain.com

I have never modified the custom.list manually so at some point the file was adjusted via the UI it did not insert a new-line properly between entries. It's also interesting that it still parses that line at all, returning the IP for the wrong service.

How to reproduce the issue

  1. Environment data
  • Operating System: Unraid
  • Hardware: Intel® Xeon® CPU E5-2650L 0 @ 1.80GHz platform
  • Kernel Architecture: amd64
  • Docker Install Info and version:
  • Hardware architecture: amd64
  1. Install official pi-hole from Unraid and modify local DNS entries. Alternative reproduce this by intentionally creating a corrupted entry by removing a newline between two entries.
  2. This may be a very transient bug. I didn't observe any down-time of my Unraid server for a 24 hour period before and after my monit reported the external service down.

These common fixes didn't work for my issue

Reboot container to clear the DNS cache.

This fixed my issue

Removed/correct the corrupted entry. In my case I simply corrected it which also resolved a local service DNS entry. I was also able to remove the external entry I added to try to mitigate this and the routing through the CloudFlare reverse proxy took over just fine.

Recommended Fix

Since this bug is probably transient it may be worth checking custom.list for corrupted entries and informing the user with some sort of alert and/or using regex matches on corrupted entries to fix them.

rdwebdesign commented

Please provide a Debug Log.

Using the command line:

  • use pihole -d command.
  • when asked to upload the log, answer Y.
  • copy only the token and paste here.

Using the web interface:

  • click on Tools > Generate Debug Log menu.
  • then mark the second checkbox to upload the log and click on the big button.
  • when finished, copy only the token and paste here.

EDIT:
Please also post your compose file or docker run command used to start your container.

github-actions commented

This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.