Pi-Hole is unable to resolve name (Ubuntu 18.04)

realtebo · August 14, 2018, 2:40pm

I'm here to ask you help to diagnose a problem on a ubuntu 18.04.

I'm working on a VM so I createad a snpshot before installation of pihole.

The problem can be summarized s:

before installation I can ping google.it
after installation I cannot ping

It's the third VM I setup with pihole, but this is the first with this problem. I am sure I'm doing wrong something in the setup of the VM, so I'd like an help to understand what I am doing that is able to break something while pihole is installing.

dig pihole3.ismyservice.space
; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> pihole3.ismyservice.space
;; global options: +cmd
;; connection timed out; no servers could be reached

The following file is not changed, it was the same before of installation.

realtebo@192.168.1.224:~$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 127.0.0.53
search homenet.telecomitalia.it

Also, my ip addr infos was not changes

realtebo@192.168.1.224:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:50:56:2d:ed:31 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.224/24 brd 192.168.1.255 scope global dynamic ens33
       valid_lft 19752sec preferred_lft 19752sec
    inet6 fe80::250:56ff:fe2d:ed31/64 scope link 
       valid_lft forever preferred_lft forever

What else ?

realtebo@pihole3:/etc/pihole$ cat install.log 
  [✓] Installing scripts from /etc/.pihole

  [i] Installing configs from /etc/.pihole...
  [✓] No dnsmasq.conf found... restoring default dnsmasq.conf...
  [✓] Copying 01-pihole.conf to /etc/dnsmasq.d/01-pihole.conf

  [✓] Installing latest Cron script

  [✓] Installing latest logrotate script

  [i] FTL Checks...
  [✓] Detected x86_64 architecture
  [i] Checking for existing FTL binary...
  [✓] Downloading and Installing FTL


  [i] Skipping firewall configuration
  [✓] man pages installed and database updated
realtebo@pihole3:/etc/pihole$ cat setupVars.conf 
PIHOLE_INTERFACE=ens33
IPV4_ADDRESS=0.0.0.0
IPV6_ADDRESS=
PIHOLE_DNS_1=8.8.8.8
PIHOLE_DNS_2=8.8.4.4
QUERY_LOGGING=true
INSTALL_WEB_SERVER=false
INSTALL_WEB_INTERFACE=false
LIGHTTPD_ENABLED=false
realtebo@pihole3:/etc/pihole$

I see in that log of installation that is not able to install FTL.

realtebo · August 14, 2018, 2:45pm

USEFULL INFO:

The previous setup was done manually, choosing to do not install web gui and do not install lighthttpd

Doing a normal installation, with webgui and lighthttpd all is working.

I'm trying to understand which point of the installation causes the breaking of name resolution.
I'm too new in linux to be able to understand it alone.

realtebo · August 14, 2018, 2:49pm

All works even not installing webui, but installing lighttpd.

Something in this portion of setup must be run even if lighttp is not installed

MaDa · August 15, 2018, 1:57pm

Have you already noticed that.....?

https://www.reddit.com/r/pihole/comments/96sl6f/installating_packages_stuck_at_100/

realtebo · August 15, 2018, 10:40pm

@MaDa: thansk

In first thread you linked me, I understand that it's due to the absence of dhcpd5 but that it can be resolved with a manual -r ?!?!?! I don't understand,

Also ... why I can make it works installing all the optional webserver, web interface and lighttpd?

If there is a problem with a prerequisite, it must fail any wat... or not?

I'll try the second link idea: add multiverse to apt. I'll update you

realtebo · August 15, 2018, 10:50pm

installation of dhcpd5 and dialog works fine without altering apt sources.list

Anyway, I can ping until 90% of the installation process... the suddenly , no name can be resolved...

Today i'll try to run with -x option ... I really really think that some developer should take care of the problem.
I've 10 nodes with ubuntu 18.04 running happily, but this new one no... Obviously I cannot compare file by file what make the new VM different from the previous....

RamSet · August 15, 2018, 11:08pm

Without knowing WHAT fails and WHERE it fails, no one will be able to fix it.

There are a lot of variables and dependencies that might cause issues.

In order to get adequate help, please post pertinent information, logs and error messages.

realtebo · August 15, 2018, 11:17pm

I found the crucial moment, putting 'ping's before and after every single step.

The mysterious problem is happening when "Disabling systemd-resolved DNSStubListener and restarting systemd-resolved"

See this link to my fork: This is the moment... before I can resolve name, just at the end of this phase, I cannot no more resolve name.

https://github.com/realtebo/pi-hole/blob/test_install/automated%20install/basic-install.sh#L2470-L2482

This is the debug output, sorry for strange format, is captured

"[i] Ping 2", "", "PING google.it (216.58.205.99) 56(84) bytes of data.", "64 bytes from mil04s26-in-f3.1e100.net (216.58.205.99): icmp_seq=1 ttl=54 time=12.1 ms ",

"--- google.it ping statistics ---", "1 packets transmitted, 1 received, 0% packet loss, time 0ms", 

"rtt min/avg/max/mdev = 12.175/12.175/12.175/0.000 ms", 

"[i] Testing if systemd-resolved is enabled  ", 

"[i] Testing if systemd-resolved DNSStub-Listener is active", 

"[✓] Disabling systemd-resolved DNSStubListener and restarting systemd-resolved", 

"[i] Ping 3", "", "ping: google.it: Errore temporaneo nella risoluzione del nome"

realtebo · August 16, 2018, 10:05am

Narrowing the problem I found that the problem is changing #DNSStubListener=yes to DNSStubListener=no

The line changing the config is this:

github.com

pi-hole/pi-hole/blob/993beab3b7bd2dab01dffd4f84f3b0f6a5c3a190/automated install/basic-install.sh#L1408


    # Check if Systemd-resolved's DNSStubListener is enabled and active on port 53
    if check_service_active "systemd-resolved"; then
        # Check if DNSStubListener is enabled
        echo -en "  ${OVER}  ${INFO} Testing if systemd-resolved DNSStub-Listener is active"
        if ( grep -E '#?DNSStubListener=yes' /etc/systemd/resolved.conf &> /dev/null ); then
            # Disable the DNSStubListener to unbind it from port 53
            # Note that this breaks dns functionality on host until dnsmasq/ftl are up and running
            echo -en "${OVER}  ${TICK} Disabling systemd-resolved DNSStubListener"
            # Make a backup of the original /etc/systemd/resolved.conf
            # (This will need to be restored on uninstallation)
            sed -r -i.orig 's/#?DNSStubListener=yes/DNSStubListener=no/g' /etc/systemd/resolved.conf
            echo -e " and restarting systemd-resolved"
            systemctl reload-or-restart systemd-resolved
        else
            echo -e "${OVER}  ${INFO} Systemd-resolved does not need to be restarted"
        fi
    else
        echo -e "${OVER}  ${INFO} Systemd-resolved is not enabled"
    fi
}

I know that this is really good and needed and well documented.

I cannot understand why I need to NOT disable the DNSStubListener in my specific case. What have I done so wrong to break a good behaviour of pi-hole ?

Mcat12 · August 20, 2018, 12:36am

Make a new debug token. What is the output of sudo service pihole-FTL status -l

system · September 10, 2018, 12:36am

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