Setting up a Libre Computer Sweet Potato SBC with Debian and Pi-Hole

Installing and configuring Pi-Hole

For now I just wanted to test this out as a secondary Pi-Hole, in case I reboot or shut off my home server which runs the main Pi-Hole instance as a Docker container. For the Sweet Potato, I decided to go bare metal and basically followed my own guide on setting up Pi-Hole, using the auto-install script with curl -sSL https://install.pi-hole.net | bash. I also made sure to change the random generated password with pihole -a -p newpassword.

Since I already had an instance of Pi-Hole running on another host, I used Gravity Sync to push the configuration from there onto the new Pi-Hole instance in the Sweet Potato — first by installing and setting it up on both hosts with curl -sSL https://raw.githubusercontent.com/vmstan/gs-install/main/gs-install.sh | bash, then on pushing the config from the original Pi-Hole to the Sweet Potato with command gravity-sync push. Finally I set it to regularly auto-sync the Pi-Holes with gravity-sync auto.

Now that all my ad lists, DNS records and other settings are on the Sweet Potato’s Pi-Hole instance, I wanted to set up DNS over TLS with Unbound. My main instance of Pi-Hole uses cloudflared for DNS over HTTPS, so I figured why not change it up here. (Someday I may keep this as the only Pi-Hole and remove the container instance from my home server, since it doesn’t really need to be on 24/7 otherwise.)

I followed the official Pi-Hole docs instructions for using Unbound as a recursive DNS server to the letter, and had everything up and running within 5 minutes. In short:

1. Install Unbound via the Debian package manager:

sudo apt install unbound -y

2. Create a new file at /etc/unbound/unbound.conf.d/pi-hole.conf and copy/paste the below into it:

server:
    # If no logfile is specified, syslog is used
    # logfile: "/var/log/unbound/unbound.log"
    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!
    # If you use the default dns-root-data package, unbound will find it automatically
    #root-hints: "/var/lib/unbound/root.hints"

    # Trust glue only if it is within the server's authority
    harden-glue: yes

    # Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
    harden-dnssec-stripped: yes

    # Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
    # see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
    use-caps-for-id: no

    # Reduce EDNS reassembly buffer size.
    # IP fragmentation is unreliable on the Internet today, and can cause
    # transmission failures when large DNS messages are sent via UDP. Even
    # when fragmentation does work, it may not be secure; it is theoretically
    # possible to spoof parts of a fragmented DNS message, without easy
    # detection at the receiving end. Recently, there was an excellent study
    # >>> Defragmenting DNS - Determining the optimal maximum UDP response size for DNS <<<
    # by Axel Koolhaas, and Tjeerd Slokker (https://indico.dns-oarc.net/event/36/contributions/776/)
    # in collaboration with NLnet Labs explored DNS using real world data from the
    # the RIPE Atlas probes and the researchers suggested different values for
    # IPv4 and IPv6 and in different scenarios. They advise that servers should
    # be configured to limit DNS messages sent over UDP to a size that will not
    # trigger fragmentation on typical network links. DNS servers can switch
    # from UDP to TCP when a DNS response is too big to fit in this limited
    # buffer size. This value has also been suggested in DNS Flag Day 2020.
    edns-buffer-size: 1232

    # Perform prefetching of close to expired message cache entries
    # This only applies to domains that have been frequently queried
    prefetch: 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

    # Ensure kernel buffer is large enough to not lose messages in traffic spikes
    so-rcvbuf: 1m

    # 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

3. Create a config file at /etc/dnsmasq.d/99-edns.conf and copy/paste in the below:

edns-packet-max=1232

4. Start the recursive server and test it:

sudo service unbound restart
dig pi-hole.net @127.0.0.1 -p 5335

5. Optional: If using DNSSEC, test validation:

dig fail01.dnssec.works @127.0.0.1 -p 5335
dig dnssec.works @127.0.0.1 -p 5335

The first command should give a status report of SERVFAIL and no IP address. The second should give NOERROR plus an IP address.

Finally, go on the Pi-Hole web admin UI go to Settings -> DNS and under Upstream DNS servers uncheck everything and check Custom DNS (IPv4), type in 127.0.0.1#5335 and click the Save button.

The docs continue with instructions for disabling resolvconf.conf but I didn’t find it necessary, the service was not present on this install of Debian 12 Bookwork on the Sweet Potato. After this Pi-Hole is good to go, so I added it as secondary DNS in my router’s DHCP settings. It’s been about a month and a half, and everything continues to work as intended, the Sweet Potato hasn’t had a single hiccup that I have noticed.

If you’d like a low wattage Raspberry Pi alternative, then in my opinion Libre’s Sweet Potato SBC is a worthy choice for $30 on Amazon.