IPv6 Failed to resolve

Please follow the below template, it will help us to help you!


Pi-Hole running on Ubuntu 18.x. When changing my router's DNS to PiHole, internet is not available for any devices other than the Pi-Hole host (DNS not resolving?) I suspect it has something to do with the failure to resolve the advertising link on a remove public DNS server.

Debug Token:


The active IP on the device is:

*** [ DIAGNOSING ]: Networking
[✓] IPv4 address(es) bound to the enp7s0 interface:

But, Pi-hole is configured on a different IP:

*** [ DIAGNOSING ]: Setup variables

Run pihole -r and select the reconfigure option to get Pi-hole on the active IP and interface.

Thank you for your reply.
I reconfigured pi-hole and made sure the IP was, however the debug still shows as the setup variables. Is there someway pi-hole is grabbing from another file after the config wizard completes?


Screenshot from 2022-07-27 09-42-56

EDIT: I manually edited SetupVars.conf and repaired pihole again, it successfully changed the setup IP, but I still have the same error: https://tricorder.pi-hole.net/p612Yzr0/

Still looking for help. How could I reset whatever internet configurations my device has? I did move from one house to another with a different gateway. Although I searched the debug log for the old IP and I am not sure what else to try.
New log:

You should verify your Pi-hole host machine's network configuration.

It would depend on your specific OS variety how and where to check that (and probably personal choice as well).

For a start, let's have a look at dhcpcd.conf, as for a long time that has been Pi-hole's target for setting a specific IP:
Run from your Pi-hole machine, what's the output of

grep -v '^#\|^$' /etc/dhcpcd.conf

:~$ grep -v '^#|^$' /etc/dhcpcd.conf

option rapid_commit
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
option ntp_servers
option interface_mtu
require dhcp_server_identifier
slaac private
interface enp7s0
        static ip_address=
        static routers=
        static domain_name_servers=

My OS is Ubuntu 18.04, willing to verify/reset network configuration however is recommended.

And what for below one?

grep -v '^#\|^$' -R /etc/netplan*


pi@ph5b:~ $ apt show netplan.io
Description: YAML network configuration abstraction for various backends
 netplan reads YAML network configuration files which are written
 by administrators, installers, cloud image instantiations, or other OS
 deployments. During early boot it then generates backend specific
 configuration files in /run to hand off control of devices to a particular
 networking daemon.
 Currently supported backends are networkd and NetworkManager.


Ow ps, you should at least configure one or more DNS server IP's on above line for the host to be able to resolve through DNS.
Can be your router IP, your ISP provided DNS IP's or public DNS resolvers like Cloudflare, Quad9 etc.
And run below to apply (or reboot if still not working):

sudo service dhcpcd restart

:~$ grep -v '^#|^$' -R /etc/netplan*

/etc/netplan/01-network-manager-all.yaml:  version: 2
/etc/netplan/01-network-manager-all.yaml:  renderer: NetworkManager

To configure the DNS IP, I just edited the line in /etc/dhcpcd.conf, static domain_name_servers=, (Router IP) is that correct?

Thats correct.

But NetworkManager is similar as what dhcpcd does:

pi@ph5b:~ $ apt show network-manager
Description: network management framework (daemon and userspace tools)
 NetworkManager is a system network service that manages your network devices
 and connections, attempting to keep active network connectivity when
 available. It manages ethernet, Wi-Fi, mobile broadband (WWAN), and PPPoE
 devices, and provides VPN integration with a variety of different VPN
 This package provides the userspace daemons and a command line interface to
 interact with NetworkManager.
pi@ph5b:~ $ apt show dhcpcd5
Description: DHCPv4, IPv6RA and DHCPv6 client with IPv4LL support
 dhcpcd is a one stop network management daemon which includes
  * RFC compliant DHCPv4 and DHCPv6 clients
  * DHCPv6 Prefix Delegation support
  * IPv4LL (aka ZeroConf) support
  * ARP address conflict resolution
  * Link carrier detection
  * Wireless SSID profiles
  * ARP ping profiles

Is NM active?

systemctl status NetworkManager.service

I got that from:

pi@ph5b:~ $ apt-file list network-manager
network-manager: /lib/systemd/system/NetworkManager.service

Below might reveal its activities:

journalctl --full --no-pager -u NetworkManager.service

And below to see what dhcpcd does:

journalctl --full --no-pager -u dhcpcd.service

You cant have two network managers fighting over network control.
You either have to disable NM that comes with netplan and configure dhcpcd properly.
Or you disable dhcpcd and configure the netplan / network-manager combo with proper IP details.

dhcpcd can be disabled with below:

sudo systemctl disable --now dhcpcd.service

Am not sure how to disable NM that comes with netplan.

Ow it might be as simple as just hashing/commenting out above three lines and reboot.
Check below one afterwards:

systemctl status NetworkManager.service

NetworkManager.service is active and running.

The journalctl output of NetworkManager was long mostly filled with connectivity going on and off.

Aug 05 22:24:13 NetworkManager[1241]: <info>  [1659752653.0061] manager: NetworkManager state is now CONNECTED_SITE
Aug 05 22:24:13 NetworkManager[1241]: <info>  [1659752653.0062] policy: set 'Wired connection 1' (enp7s0) as default for IPv4 routing and DNS
Aug 05 22:24:14 NetworkManager[1241]: <info>  [1659752654.0858] manager: NetworkManager state is now CONNECTED_GLOBAL
Aug 05 22:46:57 NetworkManager[1241]: <info>  [1659754017.5985] connectivity: (enp7s0) timed out
Aug 05 22:46:57 NetworkManager[1241]: <info>  [1659754017.5986] manager: NetworkManager state is now CONNECTED_SITE
Aug 05 22:51:30 NetworkManager[1241]: <info>  [1659754290.0728] manager: NetworkManager state is now CONNECTED_GLOBAL
Aug 05 23:16:57 NetworkManager[1241]: <info>  [1659755817.5986] connectivity: (enp7s0) timed out
Aug 05 23:16:57 NetworkManager[1241]: <info>  [1659755817.6428] manager: NetworkManager state is now CONNECTED_SITE
Aug 05 23:21:28 NetworkManager[1241]: <info>  [1659756088.7588] manager: NetworkManager state is now CONNECTED_GLOBAL

dhcpcd.service only has data from last year. repeating

Sep 11 23:50:23 dhcpcd[1206]: enp7s0: adding default route via [IPv6]
Sep 11 23:50:23 dhcpcd[1206]: if_route6 (ADD): File exists
Sep 11 23:50:26 dhcpcd[1206]: enp7s0: adding default route via [IPv6]
Sep 11 23:50:26 dhcpcd[1206]: if_route6 (ADD): File exists

I went ahead and stopped and disabled dhcpcd.service. After looking up the two services, I may not even need either since I am connected via ethernet and Ubuntu should have a native package to control?
Should I disable NM as well? How to test if disabling dhcpcd fixed the issue? I will reboot and retest pihole.

EDIT: Internet on the host machine is not working now

Am not that familiar with the netplan & NM combo but I believe static IP details need to be configured similar like below:

Afterwards you can check stuff with below commands:

  • Links and UP status:
    ip -br l

  • Adresses:
    ip -br a

  • Routes:
    ip r

  • Neighbours:
    ip n

Do mind the older iproute2 versions didnt support the -br argument yet so omit that bit if not working.

How did you configure networking?
Do you run a desktop and do it via the GUI?
netplan with NM is the default OOTB "native" manager for Ubuntu 18.x.

I do have a desktop and configure via GUI typically. I must have been mistaken about not needing NM if it is the default OOTB.

I configured the netplan static IP according to the instructions and the host computer has internet again, although the pihole error is still the same,

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] qc65ga1dit4s3blyukv13vjfhn.org is on lo (
[✓] qc65ga1dit4s3blyukv13vjfhn.org is on enp7s0 (
[✓] doubleclick.com is via a remote, public DNS server (

*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✓] www.wikipenza.info is :: on lo (::1)
[✓] www.wikipenza.info is :: on enp7s0 ([IP6])
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (2001:4860:4860::8888)

Log: https://tricorder.pi-hole.net/h4i5EObh/

I appreciate the help so far.

If you run a desktop, configure static network settings via the GUI tool and not manually in .yaml config files.
The GUI tool will take care of how NM will be configured.
Dont forget to configure DNS server(s)!
And check with the ip commands I provided.

Ow above is not an error per se.
It just informs you that DNS resolution via IPv6 failed.
Resolution via IPv4 only works just fine.
(EDIT: You can lookup IPv6 addresses via IPv4 and vice versa)
Do you have IPv6 support upstream from your ISP?

:~$ ip -br l
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> 
enp7s0           UP             04:d4:c4:XX:XX:XX <BROADCAST,MULTICAST,UP,LOWER_UP> 

:~$ ip -br a
lo               UNKNOWN ::1/128 
enp7s0           UP    [IP6]

:~$ ip r
default via dev enp7s0 proto static metric 100 dev enp7s0 scope link metric 1000 dev enp7s0 proto kernel scope link src metric 100 

:~$ ip n dev enp7s0 lladdr 8c:b8:7e:XX:XX:XX REACHABLE dev enp7s0 lladdr c0:06:c3:XX:XX:XX REACHABLE dev enp7s0 lladdr 00:17:88:XX:XX:XX STALE

My ISP does not support upstream IPv6 according to that test. Not a problem to me. I guess the overall issue is that when using the pihole as the DNS in my router, all devices lose internet connection.

Check if you run a firewall that might block stuff:

sudo nft list tables

sudo iptables -nL

Check if the own host can resolve domains to IP's:

host pi-hole.net

Check if pihole-FTL is answering when queried:

host pi.hole localhost

host pi.hole

Check if still resolves to an IP if the domain needs to be forwarded upstream:

host pi-hole.net

Grab a Linux/Windows/MacOS client and run below on it to see if it resolves:

nslookup pi.hole

And without the Pi-hole IP:

nslookup pi.hole

If that all works, you've proven that pihole-FTL functions as expected and need to look into router/client settings.
Maybe your router has got some protective settings for which you must create an exception for Pi-hole or maybe even disable it.

1 Like

Well I just realized I was using the default policies of UFW, which blocks ports 53 and 67. I followed the instructions here: Prerequisites - Pi-hole documentation and everything clicked into place and my clients connected to the internet and pi-hole is now functioning!
I do appreciate the education on dhcpcd, and netplan. Thanks for your time!

1 Like

I marked your last reply as a solution if you dont mind.