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).

A few other interesting links

• A few other solutions for a DHCP server:
  • DNSmasq installation (DHCP only)
  • Dragon: DNSmasq installation (DHCP + DNS)
  • Instructables: installation for DNSmasq (DHCP & DNS)
  • ISC-DHCP server on Debian
  • ISC-DHCP server on Ubuntu
  • Tools designed to work with ISC-DHCP
  • Fast instructions for installing DHCP, DNS, and NTP on Raspberry Pi
• Some data about installation of another DNS server:
  • BIND local-mode DNS server on Debian 9
  • BIND authoritative DNS server on Ubuntu
  • BIND “caching” or “forward-only” DNS server on Ubuntu
• DNS filters:
  • THE guide on cleaning DNS from public domain lists
• Setup of a LaSynology NAS or router:
  • Configuration of a DNS server on DSM
• Server comparisons:
  • BIND vs. dnsmasq vs PowerDNS vs Unbound
    
    
    
    

Version 1.7 of Cygnus is now available that supports Windows 7 (but drops support for Windows 95, 98 & Me).

As if this was not enough, this version also has the capability to configure IPv6 (if you are already attracted by this solution) or supports multiple installations.

Cygnus v1.7-1.1 new release.

It’s worth noticing it if you are using Opera. I had a difficult-to-solve issue recently.

While playing with the idea of starting to use IPv6 on my main PC, I tested the waters by validating this option in the network configuration of my Windows XP. Unfortunately, Opera is already fully ready for IPv6 but my router box is not. So, the first effect it had is that Opera decided to enforce the use of IPv6 for all web sites that mentioned IPv6 capacity in their DNS (not many of them, but Google and Free.fr my ISP are already in the list). The immediate effect was that Opera tried to connect to them in IPv6 but failed (because the rest of my home configuration is not 100% IPv6). For 99% of all web sites, there was no difference…

It took me several days (and some Googling – using Safari and Chrome) to understand that this is a known issue and to remove the (still) useless IPv6 Windows configuration.

I’ll have to upgrade my router and try again.

Google decided to celebrate with an anti-latin graphic to great their visitors.

This is why, while the Internet Engineering Task Force (IETF) was preparing a night without IPv4 to reach the largest possible public, Google launched a version of its search engine reserved to IPv6: ipv6.google.com (If you are like almost everybody, you will not see anything at the end of the link).

Now, we all have to switch as soon as possible.

It means that IPv6 will become a reality in most regions of the world, even if a lot more is to be done to make it overwhelmingly present.