Refonte complète de mon infrastructure DNS avec Technitium et AdGuard Home en haute disponibilité

Un setup DNS sans redondance ni zone locale, c'est un SPOF qui s'ignore. Découvrez comment refondre son infrastructure DNS en haute disponibilité avec Technitium, AdGuard Home et Proxmox HA.

Refonte complète de mon infrastructure DNS avec Technitium et AdGuard Home en haute disponibilité

Mon DNS homelab tenait sur un seul LXC. AdGuard Home cohabitait avec NPM dans le même conteneur, sans redondance, sans zone locale. Une panne du nœud Proxmox pve1 et tout tombait avec lui, même si le nœud pve2 était en parfaite santé.

Ce setup avait un autre défaut moins visible : depuis le LAN, la résolution de mon domaine perso *.domain.tld déclenchait une requête vers les DNS publics, qui retournaient l'IP publique de la Freebox. Le trafic sortait du réseau, revenait en port forwarding, pour finir sur NPM qui tourne pourtant à côté. Du "hairpin" (réflexion NAT) inutile, à chaque requête, pour chaque service que j'héberge et utilise depuis chez moi.

Pas de zone DNS locale donc, pas de résilience, et pas de séparation des rôles. AdGuard Home et NPM dans le même conteneur LXC, c'est pratique jusqu'au moment où on veut les gérer indépendamment ou en mettre un en HA Proxmox sans l'autre. Hors réseau, le filtrage AdGuard Home disparaissait aussi sur mobile, puisque tout reposait sur l’instance locale.

Bref, 3 bonnes raisons de tout refaire proprement.


Les outils retenus

Pour adresser les 3 problèmes d'un coup, j'ai retenu une architecture à 4 composants aux responsabilités bien séparées : plus de SPOF, plus de hairpin, et un filtrage cohérent en local comme hors réseau.

Technitium DNS Server est un serveur DNS open source complet : autoritaire, récursif, et relais. Il gère les zones primaires/secondaires avec synchronisation native entre instances, ce qui rend le HA DNS possible sans Proxmox HA. Les 2 nœuds se synchroniseront automatiquement, l'UCG Fiber distribuera les 2 IPs en DHCP, et si pve1 tombe les clients continueront de résoudre via pve2 immédiatement.

GitHub - TechnitiumSoftware/DnsServer: Technitium DNS Server
Technitium DNS Server. Contribute to TechnitiumSoftware/DnsServer development by creating an account on GitHub.

AdGuard Home est excellent pour le filtrage mais c'est un relais DNS et résolveur, pas un serveur autoritaire. Il ne peut pas gérer une zone primaire/secondaire, d'où Technitium. Mais AdGuard Home apporte ce que Technitium n'a pas : règles par client ou par groupe, listes de blocage différentes par client, blocage simplifié de services. Les 2 instances Technitium lui délégueront toutes les requêtes hors zone locale, avec un seul point de gestion pour le filtrage. Il tournera dans un LXC dédié sur NFS, géré par Proxmox HA.

GitHub - AdguardTeam/AdGuardHome: Network-wide ads & trackers blocking DNS server
Network-wide ads & trackers blocking DNS server. Contribute to AdguardTeam/AdGuardHome development by creating an account on GitHub.

NextDNS est le résolveur DNS en amont, chiffré en DoT. AdGuard Home lui transfèrera toutes les requêtes publiques. Il apporte surtout ce qu'AdGuard Home ne peut pas faire seul : une base de détection des menaces mise à jour en continu et un filtrage actif sur mobile hors réseau. Il servira aussi de fallback sur pve2 si AdGuard Home est temporairement indisponible pendant une migration Proxmox HA.

NextDNS
The new firewall for the modern Internet

NPM tournera dans son propre LXC sur NFS, lui aussi géré par Proxmox HA. Le split DNS pointe *.domain.tld sur son IP LAN. Depuis internet, les DNS publics retournent l'IP fixe de la Freebox qui redirige vers NPM, même URL mais 2 chemins différents selon que la requête vient du LAN ou d’internet.

GitHub - NginxProxyManager/nginx-proxy-manager: Docker container for managing Nginx proxy hosts with a simple, powerful interface
Docker container for managing Nginx proxy hosts with a simple, powerful interface - NginxProxyManager/nginx-proxy-manager

Vauxtra sera déployé dans le même LXC que NPM et servira d'interface centralisée pour piloter l'ensemble de la stack : NPM, AdGuard Home, Technitium et les entrées DNS depuis un seul endroit.

GitHub - ptitzgeg-on-git/vauxtra
Contribute to ptitzgeg-on-git/vauxtra development by creating an account on GitHub.

Voici un schéma qui représente l'existant à gauche et la cible à droite :


Installation et configuration

Prérequis

Un stockage NFS ou iSCSI doit être monté et accessible sur les 2 nœuds Proxmox. C'est indispensable pour mettre en place le HA Proxmox : les LXC gérés par HA doivent être sur un stockage partagé entre pve1 et pve2. Dans cet article, le datastore s'appelle nas-proxmox.

Le HA Proxmox nécessite également un quorum stable. Avec 2 nœuds, un QDevice tiers est indispensable, dans ce setup il tourne sur le Synology NAS.

Télécharger le dernier template Debian 13 depuis Proxmox : Datacenter > pve1 > nas-proxmox > CT Templates > Templates > chercher Debian 13 > Download. Vérifier le nom exact du fichier téléchargé et l'adapter dans les commandes ci-dessous si la version ne correspond plus.

Voici le plan d'adressage utilisé dans cet article :

LXC IP Nœud
lxc-adguard 192.168.10.9 pve1 (HA → pve2)
lxc-npm 192.168.10.10 pve1 (HA → pve2)
lxc-dns1 192.168.10.2 pve1 (fixe)
lxc-dns2 192.168.10.3 pve2 (fixe)

La création des LXC peut se faire via l'interface Proxmox ou via le shell directement sur chaque nœud. J'ai opté pour le shell par rapidité, vu le nombre de conteneurs LXC à créer.


AdGuard Home

Créer le LXC

AdGuard Home tournera sur le datastore NFS nas-proxmox. C'est une condition nécessaire pour Proxmox HA : le LXC doit être accessible depuis les 2 nœuds pour pouvoir être migré automatiquement en cas de panne.

Depuis le shell de pve1 :

pct create 110 nas-proxmox:vztmpl/debian-13-standard_13.1-2_amd64.tar.zst \
  --hostname lxc-adguard \
  --cores 1 \
  --memory 1024 \
  --swap 512 \
  --net0 name=eth0,bridge=vmbr0,ip=192.168.10.9/24,gw=192.168.10.1 \
  --storage nas-proxmox \
  --rootfs nas-proxmox:4 \
  --features nesting=1 \
  --unprivileged 1 \
  --password VotreMotDePasse \
  --start 1

Adaptez l'ID du conteneur, le datastore NFS, le nom du template, le hostname et l'IP.

Installer AdGuard Home

Se connecter au LXC lxc-adguard via la console Proxmox.

apt update && apt install -y curl
curl -sSL https://static.adguard.com/adguardhome/release/AdGuardHome_linux_amd64.tar.gz | tar xz
./AdGuardHome/AdGuardHome -s install

L'interface de premier accès est accessible sur le port 3000 pour la configuration initiale, puis sur le port 80 ensuite.

Configurer AdGuard Home

  1. Paramètres > DNS > Serveurs DNS en amont : tls://[ID].dns.nextdns.io
  2. Filtres > Listes de blocage DNS > ajouter les listes souhaitées (StevenBlack hosts, AdGuard DNS Filter, Hagezi Pro)
  3. Filtres > Services bloqués > configurer le blocage des services

Technitium DNS

Créer les LXC Technitium

Technitium tourne en actif/actif sur local-lvm, avec une instance dédiée sur chaque nœud, pas besoin de stockage NFS.

Depuis le shell de pve1 pour le premier nœud :

pct create 120 nas-proxmox:vztmpl/debian-13-standard_13.1-2_amd64.tar.zst \
  --hostname lxc-dns1 \
  --cores 1 \
  --memory 1024 \
  --swap 512 \
  --net0 name=eth0,bridge=vmbr0,ip=192.168.10.2/24,gw=192.168.10.1 \
  --storage local-lvm \
  --rootfs local-lvm:4 \
  --features nesting=1 \
  --unprivileged 1 \
  --password VotreMotDePasse \
  --start 1

Répéter sur pve2 en adaptant l'ID du conteneur, le datastore NFS, le nom du template, le hostname et l'IP.

Installer Technitium

Se connecter à lxc-dns1 via la console Proxmox puis répéter sur lxc-dns2.

apt update && apt install -y curl
curl -sSL https://download.technitium.com/dns/install.sh | bash

Une fois installé, l'interface web est accessible sur le port 5380 pour chacune des instances.

Configurer Technitium pve1

  1. Settings > Forwarders : ajouter 192.168.10.9, protocole DNS-over-UDP. AdGuard Home est sur le LAN, le chiffrement se fait entre AdGuard Home et NextDNS.
  2. Settings > Blocking : décocher "Enable Blocking". Technitium applique un filtrage par défaut même sans liste configurée, ce qui peut interférer avec certaines applications. Le filtrage est entièrement délégué à AdGuard Home.
  3. Settings > DNSSEC : décocher "Enable DNSSEC Validation". Quand AdGuard Home bloque un domaine et retourne 0.0.0.0, la réponse n'a pas de signature DNSSEC. Technitium interprète ça comme une attaque et retourne SERVFAIL. NextDNS gère le DNSSEC en aval. Désactiver la validation DNSSEC côté Technitium n’est pas un problème ici, puisque la validation reste effectuée par NextDNS en amont.
  4. Zones > Add Zone : type Primary Zone, nom domain.tld. Ajouter 2 enregistrements A, @ et *, pointant sur 192.168.10.10 (NPM). Le wildcard couvre automatiquement tous les sous-domaines.
  5. Zones > domain.tld > Zone Options > Zone Transfer : sélectionner "Use Specified Network Access Control List", autoriser 192.168.10.3.
  6. Onglet Notify : sélectionner "Specified Name Servers", renseigner 192.168.10.3. La propagation est quasi instantanée.

Configurer Technitium pve2

  1. Settings > Forwarders : ajouter 192.168.10.9 et [ID].dns.nextdns.io, protocole DNS-over-TLS pour les 2. Activer Concurrent Forwarding : Technitium interroge les 2 en parallèle et utilise la première réponse valide. Si AdGuard Home est en cours de migration HA, NextDNS prend le relais sans délai.
  2. Settings > Blocking : décocher "Enable Blocking", pour les mêmes raisons que pve1.
  3. Settings > DNSSEC : décocher "Enable DNSSEC Validation".
  4. Zones > Add Zone : type Secondary Zone, Primary Server 192.168.10.2. Technitium effectue immédiatement un transfert de zone complet et se synchronise ensuite de façon incrémentale.

Technitium propose également une fonctionnalité de cluster natif qui synchronise l'intégralité de la configuration entre les instances, forwarders et paramètres inclus. C'est la solution idéale sur le papier, mais elle repose sur DANE-EE pour l'authentification entre nœuds, ce qui nécessite un nom de domaine résolvable ainsi qu'un accès HTTPS sur chaque instance. En environnement LAN sans DNS public, la mise en place devient complexe. Pour ce homelab, la configuration manuelle des 2 instances reste la solution la plus simple.


Finalisation

Bascule DHCP

Dans UniFi, répéter pour chaque réseau et VLAN :

  1. Settings > Networks > [réseau] > DHCP > DNS Servers
  2. DNS Server 1 : 192.168.10.2, DNS Server 2 : 192.168.10.3

Patienter le renouvellement des baux DHCP pour que les clients reçoivent les nouveaux serveurs DNS.

Les clients configurés manuellement devront évidemment être adaptés aussi.

Migrer NPM vers NFS

NPM tourne actuellement sur le stockage local-lvm. Pour mettre en place le HA Proxmox, le LXC doit être sur un stockage NFS accessible depuis les 2 nœuds. Il faut donc migrer son volume vers nas-proxmox.

Depuis l'interface Proxmox :

  1. Sélectionner le LXC > bouton Shutdown
  2. Resources > Root Disk > Volume Action > Move Storage
  3. Sélectionner nas-proxmox > cocher Delete source > confirmer

L'IP, la config et les données sont préservées, seul l'emplacement du stockage change.

Activer Proxmox HA

Une fois les LXC AdGuard Home et NPM sur NFS, les ajouter en ressources HA depuis l'interface Proxmox :

Datacenter > HA > Resources > Add

Champ Valeur
VM/CT ID ID du LXC
State started
Max Restart 3
Max Relocate 1
Failback activé

Répéter pour chaque LXC (AdGuard Home et NPM).

Ensuite définir la préférence de nœud dans Datacenter > HA > Affinity Rules > Add, pve1 à 100 et pve2 à 50. Le LXC reviendra automatiquement sur pve1 au retour du nœud.


Validation

Une fois l’installation terminée et la configuration DNS basculée dans le DHCP, voici les tests à réaliser pour valider l'ensemble de la chaîne. L’objectif est de valider à la fois le split DNS, le filtrage, et les mécanismes de bascule.

Résolution interne depuis le LAN, doit retourner l'IP de lxc-npm :

nslookup syno.domain.tld 192.168.10.2
# → 192.168.10.10

Résolution externe :

nslookup google.com 192.168.10.2
# → IP publique via AdGuard Home → NextDNS DoT

Vérification du blocage par AdGuard Home, doit retourner 0.0.0.0 :

nslookup doubleclick.net 192.168.10.2
# → 0.0.0.0

Test HA DNS : arrêt de Technitium sur pve1, la résolution doit continuer immédiatement via pve2 :

pct exec 120 -- systemctl stop dns
nslookup syno.domain.tld
# → 192.168.10.10 via pve2 immédiatement

Test fallback NextDNS : arrêt d'AdGuard Home, la résolution doit continuer via NextDNS DoT :

pct exec 110 -- systemctl stop AdGuardHome
nslookup google.com
# → résolution continue via NextDNS DoT

Vauxtra

Vauxtra est un outil open source développé par un membre de la communauté DomoPi, qui sert d'interface de contrôle centralisée pour gérer vos reverse proxy et entrées DNS depuis un seul endroit. C'est un orchestrateur : il ne remplace pas les outils en place, il les pilote. Cette refonte DNS était l'occasion idéale de le mettre en place et de le tester concrètement.

Les fonctionnalités qui m'ont convaincu : la détection automatique des écarts entre la configuration attendue et l'état réel des fournisseurs, le mode simulation pour prévisualiser les changements avant de les appliquer, la découverte automatique des conteneurs Docker, et les notifications par webhook via Apprise pour les événements.

Il prend en charge NPM, Traefik, AdGuard Home, Pi-hole, Technitium, Cloudflare DNS et Cloudflare Tunnel. Il tourne en Docker dans le même LXC que NPM et embarque également un serveur MCP pour le piloter depuis Claude Desktop en langage naturel.

Voici quelques captures d'écran du guide de configuration initiale pour vous en donner un aperçu :


Conclusion

L'infrastructure DNS est maintenant résiliente de bout en bout. Plus de SPOF, plus de hairpin, un filtrage cohérent sur tous les clients y compris hors réseau. Technitium gère le split DNS et la synchronisation DNS entre les 2 nœuds, AdGuard Home centralise le filtrage avec toute la granularité nécessaire, Proxmox HA assure la bascule automatique des services critiques, et Vauxtra orchestre le tout depuis une interface unique.

Des questions ou des retours sur cette architecture ? C'est en commentaire ou sur le groupe Telegram.