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 :
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.
FonctionPi-hole + UnboundAdGuard Home + UnboundTechnitium DNS ServerBlocage pub/malveillantOui (Pi-hole)Oui (AdGuard Home)Oui (intégré)Récursion nativeVia UnboundVia UnboundIntégréeServeur autoritatif (zones locales)LimitéLimitéComplet (DNSSEC, AXFR/IXFR)Forwarders chiffrés DoH/DoT/DoQPartielDoH/DoTDoH/DoT/DoQServeur DHCPOuiOuiOui (intégré)Mises à jour dynamiques (RFC 2136)NonNonOui (avec TSIG)Nombre de services à maintenir221
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 sudo.
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 192.168.10.200.
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é : /opt/docker-compose/technitium/, avec des bind mounts pour les données et les journaux, et les variables externalisées dans un fichier .env. Je vous laisse créer cette arborescence avec la commande mkdir :
/opt/docker-compose/technitium/
├── docker-compose.yml
├── .env
├── config/ # Bind mount /etc/dns (configuration, zones, listes de blocage)
└── logs/ # Bind mount /var/log/technitium/dns (journaux)
Voici le fichier docker-compose.yml :
services:
technitium:
container_name: technitium
hostname: dns
image: technitium/dns-server:latest
# Mode host : indispensable pour voir les vraies IP des clients et utiliser le DHCP
network_mode: “host”
environment:
– DNS_SERVER_DOMAIN=${DNS_SERVER_DOMAIN}
– DNS_SERVER_ADMIN_PASSWORD=${DNS_SERVER_ADMIN_PASSWORD}
– DNS_SERVER_WEB_SERVICE_LOCAL_ADDRESSES=${DNS_SERVER_WEB_SERVICE_LOCAL_ADDRESSES}
– DNS_SERVER_ENABLE_BLOCKING=true
– DNS_SERVER_LOG_USING_LOCAL_TIME=true
– DNS_SERVER_LOG_FOLDER_PATH=/var/log/technitium/dns
– TZ=Europe/Paris
volumes:
– ./config:/etc/dns
– ./logs:/var/log/technitium/dns
security_opt:
– no-new-privileges:true
restart: unless-stopped
Et le fichier .env à placer juste à côté :
# Nom interne par lequel le serveur s’identifie
DNS_SERVER_DOMAIN=dns.lab.it-connect.fr
# Mot de passe du compte “admin” de la console web, appliqué au démarrage du conteneur.
DNS_SERVER_ADMIN_PASSWORD=VotreMotDePasseRobuste
# IP fixe du serveur : la console web (port 5380) n’écoutera QUE sur cette adresse
DNS_SERVER_WEB_SERVICE_LOCAL_ADDRESSES=192.168.10.200
Quelques explications sur les choix retenus :
no-new-privileges: true 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 DNS_SERVER_WEB_SERVICE_LOCAL_ADDRESSES. 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 (./config) et les journaux (./logs) restent visibles sur l’hôte.
:latest ou version figée ? L’image :latest 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 network_mode: “host”, on supprime tout le bloc ports: (inutile et ignoré en mode host) et on retire le sysctls 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 192.168.10.200).
Si vous souhaitez plutôt partir sur une version classique en mode bridge, alors utilisez ce fichier Docker Compose :
services:
technitium:
container_name: technitium
hostname: dns
image: technitium/dns-server:latest
ports:
– “5380:5380/tcp” # Console web d’administration (HTTP)
– “53:53/udp” # Service DNS (UDP)
– “53:53/tcp” # Service DNS (TCP)
# Ci-dessous, décommenter selon les protocoles que vous allez utiliser
# – “853:853/udp” # DNS-over-QUIC (DoQ)
# – “853:853/tcp” # DNS-over-TLS (DoT)
# – “443:443/udp” # DNS-over-HTTPS (HTTP/3)
# – “443:443/tcp” # DNS-over-HTTPS (HTTP/1.1, HTTP/2)
# – “67:67/udp” # Serveur DHCP (nécessite toutefois le mode host pour fonctionner)
environment:
– DNS_SERVER_DOMAIN=${DNS_SERVER_DOMAIN}
– DNS_SERVER_ADMIN_PASSWORD=${DNS_SERVER_ADMIN_PASSWORD}
– DNS_SERVER_ENABLE_BLOCKING=true
– DNS_SERVER_LOG_USING_LOCAL_TIME=true
– DNS_SERVER_LOG_FOLDER_PATH=/var/log/technitium/dns
– TZ=Europe/Paris
volumes:
– ./config:/etc/dns
– ./logs:/var/log/technitium/dns
security_opt:
– no-new-privileges:true
restart: unless-stopped
En mode bridge, la directive DNS_SERVER_WEB_SERVICE_LOCAL_ADDRESSES 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 5380:5380.
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 67:67/udp 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 systemd-resolved), le port 53 est déjà occupé par 127.0.0.53. 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 :
# Qui occupe le port 53 ?
sudo ss -ulpn | grep ‘:53’
Si systemd-resolved apparaît, on bascule de la manière suivante :
# Etape 1 – Désactiver le résolveur stub qui occupe le port 53
sudo nano /etc/systemd/resolved.conf
# dans la section [Resolve], décommenter/ajouter :
# DNSStubListener=no
# Etape 2 – Pointer resolv.conf vers les vrais upstreams (et non plus vers le stub 127.0.0.53)
sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
# Etape 3 – Redémarrer le service
sudo systemctl restart systemd-resolved
Sur une Debian serveur minimale sans systemd-resolved, cette étape est souvent inutile (d’où l’intérêt du contrôle avec ss avant de faire quoi que ce soit).
Déployer le conteneur
Il ne reste plus qu’à lancer la stack depuis le dossier du projet :
cd /opt/docker-compose/technitium
# Démarrer le conteneur en arrière-plan
docker compose up -d
# Vérifier qu’il tourne
docker compose ps
# Suivre les journaux (Ctrl+C pour quitter)
docker compose logs -f
Vérifions que le service DNS écoute bien sur le port 53, sur toutes les interfaces :
# Le service DNS doit écouter en UDP et en TCP sur 0.0.0.0:53
sudo ss -ulnp ‘sport = :53’
sudo ss -tlnp ‘sport = :53’
Le processus dotnet qui écoute directement sur 0.0.0.0:53, c’est Technitium : la preuve que le mode host fonctionne. Voici un exemple :
Première connexion à la console d’administration
Rendez-vous sur http://192.168.10.200:5380 et connectez-vous avec l’utilisateur admin et le mot de passe défini dans votre .env. 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 it-connect.fr). 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 :
CritèreForwarders chiffrés (DoH/DoT)Récursion nativeTrafic vers le serveur en amontChiffré (HTTPS/TLS)En clair, sur le port 53 (car les serveurs racines ne sont pas compatibles DoH/DoT)Visibilité par le FAIAucunePossible (port 53 en clair)Qui voit l’ensemble de vos requêtesUn résolveur (Cloudflare, Quad9…)Personne ne voit toutDépendance externeForte (confiance déplacée vers le résolveur)Faible (serveurs racines)Levier de confidentialitéChiffrement du canalQNAME minimization + DNSSEC
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 .fr 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 Https (DoH) ou Tls (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 (DNS_SERVER_ENABLE_BLOCKING=true 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).
https://raw.githubusercontent.com/StevenBlack/hosts/master/alternates/gambling/hosts
https://dl.red.flag.domains/adguard/red.flag.domains.txt
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 :
NX DomainAnything Address (0.0.0.0)Code de réponseNXDOMAIN (RCODE 3)NOERRORSémantique« ce domaine n’existe pas »« il existe, et pointe vers 0.0.0.0 »Réaction du clientAbandonne aussitôt, aucune connexionPeut tenter une connexion vers 0.0.0.0, qui échoueIntérêtPlus propre, plus rapide côté clientRassure certaines applications mal écrites face à un NXDOMAIN
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).
dig @192.168.10.200 doubleclick.net
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 (dns.lab.it-connect.fr) 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 :
Type de zoneRôleExemple d’usagePrimary ZoneVersion principale en lecture-écriture, faisant autoritéHéberger votre domaine interne de homelabSecondary ZoneCopie en lecture seule synchronisée (AXFR/IXFR)Redondance / haute disponibilité d’une zoneStub ZoneNe contient que les serveurs de noms (NS) d’un domaineSuivre un domaine délégué sans en copier le contenuConditional Forwarder ZoneForce la résolution d’un domaine vers des forwarders donnésRenvoyer un domaine d’entreprise vers son DNS interne (zone Active Directory, par exemple).Secondary Conditional Forwarder ZoneForwarder conditionnel répliqué depuis un primaireDiffuser une config de forwarding centraliséeCatalog ZoneListe de zones membres pour provisionnement automatique (RFC 9432)Gérer un parc de zones sur plusieurs serveursSecondary Catalog ZoneConsommateur d’un catalogue, crée les zones automatiquementLe secondaire qui s’abonne au catalogueSecondary ROOT Zone (RFC 8806)Copie locale de la zone racineGarder les requêtes racine en local (vie privée + perfs)
Pour un homelab, l’essentiel du besoin tient dans la Primary Zone. Créez-en une (par exemple lab.it-connect.fr), puis ajoutez vos enregistrements (type A, 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é AAAAMMJJnn (par exemple 2026062801 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 ddns-deploy, 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é dynamicupdate créée précédemment, le domaine couvert (*.lab.it-connect.fr – n’oubliez pas l’astérisque) et les types autorisés (A, AAAA). 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) :
HOSTNAME=”srv-passbolt”
ZONE=”lab.it-connect.fr”
DNS=”192.168.10.200″ # le serveur Technitium
IP=”$(hostname -I | awk ‘{print $1}’)” # IP primaire de la machine
# -k : fichier de clé (secret hors de la ligne de commande, voir plus bas)
nsupdate -k /etc/ddns-deploy.key <
Pour que cela fonctionne, vous devez installer ce paquet :
sudo apt install dnsutils
Le fichier /etc/ddns-deploy.key au format BIND, à protéger en chmod 600, contient la clé au format BASE64 :
key “dynamicupdate” {
algorithm hmac-sha256;
secret “MTIzNDU2YXplcnR5MTIzNDU2”;
};
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 600, à 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 ?
sudo ss -ulnp ‘sport = :53’
# Attendu : 0.0.0.0:53 … dotnet
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
UNCONN 0 0 127.0.0.1:53 0.0.0.0:* users:((“dotnet”,pid=2627,fd=290))
UNCONN 0 0 192.168.10.200:53 0.0.0.0:* users:((“dotnet”,pid=2627,fd=256))
UNCONN 0 0 0.0.0.0:53 0.0.0.0:* users:((“dotnet”,pid=2627,fd=242))
UNCONN 0 0 [::]:53 [::]:* users:((“dotnet”,pid=2627,fd=244))
2. Technitium répond-il en local ?
dig @127.0.0.1 it-connect.fr +short
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 ?
# Interroger directement une racine par son IP (a.root-servers.net), en UDP
dig @198.41.0.4 fr NS +norecurse +timeout=3
# Puis en TCP
dig @198.41.0.4 fr NS +norecurse +tcp +timeout=3
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 nslookup)
Sous Windows, nslookup 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 :
# Résolution directe, sans le bruit du reverse lookup
Resolve-DnsName -Name it-connect.fr -Server 192.168.10.200
# Joignabilité du port 53/TCP (pour écarter un blocage réseau)
Test-NetConnection 192.168.10.200 -Port 53
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
Technitium DNS Server est-il gratuit ?
Oui, Technitium DNS Server est gratuit et open source, publié sous licence GNU GPLv3. Il n’existe pas d’édition payante ni de fonctionnalité limitée : l’ensemble des fonctions (récursion, blocage, zones, DHCP, DoH/DoT/DoQ, clustering) est disponible sans frais.
Technitium est-il une bonne alternative à Pi-hole ?
Oui. Technitium offre le même blocage des publicités que Pi-hole, mais intègre en plus la résolution récursive (qui nécessite Unbound à côté de Pi-hole), un serveur autoritatif complet pour vos zones, un serveur DHCP, les protocoles chiffrés DoH/DoT/DoQ et les mises à jour dynamiques. C’est donc une alternative à Pi-hole + Unbound réunis en un seul outil.
Faut-il utiliser la récursion native ou des forwarders chiffrés avec Technitium ?
Cela dépend de votre priorité. La récursion native évite qu’un résolveur unique voie l’ensemble de vos requêtes, mais le trafic vers les serveurs faisant autorité circule en clair sur le port 53. Les forwarders chiffrés (DoH/DoT) masquent vos requêtes au FAI, mais confient tout votre historique à un résolveur unique.
Technitium peut-il remplacer mon serveur DHCP ?
Oui, Technitium embarque un serveur DHCP. Pour qu’il fonctionne, le conteneur Docker doit tourner en mode réseau host, afin d’être présent sur le réseau de diffusion. Le DHCP intégré peut aussi enregistrer automatiquement les machines dans une zone DNS locale, ce qui évite d’avoir à maintenir un service DHCP séparé sur un petit réseau.
Technitium DNS Server protège-t-il vraiment la vie privée ?
Technitium apporte de réels gains : chiffrement du trafic via DoH, DoT et DoQ, validation DNSSEC, récursion native avec QNAME minimization, et journalisation complète des requêtes, le tout sur votre serveur (et donc chez vous). Il faut toutefois faire un arbitrage au niveau de la méthode de résolution de noms (récursif VS résolveurs externes).
Cofondateur d’IT-Connect et Microsoft MVP “Cloud and Datacenter Management”. Mon obsession depuis près de 15 ans ? Rendre l’administration système et la cybersécurité accessibles, que vous soyez junior ou confirmé. Plus qu’un métier, l’IT est pour moi une véritable passion. J’accompagne au quotidien les sysadmins et les professionnels de l’IT dans leur montée en compétences et leur veille technique.