Post

🌐 Technitium DNS Server autoritatif et rĂ©cursif

Posté
Preview Image
Par Yann
25 min lire
🌐 Technitium DNS Server autoritatif et rĂ©cursif

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 est gratuit et open source.

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.

  • 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.

Comparatif

Fonction Pi-hole + Unbound AdGuard Home + Unbound Technitium DNS Server
Blocage pub/malveillant Oui (Pi-hole) Oui (AdGuard Home) Oui (intégré)
Récursion native Via Unbound Via Unbound Intégrée
Serveur autoritatif (zones locales) Limité Limité Complet (DNSSEC, AXFR/IXFR)
Forwarders chiffrés DoH/DoT/DoQ Partiel DoH/DoT DoH/DoT/DoQ
Serveur DHCP Oui Oui Oui (intégré)
Mises Ă  jour dynamiques (RFC 2136) Non Non Oui (avec TSIG)
Nombre de services Ă  maintenir 2 2 1

Le principal argument de Technitium : une seule brique Ă  installer, mettre Ă  jour et superviser, lĂ  oĂč les approches classiques en demandent deux.

RĂ©sumĂ©: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.

Prérequis

  • Un serveur Linux (Debian ou Ubuntu) avec un accĂšs sudo.
  • Docker et Docker Compose installĂ©s.
  • 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.0.205.
  • 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.

Libérer le port 53

Technitium ne pourra pas démarrer tant que vous n-aurez pas libéré le port 53

VĂ©rifier qui Ă©coute sur le port 53 :

1
2

# Qui occupe le port 53 ?
sudo ss -ulpn | grep ':53'

unbound utilise le port 53

1
2
3

UNCONN 0      0      192.168.0.205:53         0.0.0.0:*    users:(("unbound",pid=977,fd=7))                         
UNCONN 0      0      192.168.0.205:53         0.0.0.0:*    users:(("unbound",pid=977,fd=5))                         
UNCONN 0      0      192.168.0.205:53         0.0.0.0:*    users:(("unbound",pid=977,fd=3))

ArrĂȘter et dĂ©sactiver Unbound

1
2

sudo systemctl stop unbound
sudo systemctl disable unbound

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é : /sharenfs/docker-app/technitium/, avec des bind mounts pour les données et les journaux, et les variables externalisées dans un fichier .env. Créer cette arborescence avec la commande mkdir :

1
2

mkdir -p /sharenfs/docker-app/technitium
mkdir -p /sharenfs/docker-app/technitium/{config,logs}

Structure

1
2
3
4
5

/sharenfs/docker-app/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 :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

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é :

1
2
3
4
5
6
7
8

# Nom interne par lequel le serveur s'identifie
DNS_SERVER_DOMAIN=dns.rnmkcy.eu

# 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.0.205

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.0.205).

DĂ©ployer le conteneur

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

1
2
3
4

# dossier
cd /sharenfs/docker-app/technitium
# DĂ©marrer le conteneur en arriĂšre-plan
docker compose up -d

1
2
3

[+] up 13/13
 ✔ Image technitium/dns-server:latest Pulled                                                                                                                                                          4.3s
 ✔ Container technitium               Started                                                                                                                                                         0.5s

VĂ©rifier qu’il tourne

1

docker compose ps

1
2

NAME         IMAGE                          COMMAND                  SERVICE      CREATED         STATUS         PORTS
technitium   technitium/dns-server:latest   "/usr/bin/dotnet /op
"   technitium   2 minutes ago   Up 2 minutes

Suivre les journaux (Ctrl+C pour quitter)

1

docker compose logs -f

1
2
3
4
5
6

technitium  | Technitium DNS Server was started successfully.
technitium  | Using config folder: /etc/dns
technitium  | 
technitium  | Note: Open http://dns:5380/ in web browser to access web console.
technitium  | 
technitium  | Press [CTRL + C] to stop...

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

1
2
3

# 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 '

Technitium est le processus dotnet qui Ă©coute directement sur 0.0.0.0:53

Premiùre connexion à la console d’administration

Rendez-vous sur http://192.168.0.205: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 yannig.net). 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.

Récursion native ou forwarders chiffrés ?

Les deux modes protĂšgent votre vie privĂ©e, mais pas contre le mĂȘme observateur :

CritÚre Forwarders chiffrés (DoH/DoT) Récursion native
Trafic vers le serveur en amont Chiffré (HTTPS/TLS) En clair, sur le port 53 (car les serveurs racines ne sont pas compatibles DoH/DoT)
Visibilité par le FAI Aucune Possible (port 53 en clair)
Qui voit l’ensemble de vos requĂȘtes Un rĂ©solveur (Cloudflare, Quad9
) Personne ne voit tout
Dépendance externe Forte (confiance déplacée vers le résolveur) Faible (serveurs racines)
Levier de confidentialité Chiffrement du canal QNAME minimization + DNSSEC
  • 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Ă©.

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.

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).

1
2

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.

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 : retenu 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).

1

dig @192.168.0.205 doubleclick.net

C’est bien bloquĂ©e par Technitium :

Outil migration unbound technitium

Cloner outil

1
2

git clone https://github.com/danczar/unbound2technitium.git
cd ~/unbound2technitium/

Le(s) fichier(s) unbound Ă  migrer: /etc/unbound/unbound.conf.d/local-unbound.conf

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

server:
    # private-address définit les sous-réseaux de réseau privé sur votre infrastructure.
    # Seuls les noms ‘private-domain’ et ‘local-data’  sont autorisĂ©s Ă  avoir ces adresses privĂ©es.
	private-address: 192.168.0.0/16
	private-address: 192.168.10.0/16
	private-address: fe80::/10
	private-address: 2a01:e0a:95a:e2f0::/64

    # Pour configurer un domaine local pour votre réseau, 
    # vous pouvez définir une zone locale dans Unbound. 
    # Cela vous permet d'accéder facilement aux applications 
    # auto-organisées sur votre réseau local.
    #
    local-zone: "home.arpa." transparent
    #local-zone: "home.arpa." static

    # IPv4 + PTR IPV4 + PTR IPV6(option)
    local-data: "cwwk.home.arpa.  86400 IN A 192.168.0.205"
    local-data-ptr: "192.168.0.205  86400 cwwk.home.arpa."
    local-data: "cwwk.home.arpa.  86400 IN AAAA 2a01:e0a:95a:e2f0:aab8:e0ff:fe04:ec45"
    local-data-ptr: "2a01:e0a:95a:e2f0:aab8:e0ff:fe04:ec45  86400 cwwk.home.arpa."

    local-data: "link.home.arpa.  86400 IN A 192.168.0.205"
    local-data-ptr: "192.168.0.205 86400 link.home.arpa."

    local-data: "lldap.home.arpa.  86400 IN A 192.168.0.205"
    local-data-ptr: "192.168.0.205 86400 lldap.home.arpa."

    local-data: "site.home.arpa.  86400 IN A 192.168.0.205"
    local-data-ptr: "192.168.0.205  86400 site.home.arpa."


    local-data: "pve.home.arpa.  86400 IN A 192.168.0.215"
    local-data-ptr: "192.168.0.215 86400 pve.home.arpa."
    local-data: "portainer.home.arpa.  86400 IN A 192.168.0.205"
    local-data-ptr: "192.168.0.205 86400 portainer.home.arpa."
    local-data: "ged.home.arpa.  86400 IN A 192.168.0.205"
    local-data-ptr: "192.168.0.205 86400 ged.home.arpa."

Test

1
2
3

python3 unbound_to_technitium.py \
    --unbound-conf /etc/unbound/unbound.conf.d/local-unbound.conf  \
    --dry-run

Migrer

1
2
3
4

python3 unbound_to_technitium.py \
    --unbound-conf /etc/unbound/unbound.conf.d/local-unbound.conf  \
    --technitium-url http://192.168.0.205:5380 \
    --username admin --password mot_de_passe_technitium

RĂ©sultat

1
2
3
4
5
6
7
8
9
10
11

INFO     Parsing: /etc/unbound/unbound.conf.d/local-unbound.conf
INFO     Authenticated with Technitium successfully
INFO       Created zone: home.arpa (Primary)
INFO       Created zone: in-addr.arpa (Primary)
WARNING    Failed to add record 205.0.168.192.in-addr.arpa PTR: {'server': 'dns.rnmkcy.eu', 'status': 'error', 'errorMessage': 'Cannot add record: record already exists.'}
WARNING    Failed to add record 205.0.168.192.in-addr.arpa PTR: {'server': 'dns.rnmkcy.eu', 'status': 'error', 'errorMessage': 'Cannot add record: record already exists.'}
WARNING    Failed to add record 205.0.168.192.in-addr.arpa PTR: {'server': 'dns.rnmkcy.eu', 'status': 'error', 'errorMessage': 'Cannot add record: record already exists.'}
WARNING    Failed to add record 205.0.168.192.in-addr.arpa PTR: {'server': 'dns.rnmkcy.eu', 'status': 'error', 'errorMessage': 'Cannot add record: record already exists.'}
WARNING    Failed to add record 205.0.168.192.in-addr.arpa PTR: {'server': 'dns.rnmkcy.eu', 'status': 'error', 'errorMessage': 'Cannot add record: record already exists.'}
INFO       Created zone: ip6.arpa (Primary)
INFO       Settings updated

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 zone Rîle Exemple d’usage
Primary Zone Version principale en lecture-écriture, faisant autorité Héberger votre domaine interne de homelab
Secondary Zone Copie en lecture seule synchronisĂ©e (AXFR/IXFR) Redondance / haute disponibilitĂ© d’une zone
Stub Zone Ne contient que les serveurs de noms (NS) d’un domaine Suivre un domaine dĂ©lĂ©guĂ© sans en copier le contenu
Conditional Forwarder Zone Force la rĂ©solution d’un domaine vers des forwarders donnĂ©s Renvoyer un domaine d’entreprise vers son DNS interne (zone Active Directory, par exemple).
Secondary Conditional Forwarder Zone Forwarder conditionnel répliqué depuis un primaire Diffuser une config de forwarding centralisée
Catalog Zone Liste de zones membres pour provisionnement automatique (RFC 9432) GĂ©rer un parc de zones sur plusieurs serveurs
Secondary Catalog Zone Consommateur d’un catalogue, crĂ©e les zones automatiquement Le secondaire qui s’abonne au catalogue
Secondary ROOT Zone (RFC 8806) Copie locale de la zone racine Garder 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 20270722 pour la premiĂšre modification du 22 juillet 2026). C’est la convention recommandĂ©e par la RFC 1912, lisible d’un coup d’Ɠil.

home.arpa

on peut faire quelques tests

1

dig cwwk.home.arpa


1

dig -x 192.168.0.205

On a dans les 2 exemples prĂ©cĂ©dents, l’indication aa(Authoritative Answer) dans les rĂ©ponses. Le rĂ©solveur fait donc autoritĂ© et nous a bien servi les enregistrements configurĂ©s.

1

dig SOA home.arpa

Configurer reverse proxy nginx

Créer le fichier de configutation /etc/nginx/conf.d/dns.rnmkcy.eu.conf

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name dns.rnmkcy.eu;

    include /etc/nginx/conf.d/ssl-modern.inc;

    access_log /var/log/nginx/dns-access.log;
    error_log /var/log/nginx/dns-error.log;

    # DoH endpoint
    location = /dns-query {
        proxy_pass http://192.168.0.205:8053/dns-query;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # Technitium Web UI (everything else)
    location / {
        proxy_pass http://192.168.0.205:5380;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

VĂ©rifier et recharger nginx

1
2

sudo nginx -t
sudo systemctl reload nginx

Modifier le paramétrage Technitium: Settings -> Web Service
HTTPS Options: ✔Enable HTTPS
Save Settings

Lien https://dns.rnmkcy.eu

Configuration SSO pour Technitium avec Authelia OIDC

Dans cet article de blog, nous allons configurer Authelia comme fournisseur OIDC et l’utiliser pour activer l’authentification unique (SSO) dans Technitium

Etapes

  • LLDAP: CrĂ©er un utilisateur techtinium
  • Authelia:
    • VĂ©rifier que le fournisseur OIDC est actif
    • CrĂ©ation client OIDC techtinium
  • Techtinium:
    • Activer SSO
    • Connexion via SSO

LLDAP - Authelia

Pour que Techtinium puisse fonctionner avec Authelia, il faut créer un utilisateur avec LLDAP qui est la base utlisée par Authelia

Ouvrir LLDAP (accĂšs local): https://lldap.home.arpa/

  • ajouter un utilisateur nommĂ© techtinium et son mot de passe
  • CrĂ©er le groupe authelia (si inexistant), ajouter l’utilisateur techtinium Ă  ce groupe

Se connecter avec utilisateur nommé techtinium et son mot de passe sur https://auth.rnmkcy.eu/ Suivre la procédure pour créer une authentification à 2 facteurs TOTP

1 - Nous avons créer dans LLDAP un utilisateur techtinium qui appartient au groupe authelia 2 - Connexion avec utilisateur techtinium sur authelia https://auth.rnmkcy.eu pour ajouter une connexion via TOTP

Authelia fournisseur OIDC

Authelia - Création secret client

Authelia nous demande de définir un secret client sécurisé.

Vous pouvez en générer un via la commande suivante :

1

authelia crypto hash generate pbkdf2 --variant sha512 --random --random.length 72 --random.charset rfc3986

La commande précédente renvoie 2 lignes

1
2

Random Password: -G3xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Digest: $pbkdf2-sha512xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

⚠ Veuillez noter le mot de passe en clair (Random Password) ainsi que le hachage $pbkdf2 (Digest) du mot de passe pour une utilisation ultĂ©rieure.

CÎté Technitium - Activer SSO

Administration → Sessions → Single Sign-On

  • Adresse de mĂ©tadonnĂ©es: https://auth.rnmkcy.eu/.well-known/openid-configuration
  • Client ID / Secret: Authelia (Random Password)
  • Autoriser L’inscription : Allow New User Sign Up
  • Enregistrer Config

L’URI de redirect/callback est https://dns.rnmkcy.eu/sso/callback

CÎté Authelia - Création client OIDC

Mettez ce qui suit Ă  la fin de votre configuration Authelia /etc/authelia/configuration.yml :

1
2
3
4
5
6
7
8

identity_providers:
  oidc:
    [...]
    clients:
      - client_id: immich
        [...]
      - client_id: technitium


1
2
3
4
5
6
7
8
9
10
11
12
13
14

    clients:
      - client_id: technitium
        client_name: technitium OIDC
        client_secret: '$pbkdf2-sha512$310000$IxPfnOlpxWpaikXDw.qTSg$1d6xUB2YxVzwg.d7rNF.JhESblbfSgM.nuQJWrZgyj21IGKC7LCDHtMnuLvzNmuGy9Hr3INsL02tCbqXCwHOgQ'
        public: false
        authorization_policy: 'two_factor'
        redirect_uris:
          - 'https://dns.rnmkcy.eu/sso/callback'
        scopes:
          - 'openid'
          - 'profile'
          - 'email'
        userinfo_signed_response_alg: 'none'
        token_endpoint_auth_method: 'client_secret_post'

AprĂšs avoir ajustĂ© la configuration d’Authelia, vĂ©rifiez et redĂ©marrez-le pour appliquer la nouvelle configuration. Inspectez activement les journaux des conteneurs pour dĂ©tecter d’éventuels problĂšmes.

1
2
3
4
5

# en mode su
# vérification
authelia validate-config --config /etc/authelia/configuration.yml
# relancer
systemctl restart authelia

Technitium via SSO

Ouvrir le lien https://dns.rnmkcy.eu

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) :

1
2
3
4
5
6
7
8
9
10
11
12
13

HOSTNAME="srv-passbolt"
ZONE="lab.it-connect.fr"
DNS="192.168.0.205"                       # 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 <<EOF
server ${DNS}
zone ${ZONE}
update delete ${HOSTNAME}.${ZONE}. A
update add ${HOSTNAME}.${ZONE}. 300 A ${IP}
send
EOF

Pour que cela fonctionne, vous devez installer ce paquet :

1

sudo apt install dnsutils

Le fichier /etc/ddns-deploy.key au format BIND, à protéger en chmod 600, contient la clé au format BASE64 :

1
2
3
4

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 ?

1
2
3
4
5
6
7
8
9

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.0.205: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 ?

1

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 ?

1
2
3
4
5

# 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 :

1
2
3
4
5

# RĂ©solution directe, sans le bruit du reverse lookup
Resolve-DnsName -Name it-connect.fr -Server 192.168.0.205

# Joignabilité du port 53/TCP (pour écarter un blocage réseau)
Test-NetConnection 192.168.0.205 -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).

Screenshot of DNS Server UI on the Cache tab: left sidebar with domains, top navigation, and a right panel showing JSON root data; input shows example.com and a Flush button.

  • 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.

Screenshot of a DNS server management interface showing the Logs tab with a Query Logs form, including fields for app name, class path, page number, logs per page, date range, and filters like client IP, protocol, response type, domain, and type; action buttons labeled Query, Export, Reset and a Live Update option.

  • 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.

Machine, CWWK
dns
Cet article est sous licence CC BY 4.0 par l'auteur.