🌍 DNS — BIND9 et zones

🚀 Introduction (10 min)

La panne DYN du 21 octobre 2016 reste un cas d'école : un volumineux DDoS piloté par le botnet Mirai a saturé l'infrastructure DNS d'un fournisseur majeur et rendu tout un panel de services (Twitter, Netflix, Spotify…) inaccessibles pendant plusieurs heures. Cet incident illustre la dépendance critique des services en ligne au bon fonctionnement des serveurs DNS et l'importance de concevoir des résiliences (redondance, anycast, répartitions, caches locaux) dans une PME.

Dans le contexte d'InnovatTech, l'objectif est d'appréhender comment fonctionne la résolution DNS et comment déployer un service DNS interne (BIND9) fiable et testable.

🎯 Objectifs de la séance

• Expliquer la différence entre résolution récursive et itérative et décrire la hiérarchie root → TLD → authoritative.
• Configurer une zone DNS primaire sous BIND9 (named.conf, fichier de zone : SOA/NS/A/AAAA/CNAME/MX/PTR/SRV) et sa zone reverse.
• Diagnostiquer les problèmes de résolution DNS à l'aide d'outils (dig, nslookup, host, resolvectl) et interpréter leurs sorties.

📖 1. Résolution DNS : récursive vs itérative et hiérarchie (60 min)

Le DNS est un système réparti qui transforme des noms lisibles (ex : nas01.innovattech.local) en adresses IP. La résolution peut être effectuée de façon itérative ou récursive selon le rôle de l'interrogateur :

• Un client stub envoie une requête à un résolveur récursif (souvent fourni par le FAI ou un serveur local) et lui demande de lui rendre la réponse complète.
• Le résolveur récursif, lui, peut effectuer des requêtes itératives auprès des différents serveurs de la hiérarchie (root → TLD → authoritative) pour remonter jusqu'à l'autorité de la zone demandée.
• En pratique, pour les environnements d'entreprise, on installe un serveur récursif local (cache) qui répond aux clients et délègue les requêtes qu'il ne connaît pas vers des forwarders ou vers la racine.

Un échange typique se décompose ainsi : le client contacte le récursif ; si la réponse n'est pas en cache, le récursif interroge d'abord un root server, celui-ci renvoie l'adresse des serveurs responsables du TLD (.com, .net, .fr…), puis le résolveur interroge le serveur du TLD qui renvoie l'autorité finale, et ainsi de suite jusqu'au serveur faisant autorité pour le nom demandé.

Diagramme du flux de résolution

Client (stub) ──→ Résolveur récursif (cache local)
                          │
                     Root servers
                          │
                        TLD
                          │
                  Authoritative (innovattech.local)

Interroger un serveur DNS précis

Exemple de commande pour interroger le serveur DNS Windows DC win-srv01 :

# Interroger le serveur DNS situé à 192.168.10.5 pour l'enregistrement A de la racine de la zone
dig @192.168.10.5 innovattech.local A +short

Sortie attendue :

192.168.10.10

📖 2. Zones DNS, types d'enregistrements et BIND9 (70 min)

Une "zone" DNS est la portion de l'espace de noms pour laquelle un serveur est responsable. Il existe plusieurs modes de zone :

Enregistrements courants d'une zone

Configuration de BIND9

Exemple minimal du bloc options dans /etc/bind/named.conf.options :

options {
    recursion yes;
    allow-recursion { 192.168.0.0/16; };
    forwarders { 8.8.8.8; };
    dnssec-validation auto;
    listen-on { any; };
};

Déclaration des zones dans /etc/bind/named.conf.local :

zone "innovattech.local" IN {
    type master;
    file "/etc/bind/db.innovattech.local";
};

zone "10.168.192.in-addr.arpa" IN {
    type master;
    file "/etc/bind/db.10.168.192";
};

Fichier de zone forward

Exemple de /etc/bind/db.innovattech.local :

$TTL 3600
@   IN  SOA ns1.innovattech.local. admin.innovattech.local. (
        2026022001 ; serial YYYYMMDDNN
        3600       ; refresh
        600        ; retry
        604800     ; expire
        3600 )     ; minimum TTL

@   IN  NS  ns1.innovattech.local.
@   IN  A   192.168.10.10    ; enregistrement A pour la zone apex
ns1 IN  A   192.168.10.10
win-srv01     IN  A   192.168.10.5
debian-srv02  IN  A   192.168.30.5
proxmox01     IN  A   192.168.10.20
nas01         IN  A   192.168.10.15
mail          IN  A   192.168.30.5
www           IN  CNAME  debian-srv02.innovattech.local.
@             IN  MX 10 mail.innovattech.local.

Fichier de zone reverse

Exemple de /etc/bind/db.10.168.192 pour 192.168.10.0/24 :

$TTL 3600
@   IN  SOA ns1.innovattech.local. admin.innovattech.local. (
        2026022001 ; serial
        3600
        600
        604800
        3600 )

@   IN  NS ns1.innovattech.local.
5   IN  PTR win-srv01.innovattech.local.
10  IN  PTR ns1.innovattech.local.
15  IN  PTR nas01.innovattech.local.
20  IN  PTR proxmox01.innovattech.local.
30  IN  PTR debian-srv01.innovattech.local.

Les enregistrements PTR dans la zone reverse correspondent au dernier octet des adresses IPv4 (ex : 15 IN PTR correspond à 192.168.10.15).

Administration DNS Windows (PowerShell)

Les serveurs DNS Windows peuvent stocker des zones intégrées à Active Directory, bénéficiant de la réplication AD et d'un contrôle d'accès centralisé. Administration via PowerShell :

# Lister les zones DNS sur win-srv01
Get-DnsServerZone -ComputerName win-srv01

# Activer le scavenging pour nettoyer les enregistrements dynamiques obsolètes
Set-DnsServerScavenging -RefreshInterval 7.00:00:00 -NoRefreshInterval 7.00:00:00 -ComputerName win-srv01

# Créer un conditional forwarder vers 8.8.8.8 pour les requêtes non locales
Add-DnsServerConditionalForwarderZone -Name "example.com" -MasterServers 8.8.8.8 -ReplicationScope "Domain"

Diagnostics et commandes pratiques

# Interroger un serveur précis à la recherche d'un enregistrement A
dig @192.168.10.10 nas01.innovattech.local A +short

# Obtenir les enregistrements MX avec nslookup
nslookup -type=MX innovattech.local 192.168.10.10

# Interroger les NS d'une zone
host -t NS innovattech.local 192.168.10.10

# Avec systemd-resolved sur une machine Linux (ex: debian-srv01)
resolvectl query nas01.innovattech.local

Lecture des sorties dig

# Résolution directe
$ dig @192.168.10.10 nas01.innovattech.local A +short
192.168.10.15

# Résolution inverse (reverse DNS)
$ dig @192.168.10.10 -x 192.168.10.15 +short
nas01.innovattech.local.

Si dig renvoie l'adresse attendue, la résolution directe fonctionne. Pour le reverse, la sortie doit pointer vers le FQDN avec le point final.

🔬 Travaux Pratiques (80–90 min)

Objectif

Déployer une zone DNS primaire sous BIND9 contenant tous les enregistrements A et PTR nécessaires pour les serveurs d'InnovatTech et valider la résolution depuis win-srv01 et les autres serveurs.

Prérequis techniques

• Accès sudo sur debian-srv01 (Debian 12).
• Paquets BIND9 installés (bind9, bind9utils).
• Adresses IP des serveurs : win-srv01=192.168.10.5, debian-srv01=192.168.10.10, debian-srv02=192.168.30.5, proxmox01=192.168.10.20, nas01=192.168.10.15.

Étape 1 — Installation et préparation

# Sur debian-srv01
sudo apt update && sudo apt install -y bind9 bind9utils bind9-doc
sudo systemctl enable --now bind9

# Vérifier l'état
sudo systemctl status bind9 --no-pager

Étape 2 — Modifier les options globales

Éditez /etc/bind/named.conf.options et ajoutez / vérifiez les options suivantes :

options {
    directory "/var/cache/bind";
    recursion yes;
    allow-recursion { 192.168.0.0/16; };
    forwarders { 8.8.8.8; };
    dnssec-validation auto;
    auth-nxdomain no;    # conform RFC
    listen-on { any; };
};

Étape 3 — Déclarer les zones

Éditez /etc/bind/named.conf.local et ajoutez :

zone "innovattech.local" IN {
    type master;
    file "/etc/bind/db.innovattech.local";
};

zone "10.168.192.in-addr.arpa" IN {
    type master;
    file "/etc/bind/db.10.168.192";
};

Étape 4 — Créer les fichiers de zone

Créez /etc/bind/db.innovattech.local et /etc/bind/db.10.168.192 avec le contenu présenté en section 2 (respectez le serial). Exemple de départ :

sudo cp /etc/bind/db.empty /etc/bind/db.innovattech.local
# puis éditez avec votre éditeur préféré (nano / vi)

Étape 5 — Vérifier la syntaxe et charger les zones

sudo named-checkconf
sudo named-checkzone innovattech.local /etc/bind/db.innovattech.local
sudo named-checkzone 10.168.192.in-addr.arpa /etc/bind/db.10.168.192
sudo systemctl reload bind9

Sortie attendue de named-checkzone :

zone innovattech.local/IN: loaded serial 2026022001
OK

Étape 6 — Diagnostics depuis les autres serveurs

Depuis win-srv01 (ou toute autre machine) :

nslookup nas01.innovattech.local 192.168.10.10

Depuis debian-srv02 :

dig @192.168.10.10 nas01.innovattech.local A +short
dig @192.168.10.10 -x 192.168.10.15 +short

Étape 7 — Résolution des problèmes courants

• Si named ne démarre pas : consulter les logs avec sudo journalctl -u bind9 -n 200 pour identifier les messages d'erreur sur la syntaxe des fichiers de zone.
• Vérifier que le serial a été correctement incrémenté après modification ; sinon les esclaves ne reprendront pas les nouvelles données.

Livrable attendu

• Les fichiers /etc/bind/db.innovattech.local et /etc/bind/db.10.168.192 présents sur debian-srv01 avec un serial à jour.
• Un court rapport (1 page) listant les commandes de vérification lancées et les sorties clés (dig/nslookup) montrant la résolution directe et inverse depuis au moins deux machines différentes (win-srv01 et debian-srv02).

Critères de réussite

✅ Synthèse (10 min)

Cette séance a montré que le DNS est une chaîne d'autorités : un client demande à un résolveur récursif qui parcourt la hiérarchie root → TLD → authoritative si nécessaire. Nous avons vu la différence fondamentale entre :

• Requêtes récursives — le résolveur rend la réponse finale au client.
• Requêtes itératives — chaque serveur donne des pointeurs vers d'autres serveurs jusqu'à l'authoritative.

Nous avons aussi vu comment structurer des zones DNS avec les enregistrements SOA/NS/A/CNAME/MX/PTR et comment gérer concrètement des fichiers de zone BIND9, les vérifications syntaxiques (named-checkconf, named-checkzone) et les commandes de diagnostic (dig / nslookup / host / resolvectl) indispensables en production.

📝 QCM — Testez vos connaissances