Fresh install with Pi-Hole, Unbound and PiVPN... DNS Service NOT running

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

If you are Experiencing issues with a Pi-hole install that has non-standard elements (e.g you are using nginx instead of lighttpd, or there is some other aspect of your install that is customised) - please use the Community Help category.

Expected Behaviour:

RPi 4b & for things to work

Actual Behaviour:

pi@PiNet:~ $ pihole status
[✗] DNS service is NOT running

Debug Token:

[?] Would you like to upload the log? [y/N] y
* Using curl for transmission.
* curl failed, falling back to netcat for transmission.
nc: getaddrinfo for host "tricorder.pi-hole.net" port 9999: Temporary failure in name resolution
[✗] There was an error uploading your debug log.

  • Please try again or contact the Pi-hole team for assistance.
  • A local copy of the debug log can be found at: /var/log/pihole_debug.log

Absolutely fresh install on a Raspberry Pi 4b. Here's every step I took, even listing a few that aren't required, just for completeness sake, and I have replicated these results numerous times, trying things in various orders. I have realized that a temporary fix would be to open /etc/resolv.conf and modify that, but that only works until a restart, and I don't think I should have to do that every single time.

Step 1: Use balenaEtcher to burn "retropie-buster-4.6-rpi2_rpi3.img.gz". (The latest lite version from www.raspberrypi.org)
Step 2: Unplug and replug USB to create file "ssh" on boot drive of MicroSD Card, eject and boot RPi.
Step 3: PuTTY into RPi and run sudo raspi-config and setup as necessary.
Step 4: Reboot with sudo shutdown -r now.
Step 5: run command curl https://download.argon40.com/argon1.sh | bash as I have an Argon ONE case for my RPi.
Step 6: run command argonone-config to set my preferences (I know, totally unrelated to the issues, but just covering all bases and step-by-step of install).
Step 7: run command(s) sudo apt install -y unattended-upgrades && sudo apt update && sudo apt -y dist-upgrade && sudo apt -y full-upgrade this might very well be excessive and repeative, but oh well, I figured better safe than sorry on a fresh install, and well, I'm still sorry.
Step 8: Reboot with sudo shutdown -r now.
Now here I've tried a couple of variations, including trying to install PiVPN first and whatnot, so I figured I'd try and install that after Pi-Hole this time around, doesn't matter though, the end result is always the same.
Step 9: execute command curl -sSL https://install.pi-hole.net | bash with the following options:
Interface: eth0
Upstream DNS Provider: Cloudflare
Third Party Lists: default
Protocols: Default
Static IP Address: 192.168.0.111/24 Gateway: 192.168.0.1
Web admin interface, web server, log queries and privacy mode for FTL; all default
now here, it'll say supported OS Detected throughout the scrolling (I mean, why wouldn't it, this is the OS straight from the website?! But, we'll come back to this)
Step 10: execute pihole -a -p set my preferred password
Step 11: execute curl -L https://install.pivpn.io | bash to install PiVPN with the following options:
IPv4 address: 192.168.0.111/24
Gateway: 192.168.0.1
User: pi
Installation mode: OpenVPN (I don't know enough about WireGuard, but have used OpenVPN for awhile now)
Installation mode: default (Don't really care, just mainly looking to VPN for Pi-Hole from mobile devices)
Port: 3763 (picked at random, but used in the past without issue)
We have detected a Pi-hole installation, do you want to use it as the DNS server for the VPN, so you get ad blocking on the go?: Yes
Public OP or DNS: DDNS address
unattended upgrades: no, already installed
allowed to reboot the RPi
Step 12: execute sudo apt -y install unbound
Got error message:

Created symlink /etc/systemd/system/unbound.service.wants/unbound-resolvconf.service → /lib/systemd/system/unbound-resolvconf.service.
Job for unbound.service failed because the control process exited with error code.
See "systemctl status unbound.service" and "journalctl -xe" for details.
Job for unbound.service failed because the control process exited with error code.
See "systemctl status unbound.service" and "journalctl -xe" for details.
invoke-rc.d: initscript unbound, action "start" failed.
● unbound.service - Unbound DNS server
   Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset: enabled)
   Active: activating (auto-restart) (Result: exit-code) since Thu 2020-07-30 17:32:11 MDT; 25ms ago
     Docs: man:unbound(8)
  Process: 1107 ExecStartPre=/usr/lib/unbound/package-helper chroot_setup (code=exited, status=0/SUCCESS)
  Process: 1113 ExecStartPre=/usr/lib/unbound/package-helper root_trust_anchor_update (code=exited, status=0/SUCCESS)
  Process: 1117 ExecStart=/usr/sbin/unbound -d $DAEMON_OPTS (code=exited, status=1/FAILURE)
 Main PID: 1117 (code=exited, status=1/FAILURE)
Processing triggers for systemd (241-7~deb10u4+rpi1) ...
Processing triggers for man-db (2.8.5-2) ...
Processing triggers for libc-bin (2.28-10+rpi1) ...

Step 13: Reboot with sudo shutdown -r now.
Step 14: Repeat Step 12: execute sudo apt -y install unbound again
Get message:

pi@PiNet:~ $ sudo apt -y install unbound
Reading package lists... Done
Building dependency tree
Reading state information... Done
unbound is already the newest version (1.9.0-2+deb10u2).
The following package was automatically installed and is no longer required:
  rpi-eeprom-images
Use 'sudo apt autoremove' to remove it.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Must be installed... Whatever, guess the failure message was unrelated before. But, just for fun, also ran:

pi@PiNet:~ $ sudo systemctl status unbound.service
● unbound.service - Unbound DNS server
   Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Thu 2020-07-30 17:34:38 MDT; 3min 20s ago
     Docs: man:unbound(8)
  Process: 1135 ExecStartPre=/usr/lib/unbound/package-helper chroot_setup (code=exited, status=0/SUCCESS)
  Process: 1138 ExecStartPre=/usr/lib/unbound/package-helper root_trust_anchor_update (code=exited, status=0/SUCCESS)
  Process: 1142 ExecStart=/usr/sbin/unbound -d $DAEMON_OPTS (code=exited, status=1/FAILURE)
 Main PID: 1142 (code=exited, status=1/FAILURE)

Jul 30 17:34:38 PiNet systemd[1]: unbound.service: Failed with result 'exit-code'.
Jul 30 17:34:38 PiNet systemd[1]: Failed to start Unbound DNS server.
Jul 30 17:34:38 PiNet systemd[1]: unbound.service: Service RestartSec=100ms expired, scheduling restart.
Jul 30 17:34:38 PiNet systemd[1]: unbound.service: Scheduled restart job, restart counter is at 5.
Jul 30 17:34:38 PiNet systemd[1]: Stopped Unbound DNS server.
Jul 30 17:34:38 PiNet systemd[1]: unbound.service: Start request repeated too quickly.
Jul 30 17:34:38 PiNet systemd[1]: unbound.service: Failed with result 'exit-code'.
Jul 30 17:34:38 PiNet systemd[1]: Failed to start Unbound DNS server.

Guess everything isn't quite as it seems, don't know what any of this means though

Step 15: do the following (2) commands: wget -O root.hints https://www.internic.net/domain/named.root & sudo mv root.hints /var/lib/unbound/
Step 16: Attempt to do sudo nano /etc/unbound/unbound.conf.d/pi-hole.conf just to find out it's empty so I paste the following into it:

server:
    verbosity: 0
    
    interface: 127.0.0.1
    port: 5335
    do-ip4: yes
    do-udp: yes
    do-tcp: yes
    
    # May be set to yes if you have IPv6 connectivity
    do-ip6: no

    # You want to leave this to no unless you have *native* IPv6. With 6to4 and
    # Terredo tunnels your web browser should favor IPv4 for the same reasons
    prefer-ip6: no
    
    # Use this only when you downloaded the list of primary root servers!
    # Location of root.hints
    root-hints: "/var/lib/unbound/root.hints"
    
    # Trust glue only if it is within the servers authority
    harden-glue: yes
    
    # Ignore very large queries.
    harden-large-queries: yes
    
    # Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
    # If you want to disable DNSSEC, set harden-dnssec stripped: no
    harden-dnssec-stripped: yes
    
    # Use Capitalization randomization
    # This is an experimental resilience method which uses upper and lower case letters in the question hostname to obtain randomness.
    # Two names with the same spelling but different case should be treated as identical.
    # Attackers hoping to poison a DNS cache must guess the mixed-case encoding of the query.
    # This increases the difficulty of such an attack significantly
    use-caps-for-id: yes
    
    # Reduce EDNS reassembly buffer size.
    # Suggested by the unbound man page to reduce fragmentation reassembly problems
    edns-buffer-size: 1472
    
    # Rotates RRSet order in response (the pseudo-random 
    # number is taken from Ensure privacy of local IP 
    # ranges the query ID, for speed and thread safety).  
    # private-address: 192.168.0.0/16
    rrset-roundrobin: yes
    
    # Time to live minimum for RRsets and messages in the cache. If the minimum
    # kicks in, the data is cached for longer than the domain owner intended,
    # and thus less queries are made to look up the data. Zero makes sure the
    # data in the cache is as the domain owner intended, higher values,
    # especially more than an hour or so, can lead to trouble as the data in
    # the cache does not match up with the actual data anymore
    cache-min-ttl: 300
    cache-max-ttl: 86400
    msg-cache-size: 128m
    rrset-cache-size: 256m
    
    # Have unbound attempt to serve old responses from cache with a TTL of 0 in
    # the response without waiting for the actual resolution to finish. The
    # actual resolution answer ends up in the cache later on. 
    serve-expired: yes
    
    # Harden against algorithm downgrade when multiple algorithms are
    # advertised in the DS record.
    harden-algo-downgrade: yes
    
    # Ignore very small EDNS buffer sizes from queries.
    harden-short-bufsize: yes
    
    # Refuse id.server and hostname.bind queries
    hide-identity: yes
    
    # Report this identity rather than the hostname of the server.
    identity: "Server"
    
    # Refuse version.server and version.bind queries
    hide-version: yes
    
    # Prevent the unbound server from forking into the background as a daemon
    do-daemonize: no
    
    # Number  of  bytes size of the aggressive negative cache.
    neg-cache-size: 4M
    
    # Send minimum amount of information to upstream servers to enhance privacy
    qname-minimisation: yes
    
    # Deny queries of type ANY with an empty response.
    # Works only on version 1.8 and above
    # deny-any: yes

    # Do no insert authority/additional sections into response messages when
    # those sections are not required. This reduces response size
    # significantly, and may avoid TCP fallback for some responses. This may
    # cause a slight speedup
    minimal-responses: yes
    
    # Perform prefetching of close to expired message cache entries
    # This only applies to domains that have been frequently queried
    # This flag updates the cached domains
    prefetch: yes
    
    # Fetch the DNSKEYs earlier in the validation process, when a DS record is
    # encountered. This lowers the latency of requests at the expense of little
    # more CPU usage.
    prefetch-key: yes
    
    # One thread should be sufficient, can be increased on beefy machines. In reality for 
    # most users running on small networks or on a single machine, it should be unnecessary
    # to seek performance enhancement by increasing num-threads above 1.
    num-threads: 1

    # more cache memory. rrset-cache-size should twice what msg-cache-size is.
    msg-cache-size: 50m
    rrset-cache-size: 100m
   
    # Faster UDP with multithreading (only on Linux).
    so-reuseport: yes
    
    # Ensure kernel buffer is large enough to not lose messages in traffix spikes
    so-rcvbuf: 4m
    so-sndbuf: 4m
    
    # Set the total number of unwanted replies to keep track of in every thread.
    # When it reaches the threshold, a defensive action of clearing the rrset
    # and message caches is taken, hopefully flushing away any poison.
    # Unbound suggests a value of 10 million.
    unwanted-reply-threshold: 10000
    
    # Enable ratelimiting of queries (per second) sent to nameserver for
    # performing recursion. More queries are turned away with an error
    # (servfail). This stops recursive floods (e.g., random query names), but
    # not spoofed reflection floods. Cached responses are not rate limited by
    # this setting. Experimental option.
    ratelimit: 1000
    
    # Minimize logs
    # Do not print one line per query to the log
    log-queries: no
    # Do not print one line per reply to the log
    log-replies: no
    # Do not print log lines that say why queries return SERVFAIL to clients
    logfile: /dev/null
    
    # Ensure privacy of local IP ranges
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: 172.16.0.0/12
    private-address: 10.0.0.0/8
    private-address: fd00::/8
    private-address: fe80::/10

Step 17: run the following two commands from a previous automatic Pi-Hole update script I've used before so I have port 80 available for an Apache server also running on the RPi (to be added later): sudo sed -i.bak 's/80/8134/1' /etc/lighttpd/lighttpd.conf & sudo sed -i.bak 's/cache-size=10000/cache-size=0/1' /etc/dnsmasq.d/01-pihole.conf
Step 18: Reboot with sudo shutdown -r now.

Step 19: execute pihole status

  [✗] DNS service is NOT running

Step 20: execute pihole -d

[✓] ** FINISHED DEBUGGING! **

    * The debug log can be uploaded to tricorder.pi-hole.net for sharing with developers only.
    * For more information, see: https://pi-hole.net/2016/11/07/crack-our-medical-tricorder-win-a-raspberry-pi-3/
    * If available, we'll use openssl to upload the log, otherwise it will fall back to netcat.

[?] Would you like to upload the log? [y/N] y
    * Using curl for transmission.
    * curl failed, falling back to netcat for transmission.
nc: getaddrinfo for host "tricorder.pi-hole.net" port 9999: Temporary failure in name resolution
[✗]  There was an error uploading your debug log.
   * Please try again or contact the Pi-hole team for assistance.
   * A local copy of the debug log can be found at: /var/log/pihole_debug.log

These were the only things marked in red that I saw during the dubug:

*** [ DIAGNOSING ]: Operating system (I said we'd come back to this, and here we are)
[✗] Distro:  Raspbian
[✗] Error: Raspbian is not a supported distro (https://discourse.pi-hole.net/t/hardware-software-requirements/273)

*** [ DIAGNOSING ]: Networking
[✓] IPv4 address(es) bound to the eth0 interface:
   192.168.0.111/24 matches the IP found in /etc/pihole/setupVars.conf

[✓] IPv6 address(es) bound to the eth0 interface:
   fe80::xxxx:xxxx:xxxx:xxxx does not match the IP found in /etc/pihole/setupVars.conf (https://discourse.pi-hole.net/t/use-ipv6-ula-addresses-for-pi-hole/2127)

   ^ Please note that you may have more than one IP address listed.
   As long as one of them is green, and it matches what is in /etc/pihole/setupVars.conf, there is no need for concern.

   The link to the FAQ is for an issue that sometimes occurs when the IPv6 address changes, which is why we check for it.

[i] Default IPv4 gateway: 192.168.0.1
   * Pinging 192.168.0.1...
[✓] Gateway responded.

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✗] Failed to resolve www.dziennikuprowadzono.online via localhost (127.0.0.1)
[✗] Failed to resolve www.dziennikuprowadzono.online via Pi-hole (192.168.0.111)
[✓] doubleclick.com is 172.217.9.46 via a remote, public DNS server (8.8.8.8)

*** [ DIAGNOSING ]: Dashboard and block page
[✗] Block page X-Header: X-Header does not match or could not be retrieved.

[✗] Web interface X-Header: X-Header does not match or could not be retrieved.

I'm positive I just did something wrong or something and I got head firmly inserted somewhere it shouldn't be. But, if someone could please help me see the sunlight again, I'd be rather grateful.

Your all-in-one multi-software package setup results in a convoluted array of error messages that's neither easy to read nor trace. :wink:

My guess would be unbound is refusing cooperation because Pi-hole has already claimed port 53, and PiVPN is introducing incompatibilities with Pi-hole's embedded dnsmasq configuration.

May I recommend a step-by-step approach?

  1. Start with just the OS and Pi-hole
    Verify that works for you as expected. Get to know Pi-hole and how to deal with common configuration issues before moving on.
  2. Install unbound as Pi-hole's upstream resolver
    Follow Pi-hole's guide for unbound, and again verify it works as expected
  3. Add a VPN server of your choice.
    Consider consulting Pi-hole's documentation on OpenVPN. If you stick with PiVPN, be aware that this often compromises configuration for Pi-hole, which usually (but not always) can be addressed by deleting PiVPN's dnsmasq configuration details.
1 Like

Thank you for your response Bucking_Horn.

Couple of things to note, I will fully agree with the assessment that Unbound is the reason that everything keeps going sideways with this basic install. Although I'm a little confused with the "all-in-one multi-software package setup": remark. This wasn't a singular package that was installed with Pi-Hole, PiVPN and Unbound. These were all individual packages that were installed.

As far as your step-by-step approach, if it's just Pi-Hole and PiVPN installed (or even OpenVPN for that matter) the RPi has no problems. But as soon as Unbound gets brought into the mix, things don't continue to work and Pi-Hole doesn't like that. Why else would I be getting the error in debug that Raspbian isn't a supported distro when, as I noted before I even ran the debug, it was saying it was fine. Fun fact, I spent most of yesterday and the day before trying to make this 3 packages play nicely, and as I was going along, I had my Notepad++ open on the other monitor and was trying to go back and forth and I noted about the Distro in step 9 way before I ran debug because I always ran into the exact same issue and was anticipating Pi-Hole to say unsupported distro.
And with PiVPN, it specifically detected Pi-Hole and asked if I wanted to make them play nicely, which as I put in the post, I said yes this time. I have tried to also setup OpenVPN, yes following the Pi-Hole guide, Unbound, following the guide, tried installing in various combinations, admittidly, Unbound being the last, and Pi-Hole always gives me the same error, and for the life of me, I just can't figure it out.

If it would appease the courts, I will happily do an OBS recording, when I get back as I'm leaving for 3 days tomorrow, of the complete process from flash to error instead of putting everything into text. Just for funsies, I'll even have the guides pulled up and to the side so there's no doubt that I am in fact following the guides.
I'm going to assume there's no actual help coming from this thread, so I'm going to just put my backup image back on so my family has my previous Pi-Hole setup while I'm gone... They never realized how spoiled they were with game ads until I decided to try and do things "proper and right" instead of just hacking everything together in a way that things still worked, just in case something happens to me, the old lady said she'll never find someone to figure out just what I did to make things work as I have. So I wanted to do everything by the book, and well, that's not working out for me either. But fear not, if someone wants to tackle issue(s) the actual image of this current setup, I can easily replicate the problem, by following the exact steps I've laid out in my original post, when I get back.

The commands you used are different; the guide does not suggest a reboot nor to install it twice; you started the service well before the guide would have asked for it; you completely waive the commands meant to help you verify everything went smoothely, and you omit configuring Pi-hole to use unbound, installing some third-party webserver configuration tweaks instead.

As fas as can be derived from the installation steps you've posted, it's clear you didn't follow the unbound guide, hence my advice to follow it.

You already have my recommendation for order of installation and proper verification that each package works individually after each package has been installed.

It's up to you to respect and follow that advice, but I would think it would allow us to deal with one error at a time, thus avoiding any potential subsequent errors that may well not manifest once you eliminate the root cause.

A post was split to a new topic: VPN on router vs. VPN on dedicated machine

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