Lessons / Lesson 3: Service de résolution des noms, DNS

Objectifs du chapitre

• Comprendre le principe de résolution des noms de domaine (DNS).
• Expliquer la notion de serveur autoritaire, de serveur secondaire et de cache DNS.
• Mettre en place un serveur de résolution des noms primaire (maître) avec Bind9.
• Déployer un serveur secondaire (esclave) et assurer la réplication de zone via transfert AXFR.
• Établir l’intégration avec le service web et/ou le service de messagerie.
• Tester la continuité de service (failover) en cas de panne du serveur maître.

1. Principe de résolution des noms

Internet est un grand réseau composé de très nombreux ordinateurs. Pour qu’ils puissent se retrouver et communiquer entre eux, ils sont identifiés par une adresse IP. Pour faciliter l’accès à un hôte sur le réseau IP, un mécanisme a été mis en place pour associer un nom à une adresse IP : le DNS (Domain Name System).

Le DNS est un système de dénomination hiérarchique et décentralisé pour les ordinateurs, services ou autres ressources connectés à Internet ou à un réseau privé, qui établit une correspondance entre un nom de domaine (www.esprit.tn) et une adresse IP (192.168.1.10), dans les deux sens (résolution de nom, résolution inverse).

Le DNS n’est pas bijectif :

• un même nom de domaine peut répondre par plusieurs adresses IP différentes (répartition de charge, haute disponibilité) ;
• plusieurs noms de domaine (www.esprit.tn, mail.esprit.tn, ftp.esprit.tn) peuvent pointer vers la même machine physique.

2. Hiérarchie du DNS

Le DNS est organisé sous forme d’un arbre renversé :

• la racine constitue le sommet de l’arbre, représentée par un point . ;
• les nœuds représentent des domaines, chacun identifié par un label.

"."                               domaine racine
├── fr                            domaine de premier niveau (TLD)
├── tn                            domaine de premier niveau (TLD)
│   └── esprit                    domaine de second niveau (SLD)
│       ├── www                   sous-domaine (hôte)
│       └── ftp                   sous-domaine (hôte)
└── com                           domaine de premier niveau (TLD)

Le nom de domaine est une suite de labels successifs séparés par un point. Le FQDN (Fully Qualified Domain Name, nom d’hôte pleinement qualifié) donne la position exacte de son nœud dans l’arborescence DNS en indiquant tous les domaines de niveau supérieur : www.esprit.tn.

Domaine et zone DNS

• Domaine : l’ensemble d’une sous-arborescence à partir d’un nœud donné.
• Zone DNS : une partie de l’espace de noms de domaine gérée par un administrateur spécifique, constituée de la base de données décrivant un nœud. Son rôle est de simplifier l’administration des domaines (par exemple la zone « esprit.tn » sous le domaine « tn »).

3. Architecture DNS

Types de serveurs DNS

Résolution d’un nom : étapes

Lorsqu’un client souhaite résoudre www.esprit.tn en adresse IP :

1. L’utilisateur envoie une requête récursive au serveur de noms (cache) pour résoudre le nom de domaine.
2. Le serveur envoie une requête à l’un des serveurs racines.
3. Le serveur racine lui indique les serveurs de noms de domaine de premier niveau.
4. Le serveur de nom local interroge le serveur de nom de domaine de premier niveau pour résoudre le nom.
5. Le serveur de premier niveau renseigne le serveur local sur d’autres serveurs de domaine de second niveau.
6. Le serveur de nom local envoie une requête au serveur de domaine de second niveau.
7. Le serveur de domaine de second niveau répond avec autorité en envoyant l’adresse IP correspondante.
8. Le serveur de nom local transfère la réponse au poste client.
9. Le client communique avec le serveur web directement grâce à son adresse IP, via HTTP sur le port 80.
10. Le serveur web répond à la demande du client.

Résolution inverse

Trouver le nom d’une machine à partir d’une adresse IP, selon le même principe que pour les noms. L’arborescence se trouve sous le domaine in-addr.arpa (IPv4) ou ip6.arpa (IPv6) : chaque octet de l’adresse IP est vu comme un sous-domaine. Par exemple, pour l’adresse 192.168.1.1, la résolution inverse interroge la zone in-addr.arpa pour trouver le nom de domaine associé.

Mode récursif et mode itératif

• Mode récursif : si le serveur n’a pas de réponse, il demande au serveur racine ou fait suivre la requête pour donner une réponse complète à l’utilisateur (cas d’un serveur cache).
• Mode itératif : les serveurs répondent directement à la requête sur la seule base de leurs informations locales.

4. Types d’enregistrements DNS

5. De la zone au Master/Slave

Pourquoi répliquer une zone ? Une zone est une partie de l’espace de noms, décrite par un fichier de zone, sur laquelle un seul serveur fait autorité. Si ce serveur tombe, les noms de la zone ne sont plus résolus (point de défaillance unique). Solution : servir la même zone sur plusieurs serveurs, un master qui détient la zone d’origine et un ou plusieurs slaves qui en reçoivent une copie synchronisée.

Transfert de zone AXFR

Mécanisme par lequel un serveur DNS secondaire (slave) récupère une copie complète d’une zone depuis le serveur maître (master), qui seul détient l’autorité et permet les modifications. Le slave interroge périodiquement le master et sert ensuite la zone en lecture seule aux clients DNS. Objectif : redondance, si le master tombe, le slave continue de répondre grâce à la dernière copie reçue. Le slave se base sur le numéro de série SOA pour savoir s’il doit redemander un transfert.

Configuration côté master

Autoriser le transfert de zone vers le slave : ouvrir la configuration locale de la zone et ajouter la directive allow-transfer pointant vers l’IP du slave.

zone "esprit1.com" IN {
    type master;
    file "/etc/bind/zones/esprit1.com";
    allow-transfer { 192.168.1.102; };
};

sudo gedit /etc/bind/named.conf.local
sudo named-checkconf
sudo systemctl restart named

Configuration côté slave et vérification

Une deuxième instance BIND9, dédiée à l’IP alias :

# named.conf (slave)
options {
    directory "/var/cache/bind-slave";
    listen-on { 192.168.1.102; };
};

zone "esprit1.com" IN {
    type slave;
    masters { 192.168.1.100; };
    file "esprit1.com.slave";
};

# 1. créer l'arborescence
mkdir -p /etc/bind-slave /var/cache/bind-slave

# 2. vérifier la syntaxe
named-checkconf /etc/bind-slave/named.conf

# 3. démarrer la 2e instance
named -c /etc/bind-slave/named.conf -u bind

# vérification
sudo ls -l /var/cache/bind-slave/
dig www.esprit1.com @192.168.1.102
sudo journalctl -u named-slave -n 50

Test de bascule (failover)

# 1. vérifier que le master et le slave répondent tous les deux normalement
dig www.esprit1.com @192.168.1.100
dig www.esprit1.com @192.168.1.102
# → ANSWER SECTION identique sur les deux serveurs

# 2. simuler la panne du serveur maître
sudo systemctl stop named

# 3. tester la résolution côté client pendant la panne
resolvectl flush-caches && nslookup www.esprit1.com

# 4. restaurer le serveur maître
sudo systemctl start named

Prérequis : le slave ne peut répondre pendant la panne que s’il a déjà reçu une copie de la zone via AXFR avant l’arrêt du master.