Migrer de Unbound + AdGuard Home vers Technitium DNS sur Proxmox

Depuis que j’ai commencé à utiliser un serveur DNS pour mon homelab, ma résolution DNS reposait sur deux services complémentaires : Unbound en résolveur récursif et AdGuard Home pour le filtrage. Une stack éprouvée, que j’ai utilisée pendant plus de 2 ans, sans aucun problème. Mais elle avait un coût invisible : deux services à mettre à jour, deux configurations à sauvegarder, et une empreinte mémoire qui s’ajoutait sur mon serveur Proxmox.

C’est là que Technitium DNS est entré dans mon radar. Cette solution DNS autoritaire et récursive tout-en-un combine résolveur, filtrage (le fameux sinkhole) et gestion de zones autoritatives derrière une seule interface web (ou via API). En une seule instance, elle pouvait remplacer les deux services de ma stack. J’ai donc décidé de tenter la migration, et c’est cette expérience que je détaille ici, étape par étape, sur mon homelab.

Pour vous situer : ma migration suppose un Proxmox VE déjà installé et fonctionnel, ainsi qu’un accès root au nœud (interface web ou SSH). Les configurations utilisées ci-dessous (adresse IP, domaine, ID de conteneur) sont celles de mon homelab, adaptées en exemples génériques, remplacez-les par les vôtres ou celles qui vous conviennent le mieux. Si les Community Scripts ne vous disent rien, je vous recommande d’abord mon article sur le sujet.

1. Le déploiement du conteneur LXC Technitium DNS

Je récupère la commande

Sur community-scripts.org, je cherche Technitium DNS et je copie la commande à lancer dans le shell de mon nœud Proxmox :

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/technitiumdns.sh)"

Vérifiez toujours la commande directement sur le site, elle peut être mise à jour, ou le script peut évoluer. Vous pouvez le consulter sur GitHub.

Mes choix d’installation

Je choisis le mode Advanced Install : ça me permet d’ajuster finement la configuration (réseau, VLAN, ressources, protection du conteneur, etc.). Voici les configurations que j’applique (je remplace volontairement certaines valeurs par des exemples génériques) :

Je coche également la protection du conteneur : pour un service central comme le DNS, c’est une assurance supplémentaire contre les suppressions accidentelles.

Si vous n’êtes pas à l’aise avec les scripts de Community Scripts, ou que vous ne connaissez pas cette façon d’installer un conteneur LXC ou une VM, je vous recommande de lire mon article sur le sujet : Installer un LXC ou une VM sur Proxmox avec Community Scripts.

L’installation s’est terminée en quelques secondes et a affiché :

✔️ Installed Dependencies
✔️ Successfully deployed archive to /opt/technitium/dns
✔️ Service created
✔️ Cleaned
✔️ Completed successfully!

🚀 Technitium DNS setup has been successfully initialized!
💡 Access it using the following URL:
🌐 http://192.168.1.10:5380

Note : La version installée par le script au moment de la rédaction de cet article est la 15.4.

Première connexion

J’ouvre l’URL fournie dans mon navigateur : http://192.168.1.10:5380. Au premier lancement, Technitium me demande de changer le mot de passe administrateur. Celui par défaut est admin. Une fois le mot de passe changé, j’arrive sur le Dashboard, qui affiche en un coup d’œil les requêtes en cours, l’état du cache et le nombre de domaines bloqués. Pour l’instant tout est vide, mais c’est normal : je n’ai pas encore configuré mes zones, mes listes de blocage, ni mes serveurs pour utiliser Technitium.

2. Configurer la résolution DNS (remplacement d’Unbound)

Lorsqu’on vient d’Unbound, une question fondamentale se pose : vaut-il mieux utiliser la récursivité native ou le forwarding chiffré ?

• La récursivité native : Technitium joue le rôle de résolveur autonome. Il interroge directement les serveurs racines du DNS mondial (Root Servers), puis les serveurs de TLD (.com, .fr), sans dépendre d’aucun intermédiaire. C’est le fonctionnement classique d’Unbound, mais les requêtes voyagent en clair sur Internet et restent visibles par votre FAI.
• Le forwarding chiffré (DoT / DoQ) : Technitium délègue la résolution à un serveur amont de confiance (comme Quad9) en chiffrant le trafic via du DNS-over-TLS (DoT) ou du DNS-over-QUIC (DoQ). Votre FAI ne peut plus lire ni altérer vos requêtes, mais vous dépendez d’un tiers pour la résolution et il voit passer vos requêtes.

Pour mon Homelab et tout mon réseau domestique, j’ai opté pour le Forwarding chiffré en DoT vers Quad9. Le choix de Quad9 ne doit rien au hasard : cette organisation à but non lucratif basée en Suisse est reconnue mondialement pour son engagement strict en matière de respect de la vie privée (aucune collecte ni revente de données personnelles, conformité RGPD stricte et auditée).

Associé au chiffrement DNS-over-TLS, ce choix me permet de masquer l’intégralité de mon trafic DNS externe vis-à-vis de mon FAI, tout en bénéficiant de l’immense cache global de Quad9 pour des temps de réponse ultra-rapides et d’une protection native contre les domaines malveillants.

Configuration des Forwarders

Dans Settings > Proxy & Forwarders, section Forwarders :

1. Je vais sur le menu Quick Select et je choisis Quad9 Secure (DNS-over-TLS).
2. Technitium pré-remplit automatiquement la liste des serveurs :
   • dns.quad9.net (9.9.9.9:853)
   • dns.quad9.net (149.112.112.112:853)
3. Dans Forwarder Protocol, je sélectionne DNS-over-TLS.
4. Je valide en cliquant sur Save settings.

Réglages de la récursivité locale

Même en mode Forwarder, la section Settings > Recursion de Technitium doit rester active pour autoriser mes équipements locaux à interroger le serveur. Je conserve donc les paramètres recommandés par défaut :

• Recursion : Allow Recursion Only For Private Networks (limite l’accès à vos sous-réseaux locaux pour éviter que votre serveur ne devienne un relais ouvert sur Internet. Il faudrait exposer votre réseau, mais il s’agit d’une bonne pratique d’hygiène).
• QNAME Minimization : activé (technique d’anonymisation qui ne transmet aux serveurs amonts que le strict minimum du nom de domaine recherché).
• Locally Served DNS Zones : activé (évite de faire fuiter vers Internet les requêtes d’adresses privées non résolues).

Note Sécurité & DNSSEC : En déléguant les requêtes à Quad9 en DoT, la validation DNSSEC est effectuée en amont par Quad9 et Technitium effectue également sa propre vérification des signatures DNSSEC. Je conserve ainsi le même niveau de sécurité qu’avec Unbound.

3. Ma zone locale et mes enregistrements

C’est ici que je recréé mes enregistrements DNS locaux, ceux qui pointaient auparavant vers mes anciennes zones.

Créer une zone

Dans Zones, je clique sur Add Zone :

• Nom de la zone : home.lab (exemple pour un domaine local)
• Type : Primary zone
• Option Use SOA Serial Date Scheme : cochée (utile pour horodater les modifications de zone)

Enfin, je clique sur Add pour créer la nouvelle zone.

Technitium propose 8 types de zones pour répondre à tous les besoins (de la simple maison au grand réseau d’entreprise). Pour mon Homelab, je crée une simple Primary Zone, mais voici à quoi servent les autres options si vous souhaitez aller plus loin :

Ajouter un enregistrement

Depuis la zone, je clique sur Add Record : Depuis la zone, je clique sur Add Record :

• Name : dns1 (FQDN : dns1.home.lab)
• Type : A (par défaut, utilisé pour associer un nom à une IPv4)
• TTL : 3600 (par défaut, durée de vie du cache DNS)
• IPv4 Address : IP_SERVEUR_TECHNITIUM (exemple : 192.168.1.10)

Je coche également les deux options de résolution inverse :

• Add reverse (PTR) record
• Create reverse zone for PTR record

Pourquoi le PTR ? Cela permet la résolution inverse (connaître le nom d’hôte à partir de l’IP). C’est une excellente pratique pour avoir des logs réseau lisibles.

Je répète ensuite l’opération pour chacun des services de mon homelab.

4. Le filtrage (remplacement d’AdGuard Home)

C’est l’étape clé qui reproduit le comportement d’AdGuard Home ou de Pi-hole : le sinkhole. L’objectif est d’intercepter et de bloquer au niveau du DNS les requêtes vers les régies publicitaires, les trackers et les sites malveillants.

Activer le moteur de blocage

Je me rends dans Settings > Blocking, puis j’applique les configurations suivantes :

• Enable Blocking : coché.
• Allow TXT Blocking Report : activé. Ce paramètre permet à Technitium de fournir des détails dans les réponses aux requêtes bloquées.

Choisir le type de réponse

Technitium propose plusieurs manières de répondre à un client qui tente de joindre un domaine filtré :

• ANY Address : la méthode historique d’AdGuard Home et Pi-hole. Le serveur renvoie une adresse nulle (0.0.0.0 en IPv4 et :: en IPv6), coupant immédiatement la tentative de connexion du client.
• NX Domain (recommended) : le serveur indique au client que le domaine n’existe tout simplement pas. C’est le type recommandé par Technitium, car il est plus propre et évite certains comportements indésirables sur certains clients.
• Custom Address : Permet de spécifier manuellement une adresse IP personnalisée (IPv4 et IPv6) vers laquelle rediriger les requêtes bloquées. C’est très pratique si vous hébergez une page Web locale d’avertissement (“Page de blocage / Sinkhole Web Page”) ou si vous souhaitez rediriger le trafic filtré vers un serveur spécifique de votre réseau.

Mon choix : J’opte pour NX Domain (recommended). Contrairement à mon ancienne installation sous AdGuard Home qui utilisait 0.0.0.0, le mode NXDomain est plus propre selon les standards RFC : le client comprend immédiatement que le domaine n’existe pas et abandonne sa requête sans chercher à contacter une IP nulle ou à attendre un timeout.

Importer et gérer les listes de blocage

Pour alimenter le moteur de filtrage, Technitium permet de charger des listes de blocage distantes via le champ Allow / Block List URLs.

Il est tout à fait possible de coller des URLs manuellement (une par ligne), mais le plus simple est d’utiliser le menu déroulant Quick Add situé juste en dessous :

1. Je clique sur Quick Add.
2. Je sélectionne une liste pré-configurée parmi le choix proposé (StevenBlack, OISD, Hagezi, etc.).
3. Pour mon installation, je sélectionne Hagezi [Multi PRO++ - Maximum protection].

En un clic, Technitium ajoute automatiquement l’URL de la liste dans la zone de texte :

https://cdn.jsdelivr.net/gh/hagezi/dns-blocklists@latest/wildcard/pro.plus-onlydomains.txt

Cette liste constitue un excellent compromis pour un Homelab : elle offre une protection maximale contre les publicités, la télémétrie, le phishing et le tracking, tout en maintenant un taux de faux positifs extrêmement bas.

Astuces utiles :

• Ajouter une liste d’exception (whitelist) distante : Si vous souhaitez importer une liste d’autorisations hébergée en ligne, il suffit d’ajouter un point d’exclamation ! au tout début de son URL (ex: !https://exemple.com/whitelist.txt). Technitium nous prévient que cette option ne doit pas être utilisée avec les listes blanches au format Adblock Plus.
• Exceptions locales rapides : Si un domaine est bloqué à tort et que vous devez le débloquer rapidement, pas besoin de modifier vos listes distantes : utilisez directeément l’onglet Allowed dans le menu supérieur de Technitium pour autoriser un domaine précis en quelques secondes.

Fréquence de mise à jour & Sauvegarde

Je conserve la valeur par défaut pour Block List Update Interval, soit 24 heures : Technitium se charge ainsi de télécharger, nettoyer et mettre à jour automatiquement l’ensemble des listes toutes les 24 heures, en arrière-plan et sans interrompre le service.

Dès que je clique sur Save settings, Technitium déclenche le premier téléchargement et la compilation de la liste Hagezi PRO++. En retournant sur le Dashboard, le compteur de domaines bloqués s’est instantanément mis à jour avec plus de 240 000 règles actives.

L’astuce sauvegarde : Avant de passer à la suite, profitez-en pour cliquer sur le bouton Backup Settings situé tout en bas de la page. En un seul clic, Technitium génère un fichier .zip contenant l’intégralité de votre configuration (zones locales, clés DNSSEC, paramètres des forwarders et listes de blocage).

5. Configuration des serveurs

Une fois Technitium entièrement configuré et validé sur son interface web, il reste à configurer l’ensemble des serveurs de mon homelab.

La bascule DHCP sur pfSense

Pour que tous les clients du réseau (smartphones, PC, TV, objets connectés) basculent automatiquement sur Technitium sans aucune intervention manuelle, je mets à jour les options distribuées par le serveur DHCP de pfSense :

1. Je me rends dans Services > DHCP Server.
2. Je sélectionne l’onglet correspondant à un de mes VLAN (ou le LAN si vous n’utilisez pas de VLAN).
3. Dans la section Server Options, je renseigne l’adresse IP de mon serveur Technitium dans le champ DNS Server 1.
4. (Optionnel) Si vous avez mis en place une seconde instance Technitium pour de la haute disponibilité, renseignez son IP juste en dessous de la première.
5. Je clique sur Save puis sur Apply Changes.

Note : Les équipements réseau adopteront le nouveau serveur DNS au moment du renouvellement de leur bail DHCP.

Le DNS statique des serveurs

Pour les VM, serveurs à IP fixe et l’hyperviseur lui-même, il est préférable de déclarer le serveur DNS de manière statique afin d’éviter tout problème de résolution au démarrage :

• Sur Proxmox VE : je sélectionne mon nœud > System > DNS, puis j’édite le champ DNS Server 1 avec l’IP de mon serveur Technitium.
• Sur un serveur Linux traditionnel : Si le fichier est géré en direct, j’édite /etc/resolv.conf :

sudo nano /etc/resolv.conf

Je remplace la directive existante par :

nameserver IP_SERVEUR_TECHNITIUM

Note : si votre distribution utilise systemd-resolved, éditez la ligne DNS=IP_SERVEUR_TECHNITIUM dans /etc/systemd/resolved.conf puis relancez le service avec sudo systemctl restart systemd-resolved.

Validation et tests finaux

Avant de couper définitivement mes anciens conteneurs Unbound et AdGuard Home, j’exécute plusieurs tests depuis une machine cliente pour vérifier les trois piliers de ma nouvelle installation :

Je vérifie la résolution locale et le blocage avec nslookup depuis une machine du réseau, en ciblant explicitement le serveur Technitium :

# 1. Test de la résolution externe chiffrée (via Quad9 DoT)
nslookup google.com IP_SERVEUR_TECHNITIUM

# 2. Test de la résolution locale (Zone home.lab)
nslookup dns1.home.lab IP_SERVEUR_TECHNITIUM

# 3. Test du filtrage Sinkhole (Blocage Hagezi PRO++)
nslookup telemetry.microsoft.com IP_SERVEUR_TECHNITIUM

Résultats attendus :

• google.com doit retourner une IP publique valide.
• dns1.home.lab doit retourner l’IP locale de votre serveur Technitium.
• telemetry.microsoft.com doit renvoyer la réponse ** server can't find telemetry.microsoft.com: NXDOMAIN (prouvant que le domaine est bloqué et rejeté par la liste Hagezi).

Les trois tests ayant répondu avec succès en quelques millisecondes, la migration est officiellement terminée ! Pour m’assurer que tous les serveurs et clients utilisent bien Technitium et pour éviter toute interruption de service, je vais laisser mes serveurs Unbound et AdGuard Home actifs en parallèle pendant quelques jours, le temps de vérifier que tout fonctionne correctement. Une fois cette période de test passée, je supprimerai les deux serveurs (Unbound et AdGuard Home).

6. Mettre en place les logs de requêtes (Query Logs)

Par défaut, lorsqu’on se rend dans l’onglet Logs > Query Logs, Technitium affiche un message d’avertissement :

“Missing! Please install the ‘Query Logs (Sqlite)’ DNS App or any other DNS app that supports query logging feature from the Apps section.”

Contrairement à AdGuard Home ou Pi-hole qui intègrent les journaux nativement, Technitium utilise un système d’applications (Apps). Cela permet de garder le cœur du serveur ultra-léger et de choisir le moteur de stockage des logs qui vous convient le mieux (SQLite, PostgreSQL, Microsoft SQL Server, etc.).

Pour un homelab, l’application officielle Query Logs (Sqlite) est le choix idéal.

Installation de l’application Query Logs

1. Je me rends dans le menu Apps.
2. Je clique sur le bouton App Store en haut à droite.
3. Dans la liste des applications disponibles, je cherche Query Logs (Sqlite) et je clique sur Install.
4. L’installation prend quelques secondes et l’application apparaît désormais dans la liste des Installed Apps.

Note sur les performances : L’application SQLite enregistre l’ensemble des requêtes DNS dans une base de données locale. Elle est largement suffisante pour une utilisation domestique ou de petit homelab. Pour des volumes massifs, Technitium propose aussi des extensions vers des bases PostgreSQL ou SQL Server.

Consulter les journaux en direct

Une fois l’application installée, je retourne dans Logs > Query Logs :

1. Je sélectionne la base de données Query Logs (Sqlite) dans le menu déroulant.
2. Je clique sur Query pour lancer la récupération des logs.

Pour voir les logs en direct, il suffit de cocher l’option Live Update.

Il est également possible de filtrer les logs par date, client, protocol, etc. L’exportation des logs est possible au format CSV pour une analyse plus poussée.

Conclusion

En une après-midi, j’ai remplacé deux services par un seul : un unique conteneur LXC, une seule interface, une empreinte mémoire minimale et une maintenance grandement simplifiée.

Grâce à Technitium DNS, ma nouvelle stack réunit le meilleur des deux mondes :

• Les requêtes externes sont chiffrées en DNS-over-TLS vers Quad9, préservant la confidentialité vis-à-vis de mon FAI.
• Le filtrage via la liste Hagezi Multi PRO++ bloque les publicités et le tracking en NXDomain, avec des mises à jour automatiques toutes les 24h.
• La gestion de mes noms de domaines locaux et de la résolution inverse (PTR) est centralisée.
• L’extension Query Logs (SQLite) me donne une visibilité en temps réel sur tout le trafic du réseau.

Après une petite période d’observation en parallèle pour m’assurer que tout tourne sans accrocs, mes conteneurs Unbound et AdGuard Home vont pouvoir définitivement être coupés et supprimés.