Pi-hole: No DNS resolution after uninstalling Pi-Hole

[ghost]

In raising this issue, I confirm the following:

• [X] I have read and understood the contributors guide.
• [X] The issue I am reporting can be replicated.
• [X] The issue I am reporting isn't a duplicate (see FAQs, closed issues, and open issues).

How familiar are you with the the source code relevant to this issue?:

8

---

Expected behaviour:

When Pi-hole is uninstalled or dnsmasq is stopped, the host itself should still be able to resolve domain names, in a similar fashion to that prior to the installation of Pi-hole

Actual behaviour:

The uninstal removes dnsmasq, but dhcpcd.conf is left unchanged, and still contains the line static domain_name_servers=127.0.0.1 (as created by the installer when it configures a static IP address).

This results in resolvconf still using this (after Pi-hole uninstall) when regenerating /etc/resolv.conf, ultimately resulting in loss of DNS resolution, until the user replaces this line with something else (or another application adds an additional entry to resolvconf's database). The same behaviour can be seen if the dnsmasq service is stopped.

Steps to reproduce:

pihole uninstall or systemctl stop dnsmasq

Debug token provided by uploading pihole -d log:

N/A

Troubleshooting undertaken, and/or other relevant information:

dnsmasq will update resolvconf's database (see /etc/resolvconf/update.d/dnsmasq and /lib/resolvconf/dnsmasq), that adds the following entry to resolvconf's database, for use when generating /etc/resolv.conf:

# resolv.conf from lo.dnsmasq
nameserver 127.0.0.1

When dnsmasq is stopped, the entry is removed and resolvconf will regenerate /etc/resolv.conf, populating it with other entries from the database (such as domain_name_servers from dhcpcd.conf). This can be observed by running the following commands:

resolvconf -l
cat /etc/resolv.conf

systemctl stop dnsmasq

resolvconf -l
cat /etc/resolv.conf

systemctl start dnsmasq

resolvconf -l
cat /etc/resolv.conf

When the installer edits dhcpcd.conf to set a static IP address, it could set the value of domain_name_servers, to that of the upstream server chosen by the user during installation. This should be sufficient in ensuring that DNS resolution can continue when Pi-hole is uninstalled or if the dnsmasq service is stopped (as resolvconf will use lo.dnsmasq if the service is running or dhcpcd if it is not - however this will require testing on other platforms)

Examples of this issue can be found here and here

[dschaper]

Thanks for the detailed issue report, this does look like it's a bug, we should clean up everything. Probably will need to ask and confirm removal of the /etc/dhcpcd.conf lines, as people installing on Raspbian may already have lines there setting static and we wouldn't want to remove configurations that we didn't set.

Edit: We've had some internal discussion about setting localhost as the device resolver. It comes down to people installing on the Raspberry Pi Debian with Raspbian Desktop and running a browser on that same device while wanting blocking. Might be quite the edge case, but I agree we need to come up with a good solution.

[ghost]

It comes down to people installing on the Raspberry Pi Debian with Raspbian Desktop and running a browser on that same device while wanting blocking

I haven't used Debian desktop environments in a while, so I'm unsure how they interact with resolvconf or whether they use their own implementation for defining DNS, but is this why DNS is set to 127.0.0.1 only on Debian systems by the installer?

If so then that does complicate matters... on a Debian server environment the answer is simple, set DNS to an external upstream, and let dnsmasq change this (via resolvconf) when the service starts/stops. If this differs in a Debian desktop environment, and DNS must be is set to 127.0.0.1/localhost globally for Pi-hole to function correctly, then unavoidably system-wide lookup's will fail if ever the situation arises where nothing is listening on 127.0.0.1/localhost (AFAIK there's no efficient way to handle this without adding an unnecessary complexity for a rare but slightly probable scenario).

The same can be said regarding dhcpcd.conf during uninstall, with various ways of configuring a static address, it's hard to check for every possible configuration (e.g. I use arping profiles, allowing dhcpcd to use different static addresses dynamically, depending on the network it's connected with).

Either way, perhaps this cannot be solved programmatically (beyond confirming dhcpcd.conf modification with the user during uninstall), but I felt it was worth documenting for future reference (please close or mark as unsolved if applicable)

[dschaper]

I'm in agreement with just about everything, adding in the options of resolvconf.conf and the resolvconf daemon that manages /etc/resolv.conf. I appreciate the Issue and documenting the problems that users have run in to on Reddit. This will stay open for a while, while we discuss the corner cases and options to a resolution, it may just be that we change to handle the majority of installations and let corner cases lay where they fall.

[kyle95wm]

Someone was bitching about this on Reddit last night. I recommend that this is fixed in time for the next release.

[dschaper]

Yes, we saw the love note they left.

[imanpaz]

@dschaper Is there any update on this issue? My Debian machine is in a completely broken DNS state after disabling pihole-FTL from starting automatically on boot (update-rc.d pihole-FTL disable). The default system dns server is still 127.0.0.1#53 but obviously there is no process listening to that port anymore. I have tried removing the static domain_name_servers=127.0.0.1 line from /etc/dhcpcd.conf as suggested above and rebooting the machine, but problem stays. Debian cannot resolve any URL.

The /run/resolvconf file doesn't even exist anymore.

~# ll /etc/resolve.conf
lrwxrwxrwx 1 root root 31 Oct 11 18:34 /etc/resolv.conf -> /etc/resolvconf/run/resolv.conf
~# cat /etc/resolv.conf
cat: /etc/resolv.conf: No such file or directory

The dhclient gets the name servers from router but something is blocking it to update resolvconf. Appreciate if you or someone can show me how to at least work around this issue manually.

[Mcat12]

@lamp2 Have you checked what server is in /etc/resolvconf/run/resolv.conf?

[imanpaz]

@Mcat12 yes, as noted above resolve.conf did not exist anymore. Not sure what pihole had done to it

cat: /etc/resolvconf/run/resolv.conf: No such file or directory

Anyways, I was able to regenerate it by adding 8.8.8.8 in /etc/resolvconf/resolv.conf.d/base and updating resolveconf (resolveconf -u).

Not sure if this issue will reoccur next time I enable pihole again. Hopefully @dschaper and rest of pihole team can come up with a resolution to this issue so that pihole-FTL can be easily turned on and off without impacting system's default dns.

[imanpaz]

UPDATE: after rebooting system, the issue was returned (no resolv.conf file existing). I completely Uninstalled pihole this time, and followed the steps to reinstall resolvconf and regenerate resolv.conf. I had to also enable resolvconf.service as looks like disabling pihole-FTL from boot init previously had also disabled resolvconf.service at boot. Now my system is back to DNS sanity, but have to admit it was really hard to troubleshoot.

[imanpaz]

UPDATE: after rebooting system, the issue was returned (no resolv.conf file existing). I completely Uninstalled pihole this time, and followed the steps to reinstall resolvconf and regenerate resolv.conf. I had to also enable resolvconf.service as looks like disabling pihole-FTL from boot init previously had also disabled resolvconf.service at boot. Now my system is back to DNS sanity, but have to admit it was really hard to troubleshoot.

[vinc3m1]

After uninstalling on Ubuntu I also lost all DNS with lots of leftover configs broken. I had to do the following to get the network back up:

• in /etc/dhcpcd.confremove all the lines appended by
  setDHCPCD() { # but we can append these lines to dhcpcd.conf to enable a static IP echo "interface ${PIHOLE_INTERFACE} static ip_address=${IPV4_ADDRESS} static routers=${IPv4gw} static domain_name_servers=127.0.0.1" | tee -a /etc/dhcpcd.conf >/dev/null }
• in /etc/systemd/resolved.conf I had to re-comment out #DNSStubListener=yes

It would be nice if the setup script actually kept track of the changes that it made (which it clearly isn't doing), so it can properly undo them.

[dschaper]

I'm working on doing some overhaul to the installer script and as part of that I'll take a look at logging actions to help with uninstall.

[guszernial]

I had this problem when uninstalling pihole from a Kubuntu 18.04.1 system, and was able to get DNS working again by commenting out static domain_name_servers=127.0.0.1 in /etc/dhcpcd.conf. Is there anything else I need to do to clean things up and avoid possible future problems?

[triacontakai]

Had the same problem when uninstalling pihole from Debian 9.6, fixed with the solution from the above post and restarting dhcpcd

[mwoolweaver]

This issue just happened to today and I had emptied /etc/dnsmasq.d/ and change the nameserver list in resolv.conf.

After that everything started working for me.

[travisboss]

This issue just happened to today and I had emptied /etc/dnsmasq.d/ and change the nameserver list in resolv.conf.

After that everything started working for me.

This is what worked for me after a pi-hole uninstall.

EDIT: I wanted to edit my response and say this does work until you reboot the device. After that it fallbacks to 127.0.0.1. However, I did have unbound installed, once I uninstalled unbound and rebooted it defaults back to the proper DNS.

[ntindle]

Still occurs

[ntindle]

@dschaper any progress on this?

[dschaper]

If there were you would see it in the commits and history.

[jmgaleano]

Ahhh!

[wazerstar]

Had so many problems with pihole, crashing the entire device all time, just to figure out that when uninstalling, it would ask if I wanted to uninstall all apps, and after pressing Y it would just stay there for hours.

Anyways finally got it to more or less uninstall only to figure out dns issues all of sudden.

my headegg fix

sudo apt-get remove --purge resolvconf && sudo apt-get install resolvconf 

sudo resolvconf -u

reboot.

[ghost]

Tried it out, cant get the admin running. After uninstalling still the same problem with dhcpcd. I will go back to CFS and install de lists with ipset. Saves me the headache.

[FutureSharks]

but dhcpcd.conf is left unchanged, and still contains the line static domain_name_servers=127.0.0.1

Thanks for this! Took me too long to work out why resolution wasn't working after uninstall. Super annoying.

[dschaper]

We will be addressing this in the next release. The development code no longer sets the Pi-hole device to use localhost / 127.0.0.1 for the system resolver.

[JosNun]

Just for anybody here who still has the issue after trying the above steps, removing dhcpcd5 fixed it for me

apt remove --purge dhcpcd5

[rwev]

None of the aforementioned hacks to fix DNS after pihole uninstall worked for me, but this did:

sudo systemctl restart systemd-resolved.service

[mazafra1]

After almost 2 years this ticket was opened, this is still happening to me.

[XenHat]

After almost 2 years this ticket was opened, this is still happening to me.

Same, unfortunately

[TheFirsh]

sudo rm /etc/init.d/pihole-FTL
sudo reboot

That godforsaken file puts back the /etc/resolvconf/run/interface/lo.piholeFTL no matter what you do. Finally the nightmare is over.

[avoidik]

@TheFirsh pihole uninstall hadn't removed everything on my Ubuntu 18.04 machine, I have executed find / -iname '*pihole*' -not -path '/sys/kernel/*' -print0 2>/dev/null | xargs -0 -o sudo rm -rfi to clean all the leftovers up in interactive mode, then I temporarily added 8.8.8.8 to /etc/resolv.conf, reinstalled dnsmasq, dhcpcd5 packages, restarted systemd-resolved service, and got my dns resolution back

Click to expand to reveal the list of remaining files

/etc/bash_completion.d/pihole
/etc/rc4.d/S01pihole-FTL
/etc/rc6.d/K01pihole-FTL
/etc/rc1.d/K01pihole-FTL
/etc/rc3.d/S01pihole-FTL
/etc/rc0.d/K01pihole-FTL
/etc/rc2.d/S01pihole-FTL
/etc/cron.d/pihole
/etc/init.d/pihole-FTL
/etc/rc5.d/S01pihole-FTL
/run/pihole
/run/pihole-FTL.port
/run/pihole-FTL.pid
/run/resolvconf/interface/lo.piholeFTL
/run/systemd/generator.late/pihole-FTL.service
/run/systemd/generator.late/graphical.target.wants/pihole-FTL.service
/run/systemd/generator.late/multi-user.target.wants/pihole-FTL.service
/var/log/pihole
/var/log/pihole-FTL.log
/var/log/pihole.log
/var/www/html/pihole
/usr/local/share/man/man5/pihole-FTL.conf.5
/usr/local/share/man/man8/pihole-FTL.8
/usr/local/share/man/man8/pihole.8

sudo systemctl stop pihole-FTL
find / -iname '*pihole*' -not -path '/sys/kernel/*' -print0 2>/dev/null | xargs -0 -o sudo rm -rfi
echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf
sudo apt-get purge dnsmasq dhcpcd5
sudo apt-get install dnsmasq dhcpcd5
sudo systemctl restart systemd-resolved

[thewriteway]

unfortunately the above fixes did not seem to work also this happened on the new beta release v5, so i guess a fix didn't go in yet?

[ThatWeirdAndrew]

I was also experiencing this issue when installing from the master branch, but I am able to install from the v5.0 branch without issue. The v5.0 branch fixed the issue for me.

[dschaper]

Version 5 does not modify /etc/resolv.conf anymore, nor does it set the nodes resolver to 127.0.0.1. pihole-FTL no longer requires that. /etc/init.d/pihole-FTL has removed those commands

[XenHat]

I had it happen to me again so I'll post this :
anyone needing an immediate fix can:

1. unlink the /etc/resolv.conf and create a new file in its place with the same name pointing at the dns server of your choice. even works with unbound.
2. turn off all mechanisms that change the file, or set chattr +i /etc/resolv.conf to prevent anything to edit or remove it
   
   
   
   • systemd: /etc/systemd/resolved.conf, uncomment and set to no the useDnsStub (sic) property
   
   

[maxloh]

None of the aforementioned hacks to fix DNS after pihole uninstall worked for me, but this did:

sudo systemctl restart systemd-resolved.service

It works for me too.

[dschaper]

Now you won't be able to restart pihole-FTL.