Installer un DNS interne pour un lab (Debian + Bind9)

Pourquoi mettre en place un DNS interne dans un lab ?

Dans beaucoup de labs, on utilise des adresses IP en dur ou un simple fichier /etc/hosts. Ça fonctionne… jusqu’au jour où :

• le lab grandit,
• plusieurs services communiquent entre eux,
• on veut se rapprocher d’une infrastructure réelle.

Un DNS interne permet notamment de :

• Résoudre des noms de machines sans dépendre d’Internet
• Centraliser la résolution de noms
• Simuler un environnement d’entreprise
• Préparer des scénarios réalistes (AD, messagerie, reverse proxy, supervision…)

Architecture du lab

Hypothèses

• Hyperviseur ou environnement de virtualisation (Proxmox, VirtualBox, VMware…)
• Réseau interne isolé
• Une VM dédiée au DNS

Exemple de plan d’adressage

Machine	Rôle	IP
dns01	Serveur DNS	192.168.100.10
web01	Serveur web	192.168.100.20
client01	Client de test	192.168.100.30

Domaine interne

Dans ce lab, on utilisera le domaine :

lab.local

⚠️ Domaine réservé uniquement au lab (pas utilisé sur Internet)

---

Choix techniques

• OS : Debian 13 (stable, minimal)
• Serveur DNS : Bind9

---

Installation du serveur DNS

Mise à jour du système

bob@debian-dns:~$ sudo apt update && apt upgrade -y

Installation de Bind9

bob@debian-dns:~$ sudo apt install bind9 bind9utils bind9-doc -y
bob@debian-dns:~$ sudo apt install bind9 bind9utils bind9-doc -y
Note : sélection de « bind9-utils » au lieu de « bind9utils »
Installation de :
  bind9  bind9-doc  bind9-utils

Installation de dépendances : 
  dns-root-data
.....
Created symlink '/etc/systemd/system/bind9.service' → '/usr/lib/systemd/system/n
amed.service'.
Created symlink '/etc/systemd/system/multi-user.target.wants/named.service' → '/
usr/lib/systemd/system/named.service'.
Traitement des actions différées (« triggers ») pour man-db (2.13.1-1) ...
bob@debian-dns:~$ 

Vérification du service

bob@debian-dns:~$ systemctl status bind9
● named.service - BIND Domain Name Server
     Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; preset: en>
     Active: active (running) 

Le service doit être actif et démarré.

---

Configuration de Bind9

Fichier principal

Les fichiers de configuration se trouvent dans :

/etc/bind/

Nous allons principalement modifier :

• named.conf.options
• named.conf.local

---

Configuration des options globales

Éditer le fichier :

bob@debian-dns:/etc/bind$ sudo vi named.conf.options

Exemple de configuration simple :

options {

directory "/var/cache/bind";

recursion yes;

allow-recursion { 192.168.100.0/24; };

listen-on { 127.0.0.1; 192.168.100.10; };

allow-query { any; };

forwarders {

1.1.1.1;

8.8.8.8;

};

dnssec-validation auto;

};

---

Explication

1. La récursion (Le rôle de « chercheur »)

recursion yes;

• Cela autorise le serveur à aller chercher lui-même la réponse sur internet si elle n’est pas déjà dans son cache. S’il ne connaît pas google.com, il ira demander aux serveurs racines.

2. Qui peut poser des questions complexes ?

allow-recursion { 192.168.100.0/24; };

• C’est une sécurité cruciale. Vous autorisez seulement les machines de votre réseau local (toutes les adresses commençant par 192.168.100.x) à utiliser votre serveur pour naviguer sur internet.
• Cela empêche des personnes externes d’utiliser votre serveur pour des attaques DNS.

3. Sur quelles « oreilles » le serveur écoute ?

listen-on { 127.0.0.1; 192.168.100.10; };

• Le serveur écoute les requêtes sur deux interfaces uniquement :
  • 127.0.0.1 : Pour lui-même (la machine Debian).
  • 192.168.100.10 : Son adresse IP sur votre réseau local.
• Si une requête arrive sur une autre IP du serveur, elle sera ignorée.

4. Qui peut interroger le serveur ?

allow-query { any; };

• Tout le monde peut poser une question simple (ex: « Quelle est l’IP de ce serveur ? »).
• Note : Comme vous avez limité listen-on et allow-recursion, le « any » n’est pas dangereux ici, il permet simplement de répondre aux requêtes basiques.

5. Les Forwarders (Les relais)

forwarders { 1.1.1.1; 8.8.8.8; };

• Si votre serveur ne connaît pas la réponse, au lieu de chercher tout seul depuis la racine, il demande à des serveurs plus puissants :
  • 1.1.1.1 (Cloudflare)
  • 8.8.8.8 (Google)
• C’est souvent plus rapide que de faire toute la recherche soi-même.

Déclaration de la zone DNS

Ajout de la zone directe

Éditer :

bob@debian-dns:~$ sudo vi /etc/bind/named.conf.local

Ajouter :

//
// Do any local configuration here
//


zone "lab.local" {

type master;

file "/etc/bind/db.lab.local";

};

---

Création du fichier de zone

Créer et ouvrir le fichier :

nano /etc/bind/db.lab.local

Exemple de contenu :

$TTL 604800

@ IN SOA dns01.lab.local. admin.lab.local. (

2026020101

604800

86400

2419200

604800 )

;

@ IN NS dns01.lab.local.

; Serveur DNS

@ IN A 192.168.100.10

dns01 IN A 192.168.100.10

; Serveur web

web01 IN A 192.168.100.20

---

1. Le TTL par défaut

$TTL 604800 C’est la durée de vie par défaut (en secondes) de toutes les informations de ce fichier (ici, 7 jours). Si un autre serveur demande une info, il la gardera en cache pendant une semaine.

---

2. L’enregistrement SOA (Start Of Authority)

C’est la « carte grise » de votre zone. Il définit qui commande ici.

• @ : Symbole raccourci qui désigne le nom de la zone elle-même (lab.local).
• IN SOA : Internet Start Of Authority.
• dns01.lab.local. : Le serveur de noms principal.
• admin.lab.local. : L’adresse email de l’administrateur (le premier point remplace l’arobase : admin@lab.local).

Le bloc entre parenthèses (indispensable pour la synchronisation) :

• 2026020101 (Serial) : Le numéro de version. Crucial : à chaque modification du fichier, vous devez l’augmenter pour que les autres serveurs sachent qu’il y a du nouveau. (Format conseillé : AAAAMMDD + numéro de révision).
• 604800 (Refresh) : Délai avant qu’un serveur esclave ne demande une mise à jour.
• 86400 (Retry) : Délai d’attente en cas d’échec de la mise à jour.
• 2419200 (Expire) : Temps après lequel un esclave arrête de répondre s’il n’arrive plus à joindre le maître.
• 604800 (Minimum) : TTL pour les réponses négatives (NXDOMAIN).

---

3. Les enregistrements NS et A (Le contenu)

Le Serveur de Noms (NS)

@ IN NS dns01.lab.local. Dit au monde : « Pour toute question sur lab.local, le serveur officiel est dns01.lab.local. »

Les adresses IPv4 (A)

• @ IN A 192.168.100.10 : Si quelqu’un tape juste lab.local dans son navigateur, il sera envoyé vers le .10.
• dns01 IN A 192.168.100.10 : Définit l’adresse IP du serveur DNS lui-même. C’est ce qu’on appelle un « Glue Record ».
• web01 IN A 192.168.100.20 : Un enregistrement classique. web01.lab.local pointe vers votre serveur web à l’adresse .20.

Vérification de la configuration

Vérification syntaxique

bob@debian-dns:~$ named-checkconf
bob@debian-dns:~$ 

bob@debian-dns:~$ named-checkzone lab.local /etc/bind/db.lab.local
zone lab.local/IN: loaded serial 2026020101
OK
bob@debian-dns:~$

Redémarrage du service

ob@debian-dns:~$ sudo systemctl restart bind9
bob@debian-dns:~$

---

Configuration des clients

Sur une machine cliente, modifier /etc/resolv.conf (ou via NetworkManager) :

nameserver 192.168.100.10

search lab.local

---

Tests

Test avec dig

dig web01.lab.local
;; ANSWER SECTION:
web01.lab.local.	604800	IN	A	192.168.100.20

Test avec nslookup

nslookup web01.lab.local

La résolution doit retourner l’adresse IP du serveur web.

---

Configuration de la zone reverse (résolution inverse)

La zone reverse permet de résoudre une adresse IP vers un nom de machine. Elle est souvent négligée en lab, mais elle est pourtant essentielle pour :

• certains services (messagerie, supervision, logs),
• le réalisme d’une infrastructure d’entreprise,
• le diagnostic réseau.

Principe

Pour le réseau 192.168.100.0/24, la zone reverse associée est :

100.168.192.in-addr.arpa

Déclaration de la zone reverse

Éditer le fichier :

nano /etc/bind/named.conf.local

Ajouter :

zone "100.168.192.in-addr.arpa" {

type master;

file "/etc/bind/db.192.168.100";

};

Création du fichier de zone reverse

Créer le fichier à partir d’un modèle :

cp /etc/bind/db.127 /etc/bind/db.192.168.100

Éditer le fichier :

bob@debian-dns:~$ sudo vi /etc/bind/db.192.168.100

Exemple de contenu :

$TTL 604800

@ IN SOA dns01.lab.local. admin.lab.local. (

2026020101

604800

86400

2419200

604800 )

;

@ IN NS dns01.lab.local.

10 IN PTR dns01.lab.local.

20 IN PTR web01.lab.local.

Vérification et tests

bob@debian-dns:~$ sudo vi /etc/bind/db.192.168.1
bob@debian-dns:~$ named-checkzone 1.168.192.in-addr.arpa /etc/bind/db.192.168.100
zone 100.168.192.in-addr.arpa/IN: loaded serial 2026020101
OK
bob@debian-dns:~$

bob@debian-dns:~$ systemctl restart bind9

Test depuis un client :

bob@debian-dns:~$ dig -x 192.168.100.20
; ANSWER SECTION:
20.100.168.192.in-addr.arpa. 604800 IN	PTR	web01.lab.local.

La commande doit retourner le nom web01.lab.local.

Bonus

Supprimer le cache d’un serveur DNS

bob@debian-dns:~$ sudo rndc flush
bob@debian-dns:~$ 

Erreurs courantes

• Numéro de série SOA non incrémenté
• Erreur de syntaxe dans le fichier de zone
• Mauvaise IP d’écoute (listen-on)
• Firewall bloquant le port 53 (UDP/TCP)

---

Conclusion

Mettre en place un DNS interne est une brique essentielle dans tout lab sérieux. A toi de jouer.