Comment fonctionne le DNS : résolution récursive et itérative

Le DNS (Domain Name System) est l'annuaire distribué qui traduit un nom comme intranet.sorbier.example en adresse IP, et l'inverse. Pour trouver une réponse, un résolveur interroge, de proche en proche, des serveurs faisant autorité : la racine, puis le domaine de premier niveau, puis le serveur qui connaît la zone. Ce chapitre décrit cette mécanique pas à pas, le rôle du cache et du TTL, et ce qui se passe sur le poste avant même la première question.

Pourquoi un annuaire distribué

Au début d'Internet, un seul fichier, HOSTS.TXT, listait toutes les machines du réseau. Chacun le téléchargeait régulièrement. Quand le réseau a dépassé quelques milliers de machines, le fichier est devenu ingérable : trop gros, jamais à jour, modifiable par une seule équipe. Le DNS, normalisé en 1987 (RFC 1034 et 1035), a remplacé ce fichier par une base hiérarchique et répartie : chaque organisation gère elle-même la partie de l'arbre qui la concerne, sur ses propres serveurs.

Le fichier hosts a survécu sur chaque machine (C:\Windows\System32\drivers\etc\hosts sous Windows, /etc/hosts sous Linux). Il est lu avant le DNS : une ligne oubliée dedans peut fausser toute une résolution. C'est un des premiers endroits à regarder en dépannage.

L'arborescence des noms

Les noms forment un arbre, lu de droite à gauche :

Un FQDN (Fully Qualified Domain Name) est un nom complet jusqu'à la racine, avec son point final : srv-fichiers.ad.sorbier.example.. Chaque partie entre deux points est une étiquette de 63 caractères au plus, et le nom complet ne dépasse pas 253 caractères. Les noms ne tiennent pas compte de la casse : SRV-AD et srv-ad désignent la même machine.

Le TLD .example est réservé à la documentation (RFC 2606), comme les adresses 203.0.113.0/24 et 198.51.100.0/24 : aucun de ces noms n'existe vraiment sur Internet, c'est pour cela que le cours les utilise.

Les deux rôles d'un serveur DNS

Le mot « serveur DNS » désigne deux métiers très différents. Les confondre est l'erreur la plus fréquente en TP comme en épreuve.

Un même logiciel peut tenir les deux rôles. Les contrôleurs de domaine de Sorbier le font : ils font autorité pour la zone interne ad.sorbier.example et ils résolvent les noms d'Internet pour les postes. Sur Internet, on sépare les deux : un serveur public qui fait autorité ne doit pas faire de résolution pour les inconnus (chapitre 4).

La résolution d'un nom, étape par étape

Julie Lefèvre, comptable chez Sorbier, ouvre www.service-public.fr depuis son poste du VLAN 10. Son poste a reçu par DHCP les résolveurs 192.168.10.177 (srv-ad) et 192.168.10.181 (srv-ad2). On suppose que les caches sont vides et que srv-ad utilise les indications de racine (il fait lui-même l'enquête, sans redirecteur).

1. Le poste vérifie son cache DNS et son fichier hosts. Rien. Il envoie à srv-ad une requête récursive : « donne-moi l'adresse de www.service-public.fr, et débrouille-toi pour la trouver ». Le bit RD (Recursion Desired) de la requête est à 1.
2. srv-ad ne connaît pas la réponse. Il interroge un des 13 serveurs racines, dont il connaît les adresses par ses indications de racine. C'est une requête itérative : le serveur interrogé répond avec ce qu'il sait, sans enquêter.
3. La racine ne connaît pas www.service-public.fr, mais elle sait qui gère .fr. Elle répond par une délégation (referral) : la liste des serveurs de noms de .fr, avec leurs adresses.
4. srv-ad pose la même question à un serveur de .fr.
5. Le serveur de .fr délègue à son tour : voici les serveurs qui font autorité pour service-public.fr.
6. srv-ad interroge un de ces serveurs.
7. Celui-ci fait autorité pour la zone : il donne la réponse, marquée du bit AA (Authoritative Answer). Ici, c'est un alias (CNAME) suivi d'une adresse.
8. srv-ad garde la réponse et les délégations en cache, puis répond au poste. Le poste garde aussi la réponse dans son propre cache.

Les étapes 2 à 7 n'ont lieu qu'au premier accès. Dix secondes plus tard, Karim Morel ouvre le même site : srv-ad répond directement depuis son cache, en moins d'une milliseconde. Et s'il demande www.impots.gouv.fr, srv-ad sait déjà qui gère .fr : il saute l'étape de la racine.

Requête récursive, requête itérative : la différence

Un redirecteur (forwarder) change le schéma : au lieu d'enquêter lui-même, srv-ad envoie une requête récursive à un autre résolveur (celui de pfSense, du fournisseur d'accès ou d'un service comme Quad9), qui fait l'enquête à sa place. Le chapitre 3 compare les deux choix.

Le cache et le TTL

Chaque enregistrement porte un TTL (Time To Live), en secondes : la durée pendant laquelle un résolveur a le droit de garder la réponse en cache. Il est fixé par l'administrateur de la zone.

Le cache garde aussi les réponses négatives : si un nom n'existe pas (réponse NXDOMAIN), le résolveur s'en souvient pendant une durée fixée par la zone, dans son enregistrement SOA (RFC 2308). Si tu crées un nom juste après qu'un poste l'a demandé en vain, ce poste peut continuer à recevoir « nom inexistant » pendant ce délai. La solution : vider le cache (ipconfig /flushdns sur le poste, Clear-DnsServerCache sur le serveur Windows, rndc flush sur BIND).

Les ports : UDP 53, TCP 53, et au-delà

Une requête DNS ordinaire tient dans un seul datagramme UDP, sur le port 53 du serveur : pas de connexion à établir, c'est rapide. Le DNS utilise aussi TCP 53 :

• quand la réponse est trop grosse pour UDP : le serveur renvoie une réponse tronquée (bit TC) et le client recommence en TCP ;
• pour les transferts de zone entre serveurs (chapitre 2) ;
• pour les variantes chiffrées : DNS over TLS sur TCP 853, DNS over HTTPS sur TCP 443 (chapitre 5).

À l'origine, une réponse UDP était limitée à 512 octets. L'extension EDNS(0) permet d'annoncer une taille plus grande ; depuis le « DNS Flag Day » de 2020, la valeur recommandée est de 1 232 octets, pour éviter la fragmentation IP. C'est la valeur que dig affiche dans la ligne udp: 1232.

Ce qui se passe sur le poste avant la requête

Une application ne parle presque jamais directement au DNS : elle demande au système « quelle est l'adresse de ce nom ? ». Le système suit un ordre précis.

Retiens deux conséquences pratiques. Un poste qui a un serveur DNS public (8.8.8.8) en premier ne trouvera jamais les noms internes. Et un poste dont le second DNS est public peut basculer dessus au premier incident réseau : les deux serveurs configurés doivent connaître les mêmes zones. Chez Sorbier, les postes reçoivent srv-ad et srv-ad2, et seulement eux.

Les codes de réponse et les drapeaux

Chaque réponse DNS porte un code de retour (RCODE) et des drapeaux. Ce sont les premières choses à lire dans une sortie de dig ou une capture Wireshark.

Voici une réponse lue avec dig depuis un serveur Debian de Sorbier :

$ dig @192.168.10.177 srv-fichiers.ad.sorbier.example

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41872
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;srv-fichiers.ad.sorbier.example. IN	A

;; ANSWER SECTION:
srv-fichiers.ad.sorbier.example. 3600 IN A	192.168.10.178

;; Query time: 1 msec
;; SERVER: 192.168.10.177#53(192.168.10.177) (UDP)

status: NOERROR, une réponse ; aa : srv-ad fait autorité pour cette zone ; ra : il accepte aussi la récursion ; TTL de 3 600 secondes. La même question posée pour www.service-public.fr reviendrait sans le drapeau aa : srv-ad répondrait depuis son cache, en résolveur.

Le DNS et la sécurité

Le DNS a été conçu sans aucune protection : les réponses ne sont ni signées ni chiffrées. Les attaques qui en profitent, à connaître pour l'E7 :

Le chapitre 5 détaille les protections : DNSSEC pour l'authenticité des réponses, DNS over TLS et DNS over HTTPS pour la confidentialité.

Exercices

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6123
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;intranet.sorbier.example.	IN	A
;; SERVER: 9.9.9.9#53(9.9.9.9) (UDP)