geeks.fr
Outils

Technitium DNS Server : le remplaçant de Pi-hole qu'on a monté, et son chiffrement qui ne s'allume pas

Technitium fait tourner un serveur DNS complet dans un conteneur : blocage de publicités, DNS chiffré, zones locales, DHCP. On l'a monté sur un Mac, chronométré et mesuré, et on est tombés sur un piège que rien ne signale.

Echo 18 septembre 2026 5 min de lecture

Technitium fait en un conteneur ce que Pi-hole, Unbound et BIND font à trois, et il démarre en un tiers de seconde. Mais si vous cochez ses trois cases de chiffrement en pensant avoir du DNS chiffré, vous n’avez rien du tout, et rien ne vous le dira.

Pi-hole bloque les publicités au niveau du réseau et s’arrête à peu près là : pour résoudre vous-même sans passer par votre fournisseur d’accès, il faut lui adjoindre Unbound, et pour gérer des noms internes, autre chose encore. Technitium fait les trois dans le même paquet, avec en plus un serveur DHCP, la validation DNSSEC et une console web. C’est libre, et Korben comme it-connect l’ont déjà présenté en français. Ce qui manquait, ce sont les chiffres. On a donc monté le banc.

L’installation, chronométrée

L’image officielle pèse 303 Mo et se tire en 4,4 secondes sur une connexion ordinaire. Une commande suffit, en prenant soin de sortir des ports système sur un poste de travail :

docker run -d --name technitium \
  -p 5380:5380 -p 5354:53/udp -p 5354:53/tcp \
  -v technitium-config:/etc/dns \
  -e DNS_SERVER_ADMIN_PASSWORD=votremotdepasse \
  technitium/dns-server:latest

Entre l’horodatage de démarrage du conteneur et la ligne « started successfully » du journal du service, il s’écoule 0,32 seconde. Nous avons vérifié que ce n’était pas un serveur d’amorçage qui répondait à la place du vrai : la première résolution réelle passe juste après. À vide, le processus occupe 44,2 Mo.

En résolution récursive à froid, sans cache, il nous a rendu geeks.fr en 302 ms, korben.info en 197 ms et arxiv.org en 150 ms. Les mêmes noms redemandés ensuite tombent à 2 et 6 ms. Rien d’extraordinaire, c’est le fonctionnement attendu d’un cache, mais l’écart dit bien à quoi sert la machine.

Le tableau de bord de notre serveur d'essai, avec ses seize requêtes et ses six blocages
© Capture geeks.fr

Le blocage : rien par défaut, puis 80 169 domaines

Première surprise, et elle compte pour qui vient de Pi-hole : Technitium n’arrive avec aucune liste de blocage. Une installation neuve résout tout, publicités comprises. Nous avons vérifié avant de toucher à quoi que ce soit : doubleclick.net répondait normalement.

Nous avons donc ajouté la liste de StevenBlack, 2 414 225 octets et 80 170 entrées, et déclenché la synchronisation. Le serveur en a chargé 80 169 et le blocage est devenu effectif en quelques secondes, sous forme de réponse NXDOMAIN.

Le contrôle qui compte est celui qu’on oublie : vérifier que le reste marche toujours. Pendant que doubleclick.net, googleadservices.com et ads.youtube.com renvoyaient NXDOMAIN, geeks.fr et wikipedia.org répondaient normalement avec leur adresse. Ce n’est donc pas un serveur cassé, c’est bien un serveur qui bloque. Coût de ces 80 169 domaines : 50 Mo de mémoire en plus, soit 94 Mo au total. Pour un Raspberry Pi, c’est tenable.

Le piège : trois cases cochées, aucun port ouvert

Voilà ce que nous cherchions sans le savoir. Le chiffrement du trafic DNS est l’argument principal de Technitium face à Pi-hole : DNS-over-HTTPS, DNS-over-TLS et DNS-over-QUIC sont annoncés comme intégrés. Ils sont bien là, et tous les trois sont désactivés par défaut.

Nous les avons donc activés. L’interface affiche trois cases cochées, l’API confirme les trois à true, la sauvegarde répond sans broncher.

Les trois protocoles chiffrés cochés dans la console, sans un mot sur le certificat qu'ils exigent
© Capture geeks.fr

Sauf que rien n’écoute. Une poignée de main TLS sur le port 853 lit zéro octet, le HTTPS ne répond pas. En relevant les ports réellement ouverts à l’intérieur du conteneur, dans /proc/net/tcp et /proc/net/udp, on ne trouve que le 53 en TCP et UDP, et le 5380 de la console. Les écouteurs chiffrés n’ont jamais été ouverts.

La cause est simple et parfaitement logique : aucun certificat TLS n’est fourni, et sans certificat il n’y a pas de service chiffré. Technitium a d’ailleurs tout ce qu’il faut pour ça, un champ de chemin de certificat au format PKCS 12, et même un renouvellement automatique par défi HTTP quand on active DNS-over-HTTP sur le port 80.

Le problème n’est pas la mécanique, il est le silence. Le libellé de la case dit « Enable DNS-over-TLS », son aide dit « activez cette option pour accepter les requêtes DNS-over-TLS », et c’est tout. L’enregistrement ne proteste pas. Le journal du service ne dit pas un mot. Vous repartez en croyant que votre trafic DNS est chiffré, et il ne l’est pas.

Notre avis

Pour un homelab, et si vous en êtes à vous demander par où commencer, Technitium est un excellent choix : il remplace trois logiciels, il est franchement sobre, et son interface montre ce qu’il fait. Les 303 Mo d’image et les 0,32 seconde de démarrage le rendent plus agréable à vivre qu’un Pi-hole flanqué d’un Unbound.

Mais ne le déployez pas en vous fiant aux cases. Cochez le chiffrement, puis vérifiez du dehors qu’il répond vraiment, avec un openssl s_client sur le port 853 ou un simple appel HTTPS sur /dns-query. Un logiciel de vie privée qui vous laisse croire que vous êtes protégé mérite qu’on lui demande des comptes, même quand la raison technique est irréprochable.

Le projet est sur technitium.com, le code sur GitHub.

#DNS #auto-hébergement #homelab #vie privée #Docker #open source #outil du jour
Ajouter geeks.fr à mes sources préférées Un réglage Google, une fois, pour nous retrouver plus souvent dans vos résultats.
Écrit par Echo Rédac IA de geeks.fr Relu et vérifié par Cyril Verglas Fondateur et directeur de la publication

Continuer la lecture