Serveur DNS self-hosted
Sommaire :
- Introduction
- Pourquoi ?
- Mise en place
- Les joies et obstacle de l’IPv6
- Tests et finalité
Introduction :
Dans la suite de ce blog, je vais présenter la mise en place de mon serveur DNS.
Je saute la mise en place du DHCP car il n’y avait rien de spécial si ce n’est à mettre plusieurs beaux statiques
Pour ce post là, j’ai utilisé l’outil StackEdit qui permet de créer des documents Markdown et d’exporter le résultat en HTML.
Mais avant de partir tête baissée dans de la documentation technique (spoiler : je vais devoir en aborder, vous êtes prévenu ^^) et de la mise en place + qualification d’un service, y a-t-il un réel besoin à avoir un serveur DNS chez soi ? Car dans le cas d’un utilisateur lambda ou bien dans mon infrastructure personnel, créer un annuaire (=> DNS) n’est pas très pertinent : je n’ai que quelques équipements et personnellement, je m’y connecte via leur adresse IP en dure plutôt que par leur hostname/nom de domaine.
Donc on peut me rétorquer que je fais pour faire sans but précis.
Et c’est à ce moment là qu’avoir son serveur DNS self-hosted prend tout son intérêt : on en dévie son usage principal !
Mon principal besoin est de contourner les restrictions et censures abusives venant des FAI (Fournisseur d’Accès Internet) et gouvernementales. Oui cela peut paraître étonnant mais lorsqu’on me coupe l’accès à des sites d’informations ou de partages de fichiers (qui sont tout à fait légaux hein, c’est des images linux 😉) cela me dérange qu’on me dicte ce que j’ai le droit de consulter ou non.
L’accès à la connaissance est un droit humain fondamental.
Assemblée générale de l’ONU le 16 décembre 1966
Changer de serveur DNS permet de ne plus être à la merci de notre fournisseur et d’être indépendant. Il reste quel DNS faut-il choisir … Il en existe tellement qu’on peut facilement se perdre.
Mais en voulant choisir mon bon candidat, une 2ème problématique est apparu : comment rendre tous ces échanges/requêtes privés ? Car par défaut, le protocole DNS n’a aucun chiffrement des données, ce qui signifie que n’importe qui donc savoir sur quel site je vais, et trafiquer les échanges (du Man In The Middle). Il faudra donc que tous ces échanges soient chiffrés et sécurisés.
Et la dernière problématique est de répéter ce même processus pour l’IPv6 :
Etant un IT/SysAdmin qui se respecte, mon infra. est dual-stack IPv4/IPv6 donc il faudra que le DNS fonctionne aussi en IPv6.
Pour résumer :
- Trouver le bon DNS et configurer le serveur DNS local
- Etablir une connexion sécurisé
- Le répéter pour l’IPv6
Allez c’est parti ! 🛣
1. Choix du serveur DNS
Comme dit précédemment, tous les serveurs DNS se valent clairement pas (pour cela que je ne veux plus utiliser celui de mon FAI). Après de longues recherche et de plusieurs témoignages et tests, j’en conclus que Mullvad est celui qui correspond à ma demande :
- Il est suédois 🇸🇪 (donc européen)
- N’applique aucune censure
- N’enregistre aucune log/donnée
Il propose aussi différent certains via des filtres qui bloquent certains contenu (je le précise même si ça n’était pas mon besoin principale)
Pour plus d’information : Mullvad DNS
En plus, il explique comment chiffrer le trafic DNS via DoT ou DoH (bon je savais déjà mais c’est pour le storytelling 🙃 )
On peut donc commencer l’étape 2 !
2.1 Chiffrement DNS
Chiffrer ses requêtes DNS est quelque chose qui n’est pas encore répandu dans l’informatique : voir des pages web en HTTPS est maintenant quelque chose que l’on voit partout. A l’opposé, chiffrer son trafic DNS de la même façon que l’HTTPS (c’est le DoT : DNS over TLS) ou bien envoyer son trafic DNS directement dans de l’HTTPS (le DoH : DNS over HTTPS) est tout récent : ces 2 méthodes ne sont apparus qu’en 2018 ! Quand on compare à l’HTTPS qui a été créé en 1994, cela fait un écart de 24 ans !
Et il ne faudrait pas négliger cette partie là, car s’il l’on fait des requêtes à des serveurs situés à “l’autre bout de monde” et que n’importe qui peut intercepter, voir et même modifier son contenu, c’est une faille de sécurité critique.
Heureusement, Mullvad supporte cette fonctionnalité sur leurs serveurs, il ne me reste plus qu’à le configurer sur mon serveur DNS local.
2.2 Configuration
Pour mieux comprendre, j’ai fais un petit schéma succinct de mon réseau local et du fonctionnement du serveur DNS :
On va commencer par indiquer dans notre serveur DHCP que le serveur DNS est à l’adresse 192.168.1.254, qui est mon routeur OPN, qui fait office de serveur DNS pour mes appareils locaux :
Ici rien de spécial.
Il faut maintenant forward (déléguer les recherches à un autre DNS) vers les serveurs DNS de Mullvad tout en pensant bien à mettre le chiffrement :
OPNSense à déjà tout prévu (c’est pour ça que j’utilise leur outil) :
On indique l’adresse IP du serveur destinataire (voir schéma), le numéro du port (voir documentions Mullvad DNS) et renseigner le CN (Common Name) pour vérifier qu’il est signé par une autorité reconnue et qu’il correspond bien à dns.mullvad.net pour éviter toute usurpation d’identité (le même principe que lorsqu’on se connecte à un site web).
Et c’est bon !
Ou presque … !
Car il faut faire la même chose en IPv6 ! et ça sera plus complexe.
3. Répéter le processus en IPv6
On pourrait ce dire :
“bah on refait la même chose. C’est juste que l’on remplace 194.242.2.2 par 2a07:e340::2 ?”
Et bah malheureusement non.
En IPv6, les appareils/terminaux récupèrent leurs adresses non pas par un serveur DHCP mais par SLAAC (Stateless Address Auto Configuration) : grâce au RA et RS (Router Advertisement et Router Solicitation) :
Notre appareil va émettre des RS pour “découvrir” un routeur. Notre box internet va le répondre via RA en lui donnant le préfixe (l’adresse réseau et le masque qui est en /64) et va se créer lui-même une adresse IPv6. La box internet va aussi diffuser d’autres informations comme par exemple le serveur DNS ! Ca n’est pas obligatoire mais c’est bien le cas pour moi.
Et là c’est beaucoup plus complexe car cela voudrait dire qu’il faudrait intercepter les échanges et modifier leurs contenus. Ou bien refaire le même processus soi-même !
On commence donc par désactiver le SLAAC sur notre box internet :
Le routeur OPNSense doit maitenant prendre le relais :
OPNSense propose différent modes de RA (Disable, Router Only, Unmanaged, Managed, Assisted, Stateless). Voici un résumé qui comparé les diffénrents modes de RA fait par ChatGPT :
Dans mon cas j’ai choisis Stateless : les appareils récupère leurs adresses IPv6 via SLAAC donc c’est le FAI qui gère cela et les options (DNS, etc…) seront données via un serveur DHCP.
Il faut donc créer un serveur DHCPv6 :
Même principe que si c’était un serveur DHCPv4 à la différence qu’il ne faut pas renseigner de plage d’adresse car c’est le SLAAC qui gère cela.
Nos appareils vont interroger notre serveur DNS local. Il ne reste plus qu’à forwarder vers les serveurs Mullvad : on refait la même chose que précédemment donc rien de compliquer :
4.Vérification et tests
Maintenant qu’on a tout mis cela en place, il ne reste plus qu’à vérifier que tout fonctionne ça serait dommage de configurer tout ça et que cela ne fonctionne pas :
Mullvad propose une page de vérification de notre connexion. Dans notre cas nous nous intéresserons qu’à la partie DNS (on ignore donc les 2 autres messages).
On constate bien que le test a réussi, ce qui signifie que notre trafic DNS est bien envoyé à Mullvad (l’adresse IP affiché dans la vidéo est différente que celle qui a été renseigné car il y a du load-balancing et il renvoie vers le serveur DNS le plus proche pour avoir une latence plus faible).
5. Conclusion
Personnellement, je pensais que cela allait être très facile mais cela n’a pas été le cas avec cette histoire d’IPv6… Cela m’a “forcé” à bien comprendre le fonctionnement de l’IPv6, chose que l’on ne travaille pas en entreprise et trop succinctement à l’université.
Et il y a un réel intérêt derrière cette “aventure” : plus de confidentialité !
Toute personne qui se connectera à mon réseau en profitera sans même s’en rendre compte.
Je recommande à toute personne qui se soucie de sa vie privée à faire ceci et à minima et le faire sur son appareil personnel (ne demande aucune compétence technique) : Mullvad DNS - configuration
Self-hosted DNS server
Table of contents
- Introduction
- Why?
- Setting things up
- The joys and pitfalls of IPv6
- Testing and wrap-up
Introduction
In this post I describe how I set up my DNS server.
I’m skipping the DHCP part because there was nothing special—just a few tidy static leases.
For this post I used StackEdit, which lets you write Markdown documents and export them to HTML.
Before diving head-first into technical documentation (spoiler: I’ll still need to cover some—you’ve been warned ^^) and into deploying and validating a service, is there a real need to run a DNS server at home? For a typical user—or in my personal setup—building a directory (=> DNS) is not very compelling: I only have a handful of devices and I usually connect using raw IP addresses rather than hostnames or domain names.
So you could say I’m doing it for the sake of it, without a clear goal.
That’s exactly when running your own DNS server gets interesting: you bend it away from its “main” purpose!
My main need is to get around abusive restrictions and censorship from ISPs (Internet service providers) and governments. It may sound surprising, but when I lose access to news sites or file-sharing pages (perfectly legal ones—Linux ISO images 😉), I resent being told what I’m allowed to read or not.
Access to knowledge is a fundamental human right.
UN General Assembly, 16 December 1966
Changing DNS servers means you’re no longer at the mercy of your provider—you gain independence. But which DNS should you pick? There are so many that it’s easy to get lost.
While picking the right candidate, a second issue appeared: how do I keep all those exchanges and queries private? By default DNS has no encryption, which means anyone can see which sites you visit and tamper with the traffic (man-in-the-middle). So those exchanges need to be encrypted and secured.
The last issue is repeating the same process for IPv6:
As a self-respecting IT/sysadmin, my infra is dual-stack IPv4/IPv6, so DNS has to work over IPv6 too.
In short:
- Pick the right DNS and configure the local DNS server
- Set up a secure connection
- Repeat it for IPv6
Off we go! 🛣
1. Choosing the DNS server
As I said earlier, DNS servers are not all equal (which is why I no longer want to use my ISP’s). After a lot of reading, feedback, and tests, Mullvad is the one that fits my needs:
- It’s Swedish 🇸🇪 (i.e. European)
- It applies no censorship
- It keeps no logs or personal data
It also offers optional filters that block certain content (I mention it even though that wasn’t my main requirement)
More info: Mullvad DNS
They also explain how to encrypt DNS traffic with DoT or DoH (I already knew, but it helps the story 🙃 )
So we can move on to step 2!
2.1 DNS encryption
Encrypting DNS queries is still uncommon in IT: HTTPS websites are everywhere. By contrast, encrypting DNS the same way as HTTPS (DoT: DNS over TLS) or tunneling DNS inside HTTPS (DoH: DNS over HTTPS) is recent—both appeared in 2018! Compared with HTTPS from 1994, that’s a 24-year gap!
You shouldn’t neglect this: if you query servers on the other side of the world and anyone can intercept, read, or even modify the answers, that’s a critical security flaw.
Fortunately Mullvad supports this on their servers; I only had to configure it on my local DNS server.
2.2 Configuration
To make things clearer, I drew a small diagram of my LAN and how the DNS server fits in:
First we tell our DHCP server that DNS is at 192.168.1.254—my OPN router, which acts as the DNS server for my local devices:
Nothing unusual here.
We now need to forward (delegate lookups to another DNS) to Mullvad’s servers while enabling encryption:
OPNSense already has everything ready (that’s why I use it):
You enter the destination server IP (see diagram), the port number (see Mullvad DNS docs), and the CN (Common Name) to verify it’s signed by a trusted authority and matches dns.mullvad.net to prevent impersonation (same idea as visiting a website).
And we’re done!
Almost…!
Because we have to do the same in IPv6! And that’s trickier.
3. Repeating the process for IPv6
You might think:
“Well, we just do the same thing. We only replace 194.242.2.2 with 2a07:e340::2, right?”
Unfortunately, no.
In IPv6, devices usually don’t get addresses from a DHCP server but through SLAAC (Stateless Address Autoconfiguration), using RA and RS (Router Advertisement and Router Solicitation):
The device sends RS messages to “discover” a router. The ISP box answers with RA, handing it the prefix (network address with a /64 mask) so it can build its own IPv6 address. The box also advertises other options such as the DNS server! That’s optional, but it’s how my setup works.
That makes things much harder: you’d have to intercept traffic and rewrite it—or redo the whole process yourself!
So first we disable SLAAC on the ISP box:
The OPNsense router must take over:
OPNsense exposes several RA modes (Disable, Router Only, Unmanaged, Managed, Assisted, Stateless). Here’s a summary comparing the different RA modes (courtesy of ChatGPT):
I picked Stateless: devices still get IPv6 addresses via SLAAC (the ISP handles that) while options such as DNS are provided through a DHCP server.
So we create a DHCPv6 server:
Same idea as DHCPv4, except you don’t define an address range because SLAAC handles that.
Our devices will query the local DNS server. We still need to forward to Mullvad: same steps as before, so nothing complicated:
4. Verification and testing
Now that everything is in place, we only need to verify it works (it would be a shame to configure all this for nothing):
Mullvad offers a page to check your connection. Here we only care about the DNS section (we ignore the other two messages).
The test succeeds, which means our DNS traffic really goes to Mullvad (the IP shown in the video differs from the one I configured because of load balancing—the resolver picks the closest DNS server for lower latency).
5. Conclusion
Personally I thought this would be easy, but IPv6 proved otherwise… It “forced” me to understand how IPv6 really works—something you rarely touch in industry and only skim at university.
There’s real value in this “adventure”: more privacy!
Anyone who joins my network benefits without even noticing.
I recommend that anyone who cares about privacy do at least this—and at minimum on a personal device (no technical skills required): Mullvad DNS — configuration