Pour ma part, j’ai noté que l’apparition sur le marché de nano-ordinateurs comme les box Android ou les Raspberry Pi permet d’envisager de mettre en oeuvre des services qui semblaient horriblement chers et difficiles à déployer auparavant.

J’ai donc décidé d’acheter un Raspberry Pi 3 B+ qui offre une solution qui ne coûte pas cher, qui ne consomme pas beaucoup d’énergie, qui peut rester branchée en permanence, et qui est programmable intégralement. Je voulais déployer les services de base d’un réseau tout en me donnant la maîtrise la plus complète possible.

Le minimum à assurer :

• Un serveur DHCP (pour attribuer les adresses IP en local sur le réseau avec la possibilité de fixer des adresses statiques, pour une meilleure gestion)
• Un serveur DNS qui assure à la fois
  • le cache des recherches DNS (pour accélérer l’ensemble des opérations Internet des utilisateurs)
  • la fourniture de noms pour le réseau local
  • des réserves pour permettre le futur filtrage des recherches DNS (je ne m’intéresse guère au filtrage des contenus adultes, mais je me préoccupe sensiblement de bloquer les phishers, même si les deux problèmes sont techniquement identiques)

Dans le futur, il faudra aussi assurer des services complémentaires (pas étudiés ici) comme :

• Serveur de base temps NTP
• Serveur de noms WINS pour Windows

Comparaison

De fait, j’ai noté que deux serveurs semblaient aptes à gérer simultanément le DHCP et le DNS : Unbound et dsnmasq.

Unbound:

• Serveur léger
• Support DNSSEC
• plutôt tourné vers la sécurité
• Pas de serveur DNS authoritative (mais capable de gérer un domaine local)

dnsmasq:

• Serveur léger
• Support DNSSEC
• DHCP et DNS sont integrés dans un seul serveur
• Capable d’exploiter /etc/hosts pour alimenter le serveur DNS
• Pas de serveur récursif DNS (seulement forward vers un serveur récursif ou authoritative comme 8.8.8.8 ou 9.9.9.9 ou le serveur DNS de votre propre FAI)
• Pas de serveur DNS authoritative (mais capable de gérer un domaine local)

Cela m’a mené à exploiter dnsmasq, principalement à cause de la possibilité de gérer simultanément DNS et DHCP.

Découvertes intéressantes

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

Après quelques mois d’utilisation de dnsmasq sur Rapsberry Pi, il est temps de faire quelques commentaires pour partager cette expérience.

Tout d’abord, cela a très bien fonctionné. J’ai bien eu un cas où le serveur DHCP semble s’être arrêté sans autre forme de procès. J’ai essayé de comprendre la cause mais il s’est révélé plus simple de rebooter le serveur (bouton On-Off) pour retrouver le service. Evidemment, quelques dizaines de minutes de recherche m’auront valu quelques regards inquiets de l’autre utilisatrice du réseau…

Les filtres DNS mis en place pour limiter l’accès à des domaines particulièrement dangereux fonctionnent bien, mais il est exact qu’il ne semble pas y avoir eu de déclenchement intempestif (ce n’est pas la seule barrière que j’utilise contre les sites malveillants). Le script de création du filtre est ci-dessous :

#!/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

Un des avantages de ce serveur est sa rapidité. Je pouvais m’en inquiéter avant de connaître le Raspberry Pi, mais étant donné la faible charge de travail sur ce serveur (malgré un petit serveur HTTP, des connexions à distance et quelques scripts locaux) et la bonne puissance de la CPU, tout se passe très bien même devant la dizaine de clients qui font appel au serveur DNS en mode à peu près continu (les iPhones sont particulièrement exigeants).

dnsmasq est parfaitement capable de gérer le DHCP IPv6, et le DNS IPv6 correspondant. La documentation à ce sujet est faible (c’est le moins qu’on puisse en dire), mais ça fonctionne bien et j’ai pu assurer un fonctionnement fiable dans ce domaine également (temporairement, le Raspberry Pi m’a même servi de proxy pour tout le trafic IPv6 sans faiblir ou être remarqué ; là, j’ai été surpris par sa puissance).

Après une installation initiale qui fonctionnait avec une allocation dynamique des adresses IP, j’ai passé le serveur DHCP en configuration presqu’exclusivement statique (c’est un choix personnel qui me permet de reconnaître plus facilement le contenu de mon réseau). Là aussi aucune difficulté, aussi bien en IPv4 qu’en IPv6.

Conclusion : totalement positive.

Dans le futur, je peux être tenté de déployer des serveurs DHCP et DNS plus puissants (peut-être ou peut-être pas) et surtout un espion de réseau genre SNORT ou SURICATA. Mais c’est une autre histoire. Et peut-être que dans ce dernier cas, je serai tenté par un calculateur avec beaucoup plus de puissance de calcul (j’ai un Avenger96 à l’essai, mais il ne me semble pas idéalement supporté en matière de soft).

Quelques autres liens intéressants

• D’autres solutions pour un serveur DHCP :
  • Installation de DNSmasq (DHCP seul)
  • Dragon : installation de DNSmasq (DHCP et DNS)
  • Instructables : installation de DNSmasq (DHCP et DNS)
  • Serveur ISC-DHCP sur Debian
  • Serveur ISC-DHCP sur Ubuntu
  • Outils prévus pour fonctionner avec ISC-DHCP
  • Guide rapide pour l’installation de serveurs DHCP, DNS et NTP sur Raspberry Pi
• Des informations sur l’installation d’un serveur DNS :
  • Serveur DNS BIND en local sur Debian 9
  • Serveur DNS BIND authoritative sur Ubuntu
  • Serveur DNS BIND comme « caching » ou « forward-only » sur Ubuntu
• Filtres DNS :
  • LE guide sur le nettoyage du DNS à partir de listes du domaine public
• La mise en oeuvre sur un NAS ou un routeur Synology :
  • Configuration de serveur DNS sur DSM
• Comparaisons de serveurs :
  • BIND vs. dnsmasq vs PowerDNS vs Unbound

Je possède un nom de domaine (Roumazeilles.net) mais depuis ma migration vers une FreeBox, il semble plus comfortable d’émettre mes mails via le serveur SMTP de Free. Sauf que, pour se protéger du SPAM, la plupart des opérateurs de courrier électronique vérifient l’origine du mail pour s’assurer qu’il arrive bien d’une origine autorisée (ce qui permet de distinguer beaucoup de SPAM et de mails de phishing).

SPF record – Tentative #1

L’idée de base (la plus évidente) consistait à créer un SPF record de la forme suivante :

…qui ressemble à la valeur par défaut recommandée par OVH (mon hébergeur et le gestionnaire de mon DNS).

Mais cela pose à vrai problème : Free n’a rien déclaré ni pour free.fr, ni pour smtp.free.fr, ce qui mène à une erreur d’interprétation du record SPF par la plupart des opérateurs de courrier électronique. Un SPF record invalide garantit presque que le mail ne sera pas diffusé correctement.

SPF record – Tentative #2

Comme les serveurs de mail de Free (et ils sont nombreux) sont de la forme :

Il est possible de passer plutôt par une déclaration d’adresse IP. C’est moins élégant, mais on peut faire.

De fait, la déclaration s’allonge singulièrement. Au point que le record devient invalide parce que comportant trop d’entrées. Il faut donc sérieusement optimiser.

SPF record final

La solution a finalement été de créer un SPF record taillé sur mesure.

Il donne une tranche d’adresses IPv4 pour les serveurs STMP de Free, et une autre tranche de 16 adresses IPv6 pour les mêmes serveurs. Compact et efficace.

Conclusion

Le principal inconvénient (mais il n’y a guère de contournement tant que Free n’aura pas fait son travail pour décrire correctement son propre SPF record dans son DNS) est que les adresses de Free sont « en dur ». Au moindre changement chez eux, je serai pris par surprise et je risque de perdre quelques mails.

Au delà, je recommande l’excellent site de test de courriers électroniques mail-tester.com qui permet de vérifier quasi-instantanément (c’est plaisant pour des modifs de DNS) les essais de configuration et qui donne un excellent rapport de test, très lisible.

Sources d’information

Merci à ces sites/auteurs qui m’ont aidé à m’y retrouver :

• Nicolass sur ForumNews
• Julien Falconnet

Et merci à Vincent Rubiolo pour avoir détecté l’erreur de copier-coller dans la version originale de l’article.

J’ai une connexion Internet Fibre chez Numéricable qui utilise obligatoirement une adresse IP dynamique (pas d’adresse IP fixe chez Numéricable qui sont un peu gentiment arriérés). Ce n’est pas bien grave sauf que j’ai un serveur RAID provenant de chez Synology (une DiskStation DS413j à 4 disques en mode redondant RAID-5) qui me procure quelques services que je souhaite partager avec Internet (quand je suis en déplacement avec un mobile ou un PC portable, j’aimerais accéder à mon serveur FTP, à mon serveur de mail).

J’ai donc décidé de m’organiser pour permettre de retrouver facilement le Synology DiskStation depuis un sous-domaine (par exemple mail.roumazeilles.net).

La solution que j’ai adoptée :

Adresse IP dynamique :

Comme mon adresse IP est dynamique, pas moyen de faire grand chose avant d’avoir résolu ce point. J’ai opté pour le service DDNS de Synology. Comme j’utilise DSM 5.0 (la version la plus récente du soft de Synology), il est accessible dans le panneau de configuration au menu « Accès extérieur ». Il suffit d’ajouter un DDNS en choisissant Synology comme prestataire et j’ai enregistré un nom qui me convient (disons ds). A partir de là, malgré les changements d’adresse IP, ma DiskStation reste accessible à ds.synology.me.

Sous-domaine du DNS :

Il faut ensuite faire pointer mail.roumazeilles.net vers ds.synology.me. Le sujet est un peu plus compliqué parce que j’ai déjà réservé le nom de domaine roumazeilles.net chez Gandi et qu’il pointe vers un serveur mutualisé chez OVH. C’est le serveur d’hébergement (loué chez OVH) qui comporte toute l’information relative à roumazeilles.net. J’ai donc du aller sur mon serveur et dans sa configuration DNS modifer (dans votre cas, il s’agira peut-être d’ajouter) un enregistrement de type CNAME.

mail 10800 IN CNAME ds.synology.me. (N’oubliez pas le point final dans votre entrée CNAME, ou elle ne fonctionnera pas !)
Comme j’ai de la chance, mon panneau de contrôle OVH me permet de ne pas me rater avec la syntaxe exacte, mais l’affaire est identique : je lui dit que le sous-domaine mail est décrit pas un enregistrement CNAME qui pointe directement sur ds.synology.me (un peu abscons mais pas très méchant).

Ensuite, il reste à attendre que l’information DNS « se propage » (quelques minutes à quelques heures, parfois 24-48h). Et un petit contrôle se fait avec ping mail.roumazeilles.net qui doit répondre correctement avec mon adresse IP chez Numéricable.

Il y a peu de choses à faire pour améliorer sensiblement la vitesse de son Internet. Évidemment, vous pouvez toujours changer de Fournisseur d’Accès, mais c’est compliqué. Par contre, il est relativement facile d’avoir une vitesse de connexion limitée par le temps de réponse du serveur DNS de votre fournisseur. Ce serveur sert à convertir le nom de domaine (par exemple, www.roumazeilles.net) dans son adresse IP numérique (la seule dont a vraiment besoin le navigateur).

Mais tous les serveurs DNS ne sont pas nés égaux et si ceux qui sont mis à votre disposition par votre Fournisseur d’Accès Internet (FAI) sont avantagés (ils sont les plus proches de votre ordinateur), ils ne sont pas forcément les plus rapides. NameBench permet de déterminer facilement et automatiquement quel est le serveur DNS le plus efficace (et de comparer avec votre configuration actuelle).

Dans mon cas personnel, je viens de gagner 50% (pas moins !) alors que je pensais avoir une configuration pas mauvaise du tout. En fait, les serveurs de Neuf Telecom sont plus rapides pour moi que les serveurs de Free…

Ça fonctionne aussi bien sur Windows que sur MacOS ou sur GNU/Linux.

Tant que j’y suis, pour ceux qui se poseraient la question, Oui ! j’ai bien inclus le nouveau DNS de Google dans la comparaison des options et ça ne m’a pas beaucoup influencé : Google DNS est plutôt plus lent que la plupart des autres options disponibles gratuitement et librement.

Ces serveurs changent de temps à autre sans forcément prévenir. Mais dans les cas qui m’intéressaient, je ne m’était vraiment pas préoccupé du problème pour des ordinateurs qui n’avaient pas eu à être reconfigurés depuis des années. Conséquence : d’abord, des ralentissements un peu curieux ; puis la panne, apparemment plus d’Internet.

Au moment de corriger le tir, j’ai eu du mal à trouver les adresses des serveurs DNS des grands fournisseurs d’accés francophones. Mais voilà une source mise à jour régulièrement : Serveurs DNS des principaux FAI.

A garder dans un coin, n’est-ce pas ?