DNS: récursif, itératif et commandes IOS
Définition
Le DNS (Domain Name System) traduit des noms hiérarchiques (www.exemple.fr) en adresses IP. C'est une base distribuée : chaque domaine fait autorité pour sa zone, et des résolveurs chargés de la collecte répondent aux clients. Un poste n'interroge en général qu'un seul serveur, son résolveur, qui se débrouille pour trouver la réponse ailleurs.
Contexte
Le topic 4.3 du blueprint 200-301 demande d'expliquer le rôle de DNS dans le réseau. Attendus concrets : connaître la séquence de résolution d'un client (cache, hosts, résolveur), la différence entre requête récursive et itérative, le rôle des serveurs racine/TLD/authoritatifs, la configuration ip name-server sur un routeur, et les commandes de test (nslookup, ipconfig /displaydns).
Détails techniques
Ce que fait le client avant d'appeler le DNS
Un navigateur qui veut www.exemple.fr vérifie dans l'ordre : son propre cache applicatif, le cache du système d'exploitation, le fichier hosts (C:\Windows\System32\drivers\etc\hosts ou /etc/hosts), puis la requête DNS vers le serveur configuré (obtenu par DHCP le plus souvent). Une entrée hosts est prioritaire sur le DNS : c'est l'astuce de dépannage classique pour forcer une résolution locale.
Récursif contre itératif
Le client pose une requête récursive à son résolveur : "trouve-moi la réponse, je ne veux pas gérer la chaîne". Le résolveur interroge alors les serveurs Internet de façon itérative : chacun lui répond "je ne sais pas, demande à celui-là".
| Étape | Interrogé | Réponse |
|---|---|---|
| 1 | Serveur racine (13 groupes, a.root à m.root) | "Va voir un TLD .fr" |
| 2 | TLD .fr | "Va voir les DNS autoritatifs d'exemple.fr" |
| 3 | Autoritatif exemple.fr | "www.exemple.fr = 93.184.216.34, TTL 3600" |
| 4 | Résolveur vers le client | Réponse complète, mise en cache selon TTL |
Types d'enregistrements utiles à l'examen
| Type | Sens | Exemple |
|---|---|---|
| A | Nom vers IPv4 | www.exemple.fr vers 93.184.216.34 |
| AAAA | Nom vers IPv6 | www.exemple.fr vers 2001:db8::1 |
| CNAME | Alias vers un autre nom | www vers exemple.fr |
| MX | Serveur de messagerie du domaine | exemple.fr vers mail.exemple.fr (priorité 10) |
| NS | Délégué autoritatif de la zone | exemple.fr vers dns1.nic.fr |
| PTR | IP vers nom (reverse) | 34.216.184.93.in-addr.arpa vers www... |
Le transport DNS est UDP 53 par défaut, avec bascule TCP 53 pour les transferts de zone et les réponses dépassant la taille du datagramme.
DNS sur un routeur IOS
Un routeur résout ses propres noms (pour ping ou traceroute par nom) si on lui donne un serveur :
R1(config)# ip name-server 192.168.10.10 8.8.8.8
R1(config)# ip domain-name exemple.fr
ip domain-name plus le hostname servent aussi à générer les clés RSA pour SSH. Deux pièges IOS : par défaut, un mot tapé seul que la CLI ne reconnaît pas est interprété comme un nom d'hôte et déclenche une résolution DNS ("Translating 'shwo'... domain server (255.255.255.255 by default)"). La commande no ip domain-lookup désactive ce comportement. Une faute de frappe fait alors patienter la CLI le temps des timeouts : c'est le symptôme que cette commande corrige.
Vérification côté client
nslookup www.exemple.fr: interroge le résolveur configuré,set type=MXpour d'autres champs.ipconfig /displaydns(Windows) puisipconfig /flushdns: vider le cache local.dig www.exemple.fr(Linux) : affiche la chaîne complète de délégation.
Exemple concret
Un utilisateur signale que "le site est mort" alors que le collègue d'à côté y accède. Le poste en question pointe un vieux serveur DNS reçu par DHCP (le pool a été modifié la semaine dernière). nslookup depuis le poste timeout en 5 secondes vers 192.168.10.20 ; nslookup vers 192.168.10.10 répond immédiatement. Correction : pool DHCP mis à jour, ipconfig /release et renew côté client. Temps total : 10 minutes, et le site n'a jamais eu de panne.
Pièges fréquents
- Confondre récursif et itératif : c'est la relation client/résolveur qui est récursive, la relation résolveur vers Internet qui est itérative.
- Oublier que hosts passe avant DNS : une ancienne entrée peut masquer un DNS parfaitement sain.
- Un routeur qui "hang" sur une CLI mal tapée :
no ip domain-lookuprègle le symptôme, pas la cause (frappe correcte). - Le TTL se lit côté réponse : un enregistrement modifié à la source peut rester périmé dans les caches pendant la durée du TTL.