Raspberry Pi as a local DNS/DHCP server

For a local network supporting a small company or an Internet-active family, it is always possible to rely totally on an Internet Service Provider (ISP) which will provide basic network services straight from the Internet box/router (fibre or ADSL). But, if – like me – you want to have more flexibility, you’d prefer to setup your own services.

I noticed the market emergence of nano-computers like Android boxes or Raspberry Pi which allow to easily setup services that may have been prohibitely expensive in the past.

So, I decided to pruchase a Raspberry Pi 3 B+ (a rather cheap network little box, with low power consumption, able to stay online permanently, and easily configurable). I wanted to start by deploying the minimal network services to give me maximum agency.

Minimum feature set included:

A DHCP server (to assign IP addresses on the local network with ability to fix some of them in a static list, for easier management)
A DNS server providing
- DNS request cache (to speed up the overall Internet access of my Internet users)
- Delivery of local network names
- Capacity to allow future DNS filtering (I don’t care much about adult-content filtering, but I’d like to stop some of the phishers, even if these two activities are technically identical)

In the future, some more services may come handy (nothing of this has been studied here):

An NTP server (for time)
A WINS Windows names server

Comparison

As a matter of fact, I noticed that two serveurs seemed able to simultanesouly provide DHCP and DNS: Unbound and dsnmasq.

Unbound highlights:

Lightweight server
DNSSEC support
rather security-oriented
No DNS authoritative server (but able to handle a local domain)

dnsmasq highlights:

Lightweight server
DNSSEC support
DHCP and DNS are integrated in the same server
May use /etc/hosts to feed DNS
No DNS recursive server (only forward to an authoritative/recursive like 8.8.8.8 or 9.9.9.9 or your ISP DNS server)
No DNS authoritative server (but able to handle a local domain)

I chose dnsmasq, mainly because of the DNS + DHCP integration.

Some surprising discoveries

Première information vite découverte : les serveurs NAS Synology sont tout à fait incompatibles avec le filtrage de DNS de CleanBrowsing. Celui-ci compte synology.me (service nécessaire pour le DDNS de Synology) dans les domaines à risque. De nombreux services du NAS cessent immédiatement de fonctionner.

Je n’ai pas vérifié mais il est probable que de nombreux autres services DDNS (Dynamic DNS) soient black-listés pour les mêmes raisons : devant le nombre de petits serveurs Synology (ou autres) mal configurés, ces DDNS renvoient sans doute vers une forte proportion de domaines qui ont été pris en otage par les hackers.

Il faut donc pouvoir gérer cela plus finement si vous avez vous-même votre propre NAS Synology (et sans doute d’autres marques).

Observations

After a few months of dnsmasq use on Rapsberry Pi, it is time to comment and share my experience.

First, this worked really well. Even if I had one case of locked down DHCP server (no warning, no error, but killed). I tried finding why, but it was far easier to reboot the server box (On-Off switch) to restore the service. Of course, a few minutes of digging into logs did bring me some worried looks from another network user…

The DNS filter setup to remove access to some risky domains work perfectly well. But, I have to admit that nothing seems to have triggered that (except my tests). Since this is not the only security barrier on my network, this may be OK. For the record, here is the filter creation script I use:

#!/bin/sh
#Dated 2020-11-10 1.0 Addition of --quiet to wget (to reduce clutter to /var/mail/pi)
#                     *** STABLE RELEASE ***

cd /var/lib/work

#Get anti-phishing filter lists from Internet
wget -q -O ./isc-low.txt 'https://isc.sans.edu/feeds/suspiciousdomains_Low.txt'
wget -q -O ./isc-med.txt 'https://isc.sans.edu/feeds/suspiciousdomains_Medium.txt'
wget -q -O ./isc-hig.txt 'https://isc.sans.edu/feeds/suspiciousdomains_High.txt'
wget -q -O ./yoyo.dnsmasq.txt 'https://pgl.yoyo.org/adservers/serverlist.php?hostformat=dnsmasq&hostformat=nohtml&showintro=0&mimetype=plaintext'
#Remodel the lists into DNSmasq filters
catcherIP='192.168.1.250'
inputfile="./isc-med.txt"
tmpfile="/tmp/.adlist.$$"
tmpconffile="/tmp/.dnsmasq.conf.$$"
configfile="/etc/dnsmasq.filter.conf"
configheader="/etc/dnsmasq.filter.header"

#Start with putting our own header
    [ -f "$configheader" ] && cat $configheader >> $tmpconffile
#check if TmpFile could be init'd with header
if [ ! -s $tmpconffile ]
then
    echo "temp fil '$tmpconffile' could not be found or is empty; quitting"
    exit
fi
#Remove list headers
cat $inputfile | grep -v "^#" | grep -v "^Site$" > $tmpfile
#Buid list to DNSmasq format, and add it to the file
sed "s/(.*)/address=\/\1\/${catcherIP}/" $tmpfile >> $tmpconffile
#Move the final list to destination
sudo cp $tmpconffile $configfile

One of the advantages of this server is its speed. I may have been slightly worried (or attentive) before knowing the Raspberry Pi, but there was no reason. Maybe because of the low workload (despite an HTTP server, some distant connexions, and a few local scripts) and because of the good power developed by the CPU, everything is fine and dandy even when a dozen clients are pounding the DNS server (the iPhones are quite insistant in using the netowrk on a continuous basis)).

dnsmasq is perfectly able t manageIPv6 DHCP, and correspondingIPv6 DNS. Documentation about this is terse (if not simply lacking), but it works well and I learned quite a few things. The Raspberry Pi was so reliable that it was IPv6 proxy during some of my tests without any perceptible impact. (I was rightfully impressed).

After initially using dynamic address allocation, I moved the DHCP server into a nearly exclusively static configuration (my own choice in order to have easier local client identification). No big deal, neither in IPv4 nor in IPv6.

Conclusion: Totally positive.

In the future, I may be tempted to deploy more powerful servers for DHCP and DNS for a wider support (maybe or maybe not) and to try a network spy like SNORT or SURICATA. But this is a completely different story. And, in this case, I may be tempted to go to a really powerful solution (I have an Avenger96 under initial trial, but its software support seems to be a real mess).