New install -- DNS resolution is not available

dkozinn · July 10, 2022, 10:40pm

Expected Behaviour:

Pi-hole installs successfully.

This is a new install as a backup for another instance of Pi-hole on my network. This install is on a Raspberry Pi 4B running Raspbian 10 (Buster). The Pi has been running unrelated software with no DNS or Internet access issues.

Actual Behaviour:

I am running install via sudo bash basic-install.sh after cloning the repo to my local machine, which did not previously have Pi-hole installed. The install ends with:

  [✗] DNS resolution is currently unavailable
  [✗] DNS resolution is not available

(I get the same error using pihole -g.)

/etc/resolv.conf contains: nameserver 8.8.8.8, systemctl shows that pihole-FTL is running, the admin console is responding on tcp/80, and DNS resolution is working (tested both locally and from another machine on my home network pointing to this new installation.)

In other words, it seems that everything is working, but I do see errors in the debug log and I'd like to have the installation finish cleanly. (I have tried both update and reset several times.)

Thanks in advance.

Debug Token:

mw0sq4me

dkozinn · July 12, 2022, 5:52pm

Anyone? Let me know if I need to generate a new debug token.

jfb · July 12, 2022, 5:57pm

Your gravity list is empty:

[✓] Web interface X-Header: X-Pi-hole: The Pi-hole Web interface is working!

*** [ DIAGNOSING ]: Gravity Database
-rw-rw-r-- 1 pihole pihole 92K Jul 10 16:05 /etc/pihole/gravity.db

*** [ DIAGNOSING ]: Info table
   property              value                                   
   --------------------  ----------------------------------------
   version               15                                      
   Last gravity run finished at:

Your gravity database may be corrupt:

[2022-07-10 18:06:09.930 20964/T20968] gravityDB_count(SELECT value FROM info WHERE property = 'gravity_count';) - SQL error step no more rows available

What are the complete outputs of the following from the Pi terminal:

pihole-FTL sqlite3 gravity.db "PRAGMA integrity_check"

pihole -g -f

dkozinn · July 12, 2022, 6:03pm

pi@pi2:~ $ pihole-FTL sqlite3 gravity.db "PRAGMA integrity_check"
ok

pi@pi2:~ $ pihole -g -f
  [✓] Deleting existing list cache
  [✗] DNS resolution is currently unavailable
  [✗] DNS resolution is not available

though clearly, DNS resolution is available:

pi@pi2:~ $ host pi-hole.net
pi-hole.net has address 3.18.136.52
pi-hole.net mail is handled by 10 sunfire.mxrouting.net.
pi-hole.net mail is handled by 20 sunfire-relay.mxrouting.net.

jfb · July 12, 2022, 7:35pm

Try pihole -g -R

dkozinn · July 12, 2022, 7:47pm

Same as before:

pi@pi2:~ $ pihole -g -R 
  [✗] DNS resolution is currently unavailable
  [✗] DNS resolution is not available

dkozinn · July 12, 2022, 8:42pm

I am planning to install Unbound after I get pi-hole running; would it help/hurt this process if I were to install it now? I'm certainly willing to wait, just figured I'd mention it.

Bucking_Horn · July 12, 2022, 8:53pm

The machine hosting Pi-hole would use 8.8.8.8 for DNS.

Try

dig  pi-hole.net @192.168.0.49

According to your debug log, I'd expect that to fail:

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✗] Failed to resolve  on lo (127.0.0.1)
[✓] No IPv4 address available on eth0
[✗] Failed to resolve  on wlan0 (192.168.0.49)
[✓] doubleclick.com is 142.250.72.110 via a remote, public DNS server (8.8.8.8)

Could you provide a new debug token, so we could verify that at least your gravity has been rebuilt?

jfb · July 12, 2022, 8:54pm

Unbound should be completely separate, but I would resolve your current problem before changing more on the system.

dkozinn · July 12, 2022, 9:25pm

Bizarrely it doesn't fail:

pi@pi2:~ $ dig  pi-hole.net @192.168.0.49

; <<>> DiG 9.11.5-P4-5.1+deb10u7-Raspbian <<>> pi-hole.net @192.168.0.49
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27993
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;pi-hole.net.                   IN      A

;; ANSWER SECTION:
pi-hole.net.            127     IN      A       3.18.136.52

;; Query time: 26 msec
;; SERVER: 192.168.0.49#53(192.168.0.49)
;; WHEN: Tue Jul 12 17:18:18 EDT 2022
;; MSG SIZE  rcvd: 56

I even tried it from another machine on that network and get the same result.

Here's the new debug token: llU1iL7i

I believe you have this info in the debug log, but I see that pihole-FTL is listening on tcp & udp 53, is that expected?

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      20807/lighttpd      
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      20964/pihole-FTL    
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      527/sshd            
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      15509/cupsd         
tcp        0      0 127.0.0.1:4711          0.0.0.0:*               LISTEN      20964/pihole-FTL    
tcp        0      0 0.0.0.0:5900            0.0.0.0:*               LISTEN      513/vncserver-x11-c 
udp        0      0 0.0.0.0:53              0.0.0.0:*                           20964/pihole-FTL    
udp        0      0 0.0.0.0:68              0.0.0.0:*                           464/dhcpcd          
udp        0      0 0.0.0.0:631             0.0.0.0:*                           15510/cups-browsed  
udp        0      0 0.0.0.0:51877           0.0.0.0:*                           372/avahi-daemon: r 
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           372/avahi-daemon: r

jfb · July 12, 2022, 9:25pm

Yes. 53 is the DNS port, and TCP and UDP are protocols.

Bucking_Horn · July 12, 2022, 9:40pm

Your gravity database is still empty.
This also explains the reported failure, as that would be for a blocked domain, which would have to be retrieved from the database.

What's the output of

dig raw.githubusercontent.com

dkozinn · July 12, 2022, 10:27pm

As requested:

pi@pi2:~ $ dig raw.githubusercontent.com

; <<>> DiG 9.11.5-P4-5.1+deb10u7-Raspbian <<>> raw.githubusercontent.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53147
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;raw.githubusercontent.com.     IN      A

;; ANSWER SECTION:
raw.githubusercontent.com. 1425 IN      A       185.199.108.133
raw.githubusercontent.com. 1425 IN      A       185.199.109.133
raw.githubusercontent.com. 1425 IN      A       185.199.110.133
raw.githubusercontent.com. 1425 IN      A       185.199.111.133

;; Query time: 18 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Jul 12 18:24:06 EDT 2022
;; MSG SIZE  rcvd: 118

dkozinn · July 12, 2022, 10:31pm

Thanks, what I was asking (not very clearly, sorry) was whether it was expected that it would be listening at this point and on those ports. I'm a perimeter security engineer in my spare time (well, I don't let my boss know I consider it spare ). I am most definitely not a Linux newbie and not afraid fo the CLI, if there's anything I can run that might help further diagnose/resolve this.

jfb · July 12, 2022, 10:33pm

When you run this command, do you see the content of the blocklist on your screen?

curl https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts

The beginning lines should look like this:

# Title: StevenBlack/hosts
#
# This hosts file is a merged collection of hosts from reputable sources,
# with a dash of crowd sourcing via GitHub
#
# Date: 04 July 2022 21:06:51 (UTC)
# Number of unique domains: 110,091

dkozinn · July 12, 2022, 10:36pm

Yep, that's exactly what I get, all 116,682 lines worth.

Bucking_Horn · July 12, 2022, 10:40pm

So we just checked that there is no issue in accessing the blocklist, which could have explained why your gravity doesn't populate.

Let's try to manually move that empty db out of they way:

sudo service pihole-FTL stop

sudo mv /etc/pihole/gravity.db ~/gravity.empty.db

sudo service pihole-FTL start

pihole -g -f

dkozinn · July 12, 2022, 11:07pm

Still no joy:

pi@pi2:~ $ pihole -g -f
  [i] Creating new gravity database
  [i] Migrating content of /etc/pihole/adlists.list into new database
  [✓] Deleting existing list cache
  [✗] DNS resolution is currently unavailable
  [✗] DNS resolution is not available

I stopped/started pihole-FTL using systemctl instead of service, any chance that made a difference?

Also, because it's always permissions, here's /etc/pihole, in case something looks wrong:

pi@pi2:~ $ ll /etc/pihole
total 3060
-rw-r--r-- 1 root   root        65 Jul 10 16:16 adlists.list.old
-rw-r--r-- 1 root   root         0 Jul 10 16:05 custom.list
-rw-r--r-- 1 pihole pihole       0 Jul 10 16:05 dhcp.leases
-rw-r--r-- 1 root   root       651 Jul 10 18:06 dns-servers.conf
-rw-r--r-- 1 root   root        21 Jul 12 18:52 GitHubVersions
-rw-rw-r-- 1 pihole pihole   94208 Jul 12 19:00 gravity.db
-rw-r--r-- 1 root   root      1137 Jul 10 18:06 install.log
-rw-r--r-- 1 root   root        20 Jul 12 19:00 localbranches
-rw-r--r-- 1 root   root        43 Jul 12 19:00 localversions
-rw-r--r-- 1 root   root       241 Jul 10 16:05 logrotate
-rw-r--r-- 1 pihole pihole 2908160 Jul 10 16:05 macvendor.db
drwxr-xr-x 2 root   root      4096 Jul 12 19:00 migration_backup
-rw-rw-r-- 1 pihole root       127 Jul 10 18:06 pihole-FTL.conf
-rw-rw-r-- 1 pihole pihole   81920 Jul 12 19:05 pihole-FTL.db
-rw-r--r-- 1 root   root       340 Jul 10 18:06 setupVars.conf
-rw-r--r-- 1 root   root       340 Jul 10 16:23 setupVars.conf.update.bak
pi@pi2:~ $ ll -d /etc/pihole
drwxrwxr-x 3 pihole pihole 4096 Jul 12 19:05 /etc/pihole

yubiuser · July 13, 2022, 10:23am

Why did you first clone the repo?
_

This shows a number of issues: your gravity.db is still empty and there is no log output of /var/log/pihole/FTL.log. Also your local.list is missing, which should have been generated by gravity.

github.com

pi-hole/pi-hole/blob/aefbe1f5b6225b7476fe08264c62da84aaa61fa0/gravity.sh#L816-L825


      
          gravity_generateLocalList() {
            # Empty $localList if it already exists, otherwise, create it
            echo "### Do not modify this file, it will be overwritten by pihole -g" > "${localList}"
            chmod 644 "${localList}"
          
            # Add additional LAN hosts provided by OpenVPN (if available)
            if [[ -f "${VPNList}" ]]; then
              awk -F, '{printf $2"\t"$1".vpn\n"}' "${VPNList}" >> "${localList}"
            fi
          }

dkozinn · July 13, 2022, 12:25pm

No specific reason other than I wanted to try using that method as per "Alternative Methods" #1. I'm happy to use the standard method if you suggest.