Bloquer les publicités sur tout votre réseau, chiffrer vos requêtes DNS, héberger vos propres noms de domaine internes et même remplacer votre serveur DHCP : Technitium DNS Server fait tout cela, et il présente l’avantage d’être gratuit et open source.

Je vous encourage à regarder ma vidéo YouTube pour une prise en main complète et détaillée.

Sur un réseau local, le DNS est celui qui conditionne une partie de la confidentialité (vie privée), la performance et le confort de tout le réseau. Dans le contexte d’un Homelab, plutôt que d’empiler AdGuard Home ou Pi-hole pour le blocage, Unbound pour la résolution récursive et un service à part pour le DHCP, Technitium réunit l’ensemble dans un seul conteneur.

Dans cet article, je vous propose d’installer Technitium DNS Server avec Docker, puis de le configurer : résolution (récursion native ou forwarders chiffrés), blocage des publicités et des domaines malveillants, zones locales pour résoudre vos machines par leur nom, et même mises à jour dynamiques sécurisées par clé TSIG. Nous verrons aussi comment diagnostiquer une résolution qui ne fonctionne pas.

En bref : Technitium DNS Server est un serveur DNS open source (GPLv3) qui fonctionne à la fois en mode récursif (il résout lui-même depuis les serveurs racines) et autoritatif (il héberge vos zones). Il bloque les publicités au niveau DNS, prend en charge les protocoles chiffrés DoH, DoT et DoQ, signe et valide DNSSEC, embarque un serveur DHCP, et se pilote via une console web. Sur Linux, l’installation la plus pratique passe par Docker en mode réseau host.

Qu’est-ce que Technitium DNS Server ?

Technitium DNS Server est un serveur DNS autoritatif et récursif à la fois, conçu pour le self-hosting et les réseaux d’entreprise. Voici ce qu’il sait faire :

• Résoudre les noms de domaine pour tout votre réseau, soit par récursion native (en interrogeant directement les serveurs racines), soit en déléguant à un résolveur externe via différents protocoles (DNS classique, DNS-over-HTTPS, DNS-over-QUIC, etc.).
• Bloquer les publicités et les domaines malveillants à l’échelle du réseau, à la manière de Pi-hole et AdGuard Home, grâce à des listes de blocage.
• Héberger vos propres zones DNS (domaines internes), avec prise en charge de DNSSEC (signature et validation), des transferts de zone (AXFR/IXFR) et des mises à jour dynamiques (RFC 2136).
• Chiffrer le trafic DNS via DNS-over-TLS (DoT), DNS-over-HTTPS (DoH) et DNS-over-QUIC (DoQ), aussi bien en entrée qu’en sortie (sauf en mode récursif pour l’externe).
• Distribuer les adresses IP grâce à un serveur DHCP intégré
• Synchroniser plusieurs instances via le clustering (apparu en version 14).

Côté projet : Technitium DNS Server est développé par Technitium (Shreyas Zare) et publié sous licence open source GNU GPLv3. Il est entièrement gratuit, sans édition payante. Au niveau des technos utilisées, sachez qu’il est écrit en C# / .NET (la version 15, sortie en avril 2026, repose sur .NET 10) et fonctionne sur Windows, Linux, macOS, Raspberry Pi et Docker. À titre indicatif, l’éditeur annonce une capacité de l’ordre de 100 000 requêtes par seconde sur du matériel grand public.

Ressources officielles :

• Site officiel : technitium.com/dns
• Dépôt GitHub : TechnitiumSoftware/DnsServer
• Notes de version : page des releases

Technitium face à Pi-hole + Unbound et AdGuard Home + Unbound

Si vous venez du couple Pi-hole + Unbound (ou AdGuard Home + Unbound), la logique habituelle consiste à utiliser un outil pour le blocage et un second (Unbound) pour la récursion DNS. L’intérêt de Technitium est de réunir ces deux rôles, dans une même solution.

Je pense sincèrement que c’est là le principal argument de Technitium : une seule brique à installer, mettre à jour et superviser, là où les approches classiques en demandent deux. En contrepartie, l’interface est plus dense (c’est le revers d’un outil qui en fait davantage).

Prérequis

Pour suivre ce guide, il vous faut :

• Un serveur Linux (Debian ou Ubuntu dans nos exemples) avec un accès .
• Docker et Docker Compose installés. Si ce n’est pas le cas, reportez-vous à notre tutoriel d’installation de Docker sur Linux.
• Une adresse IP fixe pour ce serveur. C’est cette adresse que vous distribuerez ensuite comme serveur DNS à vos clients : elle ne doit pas changer. Fixez-la via une réservation DHCP sur votre box/routeur, ou en IP statique sur l’hôte. Dans tout cet article, le serveur porte l’adresse .
• Les ports 53 (UDP et TCP) et 5380 (TCP) disponibles sur l’hôte. Nous verrons que le port 53 est souvent déjà occupé sous Ubuntu.

Note : si votre serveur se trouve derrière un pare-feu maison (OPNsense, pfSense…), assurez-vous d’autoriser le DNS sortant en UDP et en TCP sur le port 53. La récursion native a besoin du TCP pour les réponses volumineuses (DNSSEC notamment). C’est une cause de panne fréquente, sur laquelle nous reviendrons dans la section dépannage.

Installer Technitium DNS Server avec Docker

Nous allons déployer Technitium avec Docker, en mode réseau host. Vous connaissez mes habitudes, la stack sera placée dans un dossier dédié : , avec des bind mounts pour les données et les journaux, et les variables externalisées dans un fichier . Je vous laisse créer cette arborescence avec la commande mkdir :

Voici le fichier :

Et le fichier à placer juste à côté :

Quelques explications sur les choix retenus :

• est compatible avec le port 53. Le conteneur démarre en root et peut donc se lier à ce port privilégié. L’option empêche seulement une élévation de privilèges ultérieure, sans gêner le service.
• La console est associée à l’IP du LAN via . Comme nous n’exposons rien sur Internet, c’est le compromis simple et propre : vous administrez le serveur depuis votre réseau, sans que la console traîne sur d’autres interfaces. Sur un LAN de confiance, elle reste en HTTP : gardez-le en tête.
• Bind mounts plutôt que volumes nommés : la configuration () et les journaux () restent visibles sur l’hôte.
• ou version figée ? L’image simplifie les mises à jour (que vous pouvez automatiser avec Watchtower ou What’s Up Docker). Si vous préférez la reproductibilité, figez une version majeure.

Pourquoi le mode host ?

Le mode host mérite une justification, car c’est un choix important. En partageant directement la pile réseau de l’hôte, Technitium voit les vraies adresses IP des clients, au lieu de ne voir que celle du bridge Docker. C’est indispensable pour :

• Les statistiques par client dans le Dashboard,
• Les règles de blocage et les ACL de récursion ciblées par adresse,
• Le serveur DHCP, si vous l’activez plus tard (il a besoin d’être sur le réseau de diffusion).

C’est pour cette raison que, par rapport au modèle habituel, on ajoute , on supprime tout le bloc (inutile et ignoré en mode host) et on retire le présent dans le template (il ne doit pas rester en mode host, sous peine de modifier la plage de ports éphémères de l’hôte lui-même). C’est une problématique rencontrée avec tous les services comme celui-ci (évoquée dans mon article à propos d’AdGuard Home).

À savoir : en mode host, le conteneur n’obtient pas d’adresse IP propre et ne demande aucun bail DHCP. Il utilise l’IP de l’hôte. « L’IP du conteneur », c’est donc tout simplement l’IP de votre machine Docker (pour ma part ).

Si vous souhaitez plutôt partir sur une version classique en mode bridge, alors utilisez ce fichier Docker Compose :

En mode bridge, la directive a été supprimée, car cette variable sert à associer la console à une IP de l’hôte, ce qui n’a pas de sens ici puisque le conteneur est isolé derrière le bridge. La console est donc exposée via le mapping du port .

Enfin, retenez aussi que le DHCP ne fonctionnera pas correctement en bridge (il a besoin d’être sur le réseau de diffusion) : j’ai laissé la ligne en commentaire avec l’avertissement. Pour le DHCP, le mode host reste obligatoire. Voilà, maintenant à vous de faire le bon choix par rapport à vos besoins !

Libérer le port 53

Sur Ubuntu (et toute installation utilisant le résolveur stub ), le port 53 est déjà occupé par . Technitium ne pourra pas démarrer tant que vous ne l’aurez pas libéré, ce qui va engendrer des problèmes.

Vérifions d’abord qui écoute sur le port 53 :

Si apparaît, on bascule de la manière suivante :

Sur une Debian serveur minimale sans , cette étape est souvent inutile (d’où l’intérêt du contrôle avec avant de faire quoi que ce soit).

Déployer le conteneur

Il ne reste plus qu’à lancer la stack depuis le dossier du projet :

Vérifions que le service DNS écoute bien sur le port 53, sur toutes les interfaces :

Le processus qui écoute directement sur , c’est Technitium : la preuve que le mode host fonctionne. Voici un exemple :

Première connexion à la console d’administration

Rendez-vous sur et connectez-vous avec l’utilisateur et le mot de passe défini dans votre . Le Dashboard s’affiche : il est vide pour l’instant, c’est normal, aucune requête n’a encore transité.

Avant d’aller plus loin, un réflexe de validation utile : ouvrez l’onglet DNS Client de la console et résolvez un domaine public (par exemple ). Cet outil interroge le serveur sans dépendre de la configuration réseau de votre poste. C’est le moyen le plus rapide de confirmer que la résolution fonctionne avant de toucher au reste.

Configurer la résolution DNS

Technitium peut résoudre les noms de deux façons, et c’est ce qui lui permet de remplacer le duo AdGuard Home + Unbound. Avant de configurer, prenons le temps de regarder ces deux méthodes.

Récursion native ou forwarders chiffrés ?

Les deux modes protègent votre vie privée, mais pas contre le même observateur :

Autrement dit : les forwarders chiffrés rendent vos requêtes invisibles pour votre FAI, mais un résolveur unique voit alors l’intégralité de votre historique DNS. La récursion native, à l’inverse, fait qu’aucun acteur ne voit l’ensemble de vos requêtes (le serveur racine n’apprend que le TLD interrogé, le serveur du TLD que le domaine de second niveau, etc.), au prix d’un trafic non chiffré vers les serveurs faisant autorité.

Je retiens la récursion native dans cet article. Mais c’est un arbitrage à faire. Si votre réseau filtre le port 53 sortant, ou si vous préférez chiffrer le canal, les forwarders restent une option parfaitement valable.

Configurer la récursion native

En l’absence de forwarders, Technitium résout par lui-même depuis les serveurs racines mondiaux. Pour que ce mode soit actif, dans la section Settings > Recursion, vous devez passer l’accès sur Allow recursion only for private networks. C’est indispensable pour ne pas transformer votre serveur en résolveur ouvert exploitable depuis l’extérieur (même sur un LAN non exposé, c’est mieux en termes d’hygiène informatique).

Je vous encourage également à activer l’option QNAME minimization. C’est un plus pour la confidentialité du mécanisme de récursion. Technitium n’envoie alors à chaque serveur de la chaîne que le strict nécessaire à chaque fois, sans dévoiler l’adresse à résoudre en une seule fois.

Qu’est-ce que la QNAME minimization ? Normalisée par la RFC 7816, c’est une technique qui consiste à n’envoyer à chaque serveur DNS que la partie du nom dont il a besoin pour répondre. Le serveur racine est interrogé pour « .fr », le serveur pour « it-connect.fr », et seul le serveur faisant autorité reçoit le nom complet. Chaque acteur en apprend ainsi le moins possible sur votre navigation.

Pour utiliser Technitium en tant que DNS récursif, vous devez veiller à ne pas déclarer de résolveur externe. Rendez-vous dans Settings > Proxy & Forwarders : laissez la liste des forwarders vide, puis enregistrez.

Alternative : les forwarders chiffrés (DoH/DoT)

Si vous préférez chiffrer le trafic sortant, vous pouvez solliciter un résolveur DNS externe. Dans ce cas, vous n’allez plus solliciter les serveurs DNS racines, mais directement votre résolveur (comme peuvent le faire Pi-Hole et AdGuard Home). Si c’est votre souhait, rendez-vous dans Settings > Proxy & Forwarders.

Choisissez le Forwarder Protocol (DoH) ou (DoT), puis ajoutez un ou plusieurs résolveurs. Soit vous saisissez vous-même l’adresse de votre résolveur DNS, soit vous choisissez dans la liste Quick select parmi la sélection.

Dans ce mode, c’est le résolveur choisi qui effectue la résolution récursive à votre place ; Technitium ne fait que lui transmettre la requête, chiffrée. La QNAME minimization ne s’applique donc plus côté Technitium.

Bloquer les publicités et les domaines malveillants

C’est l’équivalent intégré de Pi-hole et AdGuard Home. Le blocage est déjà activé au niveau du conteneur ( dans notre Compose). Il reste à l’alimenter avec des listes et à choisir son comportement.

Dans Settings > Blocking, vérifiez tout de même que ce soit bien activé.

Ajoutez des listes de blocage dans le champ Allow / Block List URLs. Une liste préconfigurée contient quelques références, dont les listes de Steven Black, mais vous pouvez aussi pointer vers d’autres listes (comme Red Flag Domains, par exemple).

Réglez l’intervalle de mise à jour automatique des listes (Block List URL Update Interval) et choisissez le Blocking Type, c’est-à-dire la réponse renvoyée pour un domaine bloqué (voir ci-dessous).

À côté des listes, Technitium propose une Blocked Zone (blocage manuel, domaine par domaine) et une Allowed Zone (liste blanche, prioritaire). Pratique pour débloquer un domaine victime d’un faux positif. Malgré la présence de listes, vous gardez la main pour gérer les exceptions.

NXDOMAIN ou 0.0.0.0 : quelle réponse pour un domaine bloqué ?

Le Blocking Type détermine comment Technitium répond quand un domaine est bloqué. Deux approches principales, qui ne disent pas la même chose au client :

Personnellement, j’ai retenu la méthode NXDOMAIN. Pour valider le blocage, demandez un domaine connu pour être bloqué et observez la réponse (soit en mode Web ou en ligne de commande).

La réponse est bien bloquée par Technitium :

Créer des zones DNS locales

Au-delà de la résolution et du blocage, Technitium peut héberger vos propres zones : c’est son rôle autoritatif. Dans un homelab, cela permet de résoudre vos machines par un nom () plutôt que par leur IP.

Lorsque vous créez une zone (Zones > Add Zone), Technitium propose plusieurs types. Voici à quoi ils correspondent avec ce rapide rappel sur les zones DNS :

Pour un homelab, l’essentiel du besoin tient dans la Primary Zone. Créez-en une (par exemple ), puis ajoutez vos enregistrements (type , nom + adresse IP).

À quoi sert le « SOA Serial Date Scheme » ?

Lors de la création d’une zone, vous verrez l’option nommée “Use SOA Serial Date Scheme“, mais à quoi sert-elle ?

Chaque zone faisant autorité possède un enregistrement SOA contenant un numéro de série qui doit augmenter à chaque modification. C’est ce numéro que les serveurs secondaires comparent pour savoir si la zone a changé et déclencher un transfert. Cette option détermine comment il est généré :

• Décochée (par défaut) : un simple compteur entier incrémenté de 1 à chaque changement.
• Cochée : le format daté (par exemple pour la première modification du 28 juin 2026). C’est la convention recommandée par la RFC 1912, lisible d’un coup d’œil.

À noter : l’option ne concerne que les zones dont Technitium génère le SOA (Primary, Conditional Forwarder et Catalog), et il vaut mieux choisir le schéma dès la création.

Mise à jour dynamique des enregistrements avec une clé TSIG

Voici un usage plus avancé, qui illustre encore un peu plus l’intérêt de Technitium, qui est bien plus qu’un bloqueur de pub : les mises à jour dynamiques des enregistrements. Au lieu d’ajouter manuellement chaque enregistrement dans la console, une machine s’enregistre elle-même à son déploiement, via une mise à jour dynamique (RFC 2136) authentifiée par une clé TSIG.

Qu’est-ce que TSIG ? TSIG (Transaction SIGnature, RFC 8945) authentifie les échanges DNS à l’aide d’une clé secrète partagée et d’un HMAC. Une fois en place, TSIG signe le message (authenticité + intégrité), il ne le chiffre pas. C’est un mécanisme d’authentification, pas de confidentialité.

La configuration se fait en deux temps côté Technitium :

Tout d’abord, créez la clé TSIG via le menu Settings > TSIG. Créez une clé (nom , algorithme HMAC-SHA256, Shared Secret laissé vide pour génération automatique). Notez le secret généré.

Puis, vous devez autoriser les mises à jour sur la zone en allant dans : Zones > Votre zone > Options > Zone Options > onglet Dynamic Updates (RFC 2136). Ici, choisissez Allow, puis ajoutez une politique de sécurité : la clé créée précédemment, le domaine couvert ( – n’oubliez pas l’astérisque) et les types autorisés (, ). La clé ne pourra rien toucher d’autre : on applique ici le principe du moindre privilège.

Attention, ne choisissez pas le mode Allow sans définir une stratégie de sécurité avec une clé TSIG. Sinon, n’importe qui peut venir pousser des mises à jour dans votre zone DNS…

Côté machine déployée, vous pouvez utiliser différentes méthodes pour inscrire la machine dans le DNS : Terraform, Ansible, Cloud-init… Et même un simple script Bash pour tester. Voici un script d’exemple (et qui peut être embarqué dans un autre outil) :

Pour que cela fonctionne, vous devez installer ce paquet :

Le fichier au format BIND, à protéger en , contient la clé au format BASE64 :

On exécute le script Bash, et cela a pour effet d’inscrire la machine dans le DNS.

Côté sécurité, trois réflexes :

• Limitez le périmètre des permissions pour les mises à jour dynamiques,
• Créez une clé par usage et par zones (pour pouvoir en révoquer une sans tout casser),
• Veillez à la protection du secret (fichier en , à minima).

Dépannage : quand la résolution DNS ne fonctionne pas

Cette dernière partie de ce guide sera dédiée au dépannage. Nous appliquerons la règle suivante : diagnostiquer du serveur vers le client, en entonnoir. Tant qu’on n’a pas confirmé que Technitium répond en local, inutile de chercher côté poste de travail.

1. Le port 53 est-il en écoute ?

2. Technitium répond-il en local ?

S’il répond en local mais pas depuis un autre poste, le problème est sur le chemin réseau (pare-feu, sous-réseau), pas sur Technitium.

3. L’hôte peut-il joindre un serveur racine en UDP et en TCP ?

Ce double test est important. Un pare-feu qui n’autorise que l’UDP/53 laissera passer les requêtes simples, mais fera échouer certaines requêtes où le TCP/53 est utilisé.

4. Le pare-feu côté client (le faux négatif )

Sous Windows, tente d’abord une résolution inverse (PTR) sur l’IP du serveur pour afficher son nom. Sans zone inverse, vous obtenez un message d’erreur… alors que la résolution directe fonctionne. Préférez PowerShell :

Pour aller plus loin avec Technitium

Nous avons couvert l’essentiel des fonctionnalités, mais Technitium va plus loin :

• Gestion du cache DNS : l’onglet Cache et Settings > Cache permettent d’inspecter et de vider le cache, d’ajuster les TTL (minimum, maximum, cache négatif) et d’activer le prefetch (de quoi accélérer les réponses).

• Journaux et statistiques : l’onglet Logs et Settings > Logging donnent accès aux journaux du serveur, tandis que le Dashboard agrège des statistiques utiles (top clients, domaines les plus demandés, part de requêtes bloquées, domaines les plus bloqués). Une application de journalisation des requêtes est disponible si vous souhaitez tracer chaque requête individuellement.

• Vos propres résolveurs chiffrés (DoH/DoT/DoQ côté serveur) : au-delà des forwarders chiffrés en sortie, Technitium peut aussi répondre à vos clients en DoH, DoT ou DoQ (via Settings > Optional Protocols et un certificat TLS). C’est ce que nous avions vu dans l’article sur la configuration DoH avec Windows Server, mais via Technitium.

• Le DNS App Store : Technitium propose des applications additionnelles (blocage avancé, split-horizon, géo-routage, journalisation…) pour étendre ses capacités directement depuis la console.

• Utilisateurs, rôles et MFA : la console gère plusieurs comptes d’administration avec des permissions par groupe, l’authentification multifacteur (MFA) et, depuis la version 15, le SSO via OIDC. Ce qui répond à certains besoins des entreprises !

• Serveur DHCP intégré : dans l’onglet DHCP, vous pouvez distribuer les baux et même enregistrer automatiquement les machines dans votre zone.
• Clustering : depuis la version 14, plusieurs instances Technitium peuvent synchroniser leur configuration, pour une haute disponibilité du DNS.
• Déploiement sur NAS : si vous n’avez pas de serveur Linux dédié, Technitium s’installe très bien sur un NAS Synology via Container Manager (j’essaierai de vous proposer un article complémentaire pour ce scénario).

Conclusion

Technitium DNS Server tient sa promesse : un seul outil pour résoudre, bloquer, héberger ses zones et distribuer ses baux DHCP, là où d’autres solutions vous obligent à empiler plusieurs services. C’est vraiment une solution pertinente que vous pouvez utiliser comme alternative à AdGuard Home + Unbound ou Pi-Hole + Unbound, voire même les bloqueurs de publicités seuls.

FAQ