# Déploiement du serveur DNS interne Technitium

- Link: https://dpioch.aristeecampus.org/procedure/configuration-dns/
- Published: 2026-09-22T11:19:11+02:00
- Author: Admin

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

Note

Le serveur déployé ici constitue un point unique de défaillance tant qu’aucun secondaire
n’est mis en place. Cette limite est assumée pour la version initiale et documentée
en section 6.

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

  |  Paramètre |  Description |  Valeur d’exemple |  Contrainte |  
   |  **NODE** |  Nœud d’accueil du conteneur |  pve1 |  Membre du cluster |  
 |  **CTID** |  Identifiant du conteneur |  2011 |  Unique sur le cluster |  
 |  **HOSTNAME** |  Nom court du conteneur |  technitium |  Sans point |  
 |  **FQDN** |  Nom pleinement qualifié |  technitium.srv.dozylab.lan |  Zone = VLAN de gestion |  
 |  **DNS_IP** |  Adresse du serveur DNS |  10.10.20.11/24 |  Statique, hors pool DHCP |  
 |  **GW** |  Passerelle du segment |  10.10.20.254 |  Interface du pare-feu |  
 |  **VLAN_TAG** |  Étiquette 802.1Q |  20 |  Autorisée sur le trunk |  
 |  **DOMAIN** |  Domaine interne |  dozylab.lan |  Zone primaire |  
 |  **ACL_NET** |  Réseaux autorisés à la récursion |  10.10.0.0/16 |  Jamais 0.0.0.0/0 |  
 |  **ADMIN_PW** |  Mot de passe d’administration |  <mot_de_passe> |  Coffre de secrets |

Attention

L’adresse DNS_IP est diffusée à l’ensemble des clients par le serveur DHCP. Toute
modification ultérieure impose une reconfiguration de tous les pools et le renouvellement
des baux.

## 3. Rôles et responsabilités

  |  Rôle |  Responsabilité |  
   |  **Administrateur virtualisation** |  Création du conteneur, allocation des ressources, gestion des instantanés et des sauvegardes. |  
 |  **Administrateur réseau** |  Création des politiques inter-zones, modification des attributs DHCP, vérification du transport des étiquettes VLAN. |  
 |  **Administrateur système** |  Installation du moteur DNS, configuration des zones et des enregistrements, durcissement. |  
 |  **Opérateur** |  Exécution des contrôles de la section 7, remontée des anomalies. |

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

Note

Sur une distribution utilisant un résolveur local intégré, ce service occupe le 
port 53 et doit être désactivé avant l’installation. Le modèle de conteneur standard
ne l’active pas.

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

Attention

À partir de la version 15, le service s’exécute sous un compte dédié et non plus
avec les privilèges les plus élevés. Les fichiers de certificats appartenant au 
compte administrateur deviennent illisibles par le service. Ce point doit être traité
lors de la mise en place du transport chiffré.

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

  |  Zone |  Type |  
   |  **<DOMAIN>** |  Primaire, directe |  
 |  **<X>.<Y>.<Z>.in-addr.arpa** |  Primaire, inverse |  
 |  **<X>.<Y>.<Z>.in-addr.arpa** |  Primaire, inverse (autre segment) |

Attention

Les zones inverses doivent exister avant la saisie des enregistrements de type A.
L’option de création automatique de l’enregistrement inverse est une action ponctuelle:
elle est exécutée à l’enregistrement et n’est pas conservée comme attribut. Sans
zone inverse préalable, elle est sans effet.

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

  |  Nom relatif |  Type |  Valeur |  
   |  **<hote>.<trigramme>** |  A |  <adresse IPv4> |  
 |  **<hote>.<trigramme>** |  A |  <adresse IPv4> |  
 |  **<hote>.<trigramme>** |  A |  <adresse IPv4> |

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

  |  Élément |  Valeur |  
   |  **Interface** |  eth0 |  
 |  **Adresse IP** |  <DNS_IP> |  
 |  **Passerelle** |  <GW> |  
 |  **VLAN** |  <VLAN_TAG> |  
 |  **Pont** |  vmbr0 |  
 |  **Nom DNS** |  <FQDN> |  
 |  **Ports en écoute** |  53/UDP, 53/TCP, console web/TCP |  
 |  **Flux entrants** |  Requêtes DNS depuis les segments autorisés ; console web depuis le segment d’administration |  
 |  **Flux sortants** |  Résolution récursive vers les serveurs racine en 53/UDP et 53/TCP |

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

Note

Le protocole TCP doit être autorisé au même titre que UDP. Les réponses signées 
cryptographiquement dépassent fréquemment la taille maximale d’un datagramme et 
provoquent un repli sur TCP. L’omettre produit des échecs intermittents difficiles
à diagnostiquer.

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
    ```

Attention

La validation temporisée annule automatiquement la modification après le délai indiqué
si elle n’est pas confirmée. Elle protège la configuration de l’équipement, non 
le bail du poste d’administration. Une validation définitive par une seconde commande
est requise.

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>
    ```

Note

Le suffixe de recherche du conteneur doit correspondre à la zone de son propre segment.
Une valeur héritée d’un autre segment n’empêche pas le fonctionnement mais fausse
toute résolution en nom court.

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

Note

La signature cryptographique des zones internes n’apporte rien lorsque le domaine
utilisé n’existe pas dans l’espace de nommage public : aucune chaîne de confiance
ne peut être établie jusqu’à la racine. La validation des réponses reçues, elle,
est assurée par le résolveur récursif et doit être vérifiée par le test prévu en
section 7.

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

  |  Symptôme |  Cause |  Résolution |  
   |  **Le conteneur n’obtient pas de bail ou ne joint pas sa passerelle** |  Étiquette VLAN non autorisée sur le lien montant vers le nœud |  Ajouter le VLAN à la liste des VLAN autorisés du trunk |  
 |  **Enregistrement inverse absent malgré l’option cochée** |  Zone inverse créée après la saisie de l’enregistrement direct |  Rouvrir l’enregistrement en édition et cocher à nouveau l’option |  
 |  **Refus de la configuration à la validation** |  Objet d’adressage référencé mais non déclaré |  Créer l’objet dans le carnet d’adresses avant la politique |  
 |  **Résolution interne fonctionnelle, résolution externe en échec** |  Politique inter-zones absente ou placée après une règle de refus |  Vérifier l’ordre d’évaluation des politiques |  
 |  **Modifications inattendues validées** |  Session de configuration concurrente partageant la configuration candidate |  Utiliser le mode de configuration exclusif |

## 7. Vérifications finales

  |  Contrôle |  Critère d’acceptation |  Statut |  
   |  **Service** |  L’état du service retourne « actif » |  ☐ |  
 |  **Ports** |  Les ports 53 en UDP et TCP et le port de la console sont en écoute sur l’adresse du serveur |  ☐ |  
 |  **Connectivité** |  Le serveur atteint sa passerelle en ICMP sans perte |  ☐ |  
 |  **Récursion** |  Une interrogation sur un domaine public retourne au moins une adresse |  ☐ |  
 |  **Zone directe** |  Une interrogation sur un nom interne retourne l’adresse attendue |  ☐ |  
 |  **Zone inverse** |  Une interrogation inverse sur une adresse interne retourne le nom pleinement qualifié |  ☐ |  
 |  **Validation cryptographique** |  Une interrogation sur un domaine volontairement mal signé retourne une erreur de service et non une réponse |  ☐ |  
 |  **Récursion fermée** |  Une interrogation depuis un réseau hors liste d’accès est refusée |  ☐ |  
 |  **Attributs DHCP** |  Un client renouvelé reçoit l’adresse du serveur et le suffixe de recherche |  ☐ |  
 |  **Persistance** |  Après redémarrage du conteneur, le service est actif et les zones sont présentes |  ☐ |  
 |  **Dimensionnement** |  La consommation mémoire relevée après vingt-quatre heures reste inférieure à l’allocation |  ☐ |

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

  |  Version |  Date |  Auteur |  Modifications |  
   |  **0.1** |  24/08/2026 |  Administrateur |  Création du document. |

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