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

1. Le poste envoie une requête récursive à son serveur cache : « donne-moi la réponse complète ».
2. Le cache interroge un serveur racine, qui renvoie les serveurs du TLD tn.
3. Le cache interroge le serveur de tn, qui renvoie les serveurs de esprit.tn.
4. Le cache interroge le serveur de esprit.tn, qui répond avec autorité : l’IP de www.
5. Le cache renvoie l’IP au poste (et la garde le temps du TTL).
6. Le poste contacte le serveur web en HTTP, port 80.

Les étapes 2 à 4 sont itératives : chaque serveur renvoie ce qu’il sait (un renvoi vers le niveau suivant), c’est le cache qui fait tout le travail.

• Primaire (maître) : fait autorité, lit la zone dans son fichier de zone, seul endroit où on la modifie.
• Secondaire (esclave) : fait autorité aussi, mais copie la zone depuis le maître.
• Racine : 13 identités de serveurs, connaissent les serveurs de chaque TLD.
• Cache : ne fait autorité sur rien, garde les réponses le temps du TTL et répond aux clients.

dig www.esprit1.com @192.168.1.102

Sans @, dig utilise le résolveur configuré sur le poste, qui peut répondre depuis son cache.

dig esprit1.com MX

On demande le MX du domaine, pas d’un hôte.

dig -x 192.168.1.100

dig construit lui-même la question 100.1.168.192.in-addr.arpa PTR.

sudo named-checkconf

Pour un fichier de zone : named-checkzone esprit1.com /etc/bind/zones/esprit1.com.

resolvectl flush-caches && nslookup www.esprit1.com

Sans vider le cache, le client répondrait avec une réponse mémorisée, et le test ne prouverait pas que le slave répond.

Dans /etc/bind/named.conf.local :

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

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

Le fichier est écrit par le slave lui-même après le transfert : on ne le crée pas à la main.

www       IN  A      192.168.1.80
intranet  IN  CNAME  www
mail      IN  A      192.168.1.25
@         IN  MX 10  mail

Le MX doit pointer vers un nom qui a un enregistrement A, pas vers une IP ni vers un CNAME.

10.1.168.192.in-addr.arpa. : les octets sont inversés, pour que le plus général (192) soit à droite, comme dans un nom DNS.

1.168.192.in-addr.arpa : les trois octets du réseau, inversés. Chaque hôte y est un PTR nommé par son dernier octet.

Le domaine esprit.tn est toute la sous-arborescence sous ce nœud. La zone est la partie qu’un administrateur gère, décrite dans un fichier de zone.

Si info.esprit.tn est délégué à une autre équipe (NS dans la zone esprit.tn), il fait toujours partie du domaine esprit.tn, mais plus de sa zone : il a sa propre zone.

• Récursif : le serveur interrogé fait toutes les requêtes nécessaires et renvoie la réponse complète (le serveur cache, pour le poste client).
• Itératif : le serveur répond avec ce qu’il sait localement : la réponse, ou un renvoi vers un autre serveur. C’est le demandeur qui continue (le cache face aux serveurs racine, TLD, autoritaires).

Avec un CNAME, l’IP n’est écrite qu’une fois (sur www). Si la machine change d’adresse, on modifie un seul enregistrement. Avec deux A, il faut penser à modifier les deux.

Le cache : il garde une réponse le temps de son TTL. Si l’enregistrement change sur le serveur autoritaire pendant ce temps, le cache continue de servir l’ancienne valeur jusqu’à expiration. Le serveur autoritaire, lui, lit sa zone.

Le slave compare le numéro de série du master au sien : plus grand, il redemande un transfert, sinon il considère qu’il est à jour.

Sans incrément, le slave ne voit pas le changement et continue de servir l’ancienne zone. Master et slave répondent différemment selon le serveur interrogé.

Un transfert AXFR livre toute la zone : tous les noms et toutes les IP internes (serveurs, postes, services). C’est une carte du réseau offerte à un attaquant. Seuls les secondaires légitimes doivent pouvoir la demander.

• Un nom, plusieurs IP : www.esprit.tn renvoie plusieurs adresses (répartition de charge, haute disponibilité).
• Plusieurs noms, une IP : www, mail, ftp.esprit.tn pointent vers la même machine.

Conséquence : la résolution inverse d’une IP ne redonne pas forcément le nom qu’on a demandé.

Un nom DNS se lit du plus précis (à gauche) au plus général (à droite). Une IP, c’est l’inverse : le réseau (192) est à gauche. En inversant, le réseau devient la partie générale, à droite : chaque organisation peut alors recevoir la délégation de sa plage (1.168.192.in-addr.arpa), comme un domaine.

1. Le slave n’a jamais reçu la zone (pas d’AXFR avant la panne : allow-transfer absent ou mauvais, fichier .slave vide). Vérifier ls -l /var/cache/bind-slave/.
2. Le client n’interroge que le master : le slave n’est pas dans sa configuration de résolveur.
3. La seconde instance n’écoute pas sur la bonne IP (listen-on) ou n’est pas démarrée. Vérifier dig www.esprit1.com @192.168.1.102.

86400 s = 24 heures : les caches qui ont résolu www avant 10 h gardent l’ancienne IP jusqu’à 24 h. Ce n’est pas une panne, c’est le cache.

Préparation : baisser le TTL (par exemple à 300 s) au moins 24 h avant le changement, changer l’IP, puis remonter le TTL.

Le slave sert la zone en lecture seule : c’est une copie. Au prochain transfert depuis le master, la correction est écrasée. On modifie toujours le master (et on incrémente le numéro de série du SOA).

Il y a 13 identités (a à m.root-servers.net), mais chacune est servie par des centaines d’instances réparties dans le monde grâce à l’anycast. Plus de 1500 machines au total.

Un MX pointe vers un nom d’hôte, pas une IP : @ IN MX 10 mail, avec mail IN A 192.168.1.25.

Non. Le slave sert sa copie, mais si le master ne répond plus pendant la durée expire du SOA, le slave considère sa zone comme périmée et cesse d’y répondre avec autorité. La redondance couvre une panne, pas un abandon du master.

Sans point final, le nom est relatif : Bind y ajoute l’origine de la zone. Il devient mail.esprit1.com.esprit1.com., qui n’existe pas. D’où l’importance du FQDN avec son point final.