Déploiement du serveur DNS interne Technitium

Mise en place d’un serveur DNS récursif et autoritaire en conteneur LXC, et bascule de la distribution DNS des pools DHCP du pare-feu périmétrique.

1. Objet

Cette procédure décrit le déploiement d’un serveur DNS interne Technitium en conteneur LXC sur un cluster de virtualisation, ainsi que son intégration au plan d’adressage existant. Elle couvre l’installation, la configuration des zones directes et inverses, le durcissement de la récursion et la bascule progressive des clients depuis le relais DNS du pare-feu.

L’objectif est de disposer d’une autorité DNS interne unique pour l’ensemble des segments réseau, préalable indispensable à tout déploiement de service nommé, d’infrastructure à clés publiques et d’annuaire.

2. Périmètre et prérequis

Périmètre

Couvert : création du conteneur, installation du moteur DNS, création des zones directe et inverses, configuration du mode récursif, restriction de la récursion par liste de contrôle d’accès, création des politiques de sécurité inter-zones nécessaires, bascule des attributs DHCP du pare-feu.

Non couvert : mise en place d’un serveur secondaire et de la réplication, chiffrement du transport DNS (DoT, DoH, DoQ), listes de blocage, délégation vers un annuaire, supervision.

Prérequis

• Cluster de virtualisation opérationnel, quorum atteint, stockage local déclaré et accessible.
• Modèle de conteneur de la distribution cible présent sur le stockage du nœud d’accueil.
• Pont réseau configuré en mode « VLAN aware », segment du serveur autorisé sur le lien montant de l’équipement de commutation.
• Adresse IP statique réservée hors de la plage distribuée par le serveur DHCP.
• Accès administrateur au pare-feu périmétrique pour la modification des politiques et des attributs DHCP.
• Coffre de secrets disponible pour le stockage du mot de passe d’administration.

Paramètres

Toute valeur spécifique à une installation est déclarée ici. Le corps de la procédure référence les paramètres, jamais les valeurs.

3. Rôles et responsabilités

4. Procédure de déploiement

1. Création du conteneur

Le conteneur est créé en mode non privilégié. L’option d’imbrication est requise pour que le gestionnaire de services fonctionne correctement dans cet environnement.

pct create <CTID> local:vztmpl/<TEMPLATE> \

–hostname <HOSTNAME> \

–cores 1 –memory 1024 –swap 512 \

–rootfs local-lvm:8 \

–net0 name=eth0,bridge=vmbr0,tag=<VLAN_TAG>,ip=<DNS_IP>,gw=<GW> \

–nameserver <GW> \

–unprivileged 1 –features nesting=1 \

–onboot 1 –startup order=2

Le paramètre de résolution pointe temporairement la passerelle : le serveur ne peut pas se résoudre lui-même avant d’être installé.

Vérification : la commande de création se termine sans erreur et le fichier de configuration du conteneur existe.

2. Préparation du système

pct start <CTID>
pct enter <CTID>
apt update && apt full-upgrade -y
apt install -y curl gzip tar ca-certificates

Les utilitaires d’archivage sont des dépendances du script d’installation officiel et ne figurent pas dans le modèle minimal.

Vérification : le port 53 doit être libre avant de poursuivre. La commande suivante ne doit rien retourner.

ss -tulpn | grep ':53'

3. Installation du moteur DNS

L’éditeur fournit un script d’installation qui déploie l’environnement d’exécution applicatif, télécharge le serveur et déclare le service. Le script est téléchargé puis relu avant exécution : un enchaînement direct exécuterait du code non inspecté avec les privilèges les plus élevés.

curl -sSL https://download.technitium.com/dns/install.sh -o /tmp/install.sh

less /tmp/install.sh

bash /tmp/install.sh

Vérification :

systemctl status dns-server
ss -tulpn | grep -E ':53|:5380'

Résultat attendu : service actif, ports 53 en UDP et TCP ainsi que le port de la console web en écoute sur l’adresse du serveur.

4. Accès à la console et changement des identifiants

La console web est accessible sur le port dédié depuis le segment d’administration. Les identifiants par défaut sont documentés publiquement par l’éditeur et doivent être modifiés immédiatement, puis consignés dans le coffre de secrets.

Vérification : la reconnexion avec les anciens identifiants échoue.

5. Création des zones

Trois zones primaires sont créées : la zone directe du domaine interne et les zones inverses correspondant aux segments concernés.

6. Saisie des enregistrements

Les équipements d’infrastructure sont déclarés dans la zone directe. Le nom saisi est relatif à la zone : le serveur complète automatiquement avec le domaine.

L’option de création de l’enregistrement inverse est cochée à chaque saisie.

Vérification : le numéro de série de la zone directe et celui des zones inverses progressent après chaque enregistrement.

5. Intégration réseau

Paramètres réseau du serveur

1. Politiques de sécurité inter-zones

Avant la bascule, chaque segment interrogeait sa propre passerelle : le trafic était traité localement par le pare-feu et ne nécessitait aucune politique. Pointer un serveur situé dans un autre segment transforme ce trafic en flux inter-zones, qui doit être explicitement autorisé.

Un objet d’adressage est créé pour le serveur, puis une politique par zone source.

set security address-book global address <OBJ> <DNS_IP>/32
set security policies from-zone <SRC> to-zone <DST> policy <NOM> match source-address any
set security policies from-zone <SRC> to-zone <DST> policy <NOM> match destination-address <OBJ>
set security policies from-zone <SRC> to-zone <DST> policy <NOM> match application [ <dns-udp> <dns-tcp> ]
set security policies from-zone <SRC> to-zone <DST> policy <NOM> then permit

Vérification : les politiques existantes de la zone source vers la zone de destination sont listées et la nouvelle règle n’est précédée d’aucune règle de refus. L’évaluation s’effectue dans l’ordre de déclaration.

2. Bascule des attributs DHCP

Chaque pool distribue l’adresse du nouveau serveur et le suffixe de recherche. La bascule s’effectue segment par segment, en commençant par un segment sans conséquence opérationnelle et en terminant par le segment d’administration.

delete access address-assignment pool <POOL> family inet dhcp-attributes name-server
set access address-assignment pool <POOL> family inet dhcp-attributes name-server <DNS_IP>
set access address-assignment pool <POOL> family inet dhcp-attributes domain-name <DOMAIN>
show | compare
commit confirmed 5

Vérification : la liste des attributs distribués ne comporte plus qu’une seule adresse de serveur DNS par pool basculé. Côté client, le renouvellement du bail est nécessaire pour appliquer la modification ; les baux en cours ne sont pas affectés.

3. Auto-résolution du serveur

Une fois les zones en place, le serveur se résout par lui-même.

pct set <CTID> --nameserver 127.0.0.1
pct reboot <CTID>

6. Durcissement et sécurité

• Restreindre la récursion par liste de contrôle d’accès explicite. Le mode « réseaux privés » autorise l’ensemble de l’espace d’adressage privé, bien au-delà du périmètre réel de l’installation.
• Ne jamais exposer la récursion à un réseau public : un résolveur ouvert est utilisable comme amplificateur d’attaque par déni de service.
• Limiter l’écoute aux interfaces utiles plutôt qu’à toutes les adresses de l’hôte.
• Exclure de la liste d’accès les segments déclarés isolés. Une politique de pare-feu bloquante ne dispense pas d’une restriction applicative : la défense en profondeur suppose que chaque couche refuse indépendamment.
• Modifier les identifiants par défaut avant toute exposition sur le réseau et consigner le nouveau mot de passe dans le coffre de secrets.
• Exécuter le service sous un compte dédié, conformément au comportement par défaut des versions récentes.
• Conserver le mode récursif direct plutôt qu’un relais vers un résolveur tiers, afin de ne pas rendre la visibilité des résolutions internes à un opérateur externe.
• Restreindre l’accès à la console web au seul segment d’administration.
• Maintenir un instantané antérieur à la configuration et intégrer le conteneur au plan de sauvegarde.

Limites connues

• Serveur unique : toute indisponibilité interrompt la résolution sur l’ensemble des segments basculés. Les équipements restent joignables par adresse IP.
• Le transport chiffré et les listes de blocage ne sont pas traités par cette procédure.
• La délégation vers un annuaire suppose que celui-ci soit déjà déployé ; elle fait l’objet d’une procédure distincte.

Retour arrière

Un instantané est créé avant la phase de configuration.

pct snapshot <CTID> pre-config
pct rollback <CTID> pre-config

Côté pare-feu, l’annulation de la dernière modification validée s’obtient par retour à la version antérieure de la configuration, suivie d’une validation. Côté client, un renouvellement de bail restaure l’attribut précédent.

Pièges rencontrés

7. Vérifications finales

Commandes de contrôle

dig @<DNS_IP> <domaine_public> +short
dig @<DNS_IP> <hote>.<trigramme>.<DOMAIN> +short
dig @<DNS_IP> -x <adresse_interne> +short
dig @<DNS_IP> <domaine_mal_signe>

Le dernier contrôle est le seul qui atteste réellement de la validation cryptographique : le domaine interrogé est délibérément mal signé, un résolveur validant doit refuser de répondre et signaler le motif du rejet.

8. Références et historique des révisions

Documents associés

• HL-PRC-001 — Configuration du pare-feu périmétrique et du plan de segmentation.
• HL-PRC-002 — Configuration de l’équipement de commutation et des liens montants étiquetés.
• HL-PRC-003 — Déploiement du contrôleur de domaine et délégation de la zone d’annuaire.

Documentation éditeur

• Technitium DNS Server — site officiel et instructions d’installation : https://technitium.com/dns/
• Technitium DNS Server — dépôt du projet et notes de version : https://github.com/TechnitiumSoftware/DnsServer
• Proxmox VE — documentation des conteneurs LXC : https://pve.proxmox.com/pve-docs/
• Juniper — documentation Junos relative aux politiques de sécurité et à l’attribution d’adresses.

Historique des révisions

Document interne — diffusion restreinte au périmètre du homelab.