DNS broken only on localhost

Expected Behaviour:

ping *any domain*

should work

Actual Behaviour:

DNS never resolves on the machine hosting Pi-hole.

Debug Token:

https://tricorder.pi-hole.net/hftwPWXg/

Hi all:

First time using Pi-hole. I am trying to follow Method 2 of this guide to have my router running OpenWRT 21.02.1 advertise the server Pi-hole is on as the DNS server of all the devices connected to the network.

The router and Pi-hole work perfectly fine together after following this guide for every device connected except the machine running Pi-hole where DNS resolution is completely broken after installing Pi-hole. apt is non-functional, and if I ping any domain I get "Temporary failure in name resolution." I know there are posts all over about this issue, but none of the solutions provided within those threads have worked for me permanently -- the solution in this thread worked temporarily, but the next reboot nullified it, and DNS was broken again.

I would like to use Pi-hole as the DNS resolver for the machine it is installed on -- if I edit /etc/resolv.conf to include nameserver 127.0.0.1 instead of the default nameserver 127.0.0.53 I get "Name or service not known" when using ping. Switching the nameserver to literally any other functional resolver will get the machine to work immediately every time. I am quite certain this is not a Pi-hole issue but an Ubuntu one. I am running Ubuntu 20.04.3 and using NGINX as the webserver for the admin interface (which I know is not the issue at all because the web interface works perfectly).

Per the instructions for Method 2 on that guide the Pi-hole has no other upstream DNS resolvers defined except for 192.168.1.1, the address of my router. My router is advertising the server's internal address via dnsmasq through the DHCP option "6,address of server" set by navigating to "Network -- Interfaces -- LAN -- Edit -- DHCP Server -- Advanced Settings -- DCHP Options." The Ubuntu settings page for my connection has DNS set to automatic.

Things I have tried that did not work:

  • Changing /etc/resolv.conf to only include nameserver 127.0.0.1 instead of 127.0.0.53

  • Using the package resolvconf to make above changes to /etc/resolv.conf persist upon reboot

  • Disabling the options "Never forward non-FQDNs" and "Never forward reverse lookups for private IP ranges" in the Pi-hole settings

Thanks so much for any help! I know that the solution to this will be very simple and is just something I'm not seeing because I've been trying to resolve this issue for too long.

Sounds another resolver like systemd-resolved is already claiming port 53 for the loopback interface.

You could try to either configure systemd-resolved for Pi-hole's IPv4 (as bound to your Ethernet or wifi network interface), or to disable systemd-resolved altogether.

Thanks for the very quick reply. I think something like this is probably the issue, and I played with systemd-resolved yesterday to no avail. I tried what you suggested and disabled systemd-resolved, and that did not fix the issue.

I forgot to mention that when I first started troubleshooting this /etc/resolv.conf was generated by Network Manager and not systemd-resolved -- after fiddling with `/etc/resolv.conf`` there are always comments about the latter instead of the former. I didn't uninstall either of them.

I've also tried setting the DNS server for the Ethernet connection in the Ubuntu settings to the local address of the machine and 127.0.0.1, but that does nothing either.

If I run netstat -tulpn | grep LISTEN I get the following output:

tcp        0      0 0.0.0.0:364             0.0.0.0:*               LISTEN      1119/sshd: /usr/sbi 
tcp        0      0 0.0.0.0:2095            0.0.0.0:*               LISTEN      1070/jellyfin       
tcp        0      0 0.0.0.0:2096            0.0.0.0:*               LISTEN      1070/jellyfin       
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      1480/nginx: master  
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      4321/pihole-FTL     
tcp        0      0 192.168.1.139:53        0.0.0.0:*               LISTEN      4321/pihole-FTL     
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      907/cupsd           
tcp        0      0 127.0.0.1:8888          0.0.0.0:*               LISTEN      1466/uwsgi          
tcp        0      0 127.0.0.1:3000          0.0.0.0:*               LISTEN      1072/morty          
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      1480/nginx: master  
tcp        0      0 127.0.0.1:4004          0.0.0.0:*               LISTEN      1066/filtron        
tcp        0      0 127.0.0.1:4005          0.0.0.0:*               LISTEN      1066/filtron        
tcp        0      0 127.0.0.1:4711          0.0.0.0:*               LISTEN      4321/pihole-FTL     
tcp        0      0 127.0.0.1:27017         0.0.0.0:*               LISTEN      1277/mongod         
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      1189/mysqld         
tcp6       0      0 :::364                  :::*                    LISTEN      1119/sshd: /usr/sbi 
tcp6       0      0 :::80                   :::*                    LISTEN      1480/nginx: master  
tcp6       0      0 ::1:53                  :::*                    LISTEN      4321/pihole-FTL     
tcp6       0      0 fdef:c64f:8d18:0:6af:53 :::*                    LISTEN      4321/pihole-FTL     
tcp6       0      0 2600:8806:8300:29:6a:53 :::*                    LISTEN      4321/pihole-FTL     
tcp6       0      0 fe80::6af7:28ff:fe60:53 :::*                    LISTEN      4321/pihole-FTL     
tcp6       0      0 ::1:631                 :::*                    LISTEN      907/cupsd           
tcp6       0      0 :::8443                 :::*                    LISTEN      1081/node           
tcp6       0      0 :::443                  :::*                    LISTEN      1480/nginx: master  
tcp6       0      0 ::1:4711                :::*                    LISTEN      4321/pihole-FTL     

To me it looks like Pi-hole is successfully binding to port 53 on the loopback interface. What stands out to me is that it's also binding to 192.168.1.139 (local address of the machine) on the same port. This doesn't happen for any other service I have running as one can see. I have no idea why this would be occurring.

Managed to fix the issue.

For anyone that sees this post in the future:

A. I followed the instructions in the checked comment on this AskUbuntu thread to disable systemd-resolved. This may not have actually made any difference because of B. It did bring /etc/resolv.conf back to being managed by Network Manager like it was initially.

B. I disabled the adblock package on my OpenWRT router, which had been running the whole time. DNS on the localhost worked instantaneously once adblock was fully disabled after a few seconds. This also cleared up every issue I had with connectivity on devices other than the localhost since installing Pi-hole.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.