Résolution DNS : ce qui se joue derrière chaque requête

Avant qu’une page s’affiche, une mécanique discrète traduit un nom en adresse. Le Fonctionnement résolution DNS lève le voile sur ce ballet : racines, TLD, autorités, caches et signatures s’enchaînent pour livrer un A ou un AAAA en quelques millisecondes. Cette enquête suit pas à pas le voyage réel d’un paquet.

Que se passe-t-il quand un nom de domaine est saisi ?

Une requête DNS part du système d’exploitation vers un résolveur récursif, qui interroge en cascade racines, TLD et serveurs faisant autorité, puis renvoie l’adresse avec un TTL. Un cache coupe court à la route quand la réponse est déjà fraîche.

Dans ce scénario sans fioritures, l’application s’adresse au stub du système. Celui-ci connaît l’adresse d’un récursif — souvent fourni par DHCP — et lui délègue la recherche. Le récursif joue alors l’enquêteur : s’il n’a rien d’exploitable en cache, il commence au sommet, auprès d’un serveur racine, pour apprendre quels serveurs règnent sur le TLD visé. De là, il obtient la délégation vers le domaine, suit les NS, récupère les glue nécessaires pour joindre ces autorités et finit par négocier la réponse exacte : A, AAAA, parfois CNAME suivi d’une nouvelle résolution. Quand tout s’aligne, la réponse voyage dans l’autre sens, escortée de son TTL qui règle la mémoire des caches, et chacun des maillons garde une trace éphémère de l’événement, afin que la prochaine demande ne refasse pas toute l’ascension.

• Le stub interroge un récursif connu (ISP, entreprise, service public).
• Le récursif consulte racines → TLD → autorité, en itératif.
• Les réponses valides sont mises en cache selon leur TTL.
• Les échecs aussi se mémorisent brièvement (négatif).
• Le client reçoit une réponse synthétique et rapide, tant que la chaîne reste cohérente.

D’où part la requête : stub, résolveur récursif et serveurs racines

Le stub sait où envoyer la question, le récursif sait comment remonter la hiérarchie et les racines posent la première pierre de confiance. L’ensemble forme la rampe de lancement des recherches.

Dans la plupart des systèmes, le stub est minimaliste : il n’interroge qu’un petit nombre d’adresses préconfigurées, souvent apprises via DHCP ou MDM. Le récursif, lui, détient la compétence : il maintient un cache, applique des politiques (EDNS, QNAME minimization, ECS si activé), et garde sous la main un jeu d’indices pour joindre les treize identités logiques du Root Server System, servies en anycast à travers le monde. Ces racines ne connaissent pas les réponses finales, mais indiquent quels TLD continueront l’histoire. Les praticiens notent que la latence d’accès aux racines devient marginale dès que le cache du récursif se réchauffe ; la vraie bataille se joue alors dans la cohérence de la délégation et la santé des autorités. Dans les environnements d’entreprise, des forwarders intermédiaires peuvent encore relayer la charge, ce qui facilite le contrôle mais exige une vigilance sur la fraîcheur du cache et les MTU qui sabotent parfois EDNS.

Le cache décide : TTL, fraîcheur et cohérence

Le cache répond tant que le TTL n’est pas écoulé et que la cohérence n’a pas été brisée par une invalidation. Des politiques avancées prolongent parfois la vie des données pour éviter l’arrêt brutal.

Le cœur de la performance DNS tient dans cet art de la mémoire. Un TTL court accélère la propagation des changements, mais force des voyages plus fréquents vers les autorités. Un TTL long apaise les serveurs et stabilise le trafic, au prix d’une inertie qu’il faut anticiper avant les migrations. Certains résolveurs proposent le prefetch, qui regarnit le cache avant expiration, et le serve-stale, qui accepte de livrer une réponse légèrement périmée si l’autorité se tait momentanément, limitant ainsi les tempêtes de timeouts. La cohérence passe aussi par l’attention portée au négatif : NXDOMAIN se met en cache, tout comme les NOERROR/NODATA, afin d’éviter les boucles infernales vers l’inconnu. Dans la pratique, la juste mesure naît des métriques : ratio de hits, latences p50/p95/p99, répartition IPv4/IPv6, et part des échecs par code RCODE.

Comment le négatif se met en cache

Les échecs se mémorisent brièvement pour protéger les autorités et accélérer la réponse. Les paramètres négatifs doivent rester mesurés pour ne pas figer une correction.

Quand une réponse NXDOMAIN surgit, le résolveur ne retentera pas l’aventure à chaque requête. Il applique un délai, souvent dérivé de l’enregistrement SOA de la zone interrogée (champs minimum/TTL négatif), plafonné par des bornes internes. De même, un NOERROR/NODATA informe que le nom existe mais pas le type demandé — cas typique d’un A absent quand seule une IPv6 (AAAA) a été fournie. La sagesse opérationnelle impose d’éviter des TTL négatifs extravagants : ils maquillent la douleur sur le moment, mais prolonge la confusion quand l’erreur côté autorité a été corrigée. La visibilité sur le cache négatif reste un atout pour débusquer des fautes de frappe qui empoisonnent longtemps les statistiques de hit.

Quand l’autorité répond : NS, glue, CNAME et délégations

La résolution suit la délégation : des racines vers le TLD, puis vers les serveurs faisant autorité pour le domaine. Les glue facilitent la jonction, et les CNAME redirigent la question vers un autre nom à résoudre.

La mécanique paraît simple, mais recèle des chausse-trappes. Un domaine est confié à plusieurs NS, publiés chez le parent (le TLD) et répétés dans l’autorité enfant. Si l’un de ces NS est lui-même dans la zone enfant, une glue — une adresse A/AAAA servie par le parent — évite le paradoxe de l’œuf et de la poule. Les chaînes CNAME ajoutent une étape supplémentaire : l’autorité indique que la réponse se trouve sous un autre nom, parfois dans une autre zone, exposant des politiques de cache discordantes. Les praticiens rencontrent aussi des délégations « lame » : le parent délègue vers un NS qui n’a pas la zone, ou répond en erreur. À l’échelle d’une infrastructure, ces décalages se traduisent par des latences en dents de scie, et des SERVFAIL en cascade si la validation DNSSEC entre en jeu.

• Éviter les délégations « lame » en vérifiant que chaque NS sert la zone.
• Harmoniser les TTL à travers une chaîne CNAME pour limiter les secousses.
• Publier des glue exactes et surveiller leur alignement IPv4/IPv6.

Sécurité et vie privée : DNSSEC, QNAME minimization et cohérence

DNSSEC signe les enregistrements, le résolveur valide la chaîne de confiance jusqu’à la racine, et la QNAME minimization réduit les fuites de noms complets vers chaque palier. L’ensemble augmente l’intégrité sans sacrifier la performance.

DNSSEC s’appuie sur des enregistrements RRSIG calculés à partir des DNSKEY de la zone, ancrés dans une chaîne de DS publiés par le parent. Un résolveur validant reconstruit le chemin : clé de la zone, DS chez le parent, et ainsi de suite jusqu’à l’ancre de la racine. Si un maillon manque, la réponse honnête devient SERVFAIL, ce qui surprend parfois quand l’autorité tourne une clé ou publie un DS mal formé. La QNAME minimization, popularisée par RFC 7816, n’envoie à chaque niveau que la partie nécessaire du nom : au TLD, seul l’étiquette de second niveau transparaît, pas l’hôte complet, limitant l’exposition des sous-domaines. Le tandem fonctionne bien, à condition d’absorber les détails opérationnels : MTU qui fragmente les paquets signés, autorités allergiques aux requêtes minimisées, horloges en retard qui rendent les signatures « pas encore valides ». Une instrumentation fine — journaux de validation, compteurs d’ECN/ICMP, suivi des tailles de réponse — transforme ces irritations en diagnostics rapides.

Protocoles et transport : UDP, TCP, EDNS, DoT et DoH

Le DNS parle d’abord UDP, bascule en TCP si nécessaire, s’appuie sur EDNS pour élargir les messages, et peut être chiffré via DoT ou DoH pour protéger le transport. Chaque option a sa dynamique et ses coûts.

Le flux classique use d’UDP pour sa légèreté : question, réponse, plié. Quand la réponse dépasse la taille annoncée, la troncature (TC=1) invite à refaire la danse en TCP, plus verbeux mais fiable. EDNS (RFC 6891) publie la taille maximale acceptée, souvent 1232–4096 octets, variable selon les MTU et les politiques anti-fragmentation. Sur le terrain, forcer une taille EDNS raisonnable évite des pertes silencieuses. Côté confidentialité, DoT (DNS over TLS) chiffre sur 853/TCP et DoH (DNS over HTTPS) encapsule le DNS dans HTTP/2 ou HTTP/3. Le premier s’insère bien dans les piles réseau traditionnelles, le second traverse sans heurts des proxys zélés et autorise du multiplexage. Leur adoption déplace la charge vers des connexions persistantes et des handshakes coûteux ; en retour, la corrélation des requêtes par un observateur passif devient nettement plus difficile.

EDNS et la taille des réponses DNS

Annoncer une taille EDNS adaptée évite les pertes par fragmentation et réduit les bascules TCP inutiles. La valeur de 1232 octets demeure un compromis robuste sur Internet.

Entre l’enthousiasme de grossir les messages DNSSEC et la réalité des MTU variables, un juste milieu s’impose. En pratique, annoncer 1232–1400 octets limite la casse sur des chemins étriqués, surtout derrière des tunnels ou VPN qui mordent dans la MTU. Les autorités bavardes — zones riches en RRSIG, DNSKEY lourdes, records HTTPS/SVCB foisonnants — gagnent à soigner la compaction : NSEC3 sobre, pas de clés obsolètes, réponses ciblées. Côté résolveur, des stratégies de retry en TCP ou en réduisant EDNS par palier accélèrent la délivrance au lieu d’empiler les timeouts.

Lire une panne : timeouts, NXDOMAIN, SERVFAIL et REFUSED

Chaque code raconte une histoire : NXDOMAIN indique que le nom n’existe pas, SERVFAIL trahit une autorité muette ou une validation cassée, REFUSED révèle une politique, et les timeouts signent souvent un problème de transport.

Les diagnostics efficaces commencent par la cartographie des symptômes. Un NXDOMAIN massif sur un sous-domaine neuf parle souvent d’une propagation incomplète ou d’une faute de frappe durable. Un SERVFAIL n’est presque jamais une plaisanterie : validation DNSSEC rompue, délégation « lame », zone absente sur l’autorité, clé expirée. Les timeouts suivent les MTU trop ambitieux, les filtrages asymétriques ou des autorités surchargées. REFUSED, au contraire, assume la décision : récursif privé interrogé depuis l’extérieur, politique de rate limit, liste d’accès restrictive. Les équipes aguerries lisent aussi le timing : une alternance réponse/échec toutes les minutes trahit des bascules actives, quand une montée lente de la latence annonce le frémissement d’un cache qui perd son hit-ratio.

• Comparer la réponse d’un résolveur validant et non validant pour isoler DNSSEC.
• Forcer TCP et réduire EDNS pour traquer les problèmes de taille.
• Interroger directement l’autorité afin d’écarter les caches intermédiaires.
• Surveiller les TTL résiduels : une incohérence révèle des caches hétérogènes.

Optimiser une infrastructure de résolution sans sacrifier la clarté

La robustesse naît d’un cache discipliné, d’un transport maîtrisé et d’une observabilité précise. Quelques réglages bien choisis transforment une chaîne nerveuse en instrument mesuré.

Un récursif moderne gagne à activer la QNAME minimization, à limiter la taille EDNS vers 1232–1400 octets et à pratiquer le prefetch pour les noms chauds. Le serve-stale protège contre les éclipses d’autorités sans masquer durablement les erreurs. Le monitoring s’appuie sur des métriques lisibles : taux de hits, p95 de latence, répartition des RCODE, proportion TCP/UDP/DoT/DoH, poids des réponses et taux d’échec de validation. L’acheminement vers des autorités proches — via anycast public de TLD, ou via accords de peering — rabote la latence. Dans les environnements mixtes, l’IPv6 mérite une parité de soin : glue en double pile, pare-feu accommodant l’ICMP indispensable au PMTUD. Enfin, la publication elle-même devient un acte d’ingénierie : TTL alignés à travers une chaîne CNAME, politiques DNSSEC sobres, et migrations scénarisées avec TTL abaissé en amont puis réhaussé une fois la poussière retombée.

• Activer QNAME minimization et validation DNSSEC côté récursif.
• Régler EDNS autour de 1232–1400 octets, observer le fallback TCP.
• Utiliser prefetch et serve-stale avec des bornes claires.
• Uniformiser les TTL à travers les CNAME et documenter les fenêtres de bascule.
• Surveiller p50/p95/p99 de latence, taux de troncature et d’erreurs par RCODE.

Au bout du compte, la résolution DNS ressemble à un réseau ferré bien tenu : aiguillages précis, horaires respectés, signaux fiables. Les trains qui filent ne se remarquent pas ; ceux qui s’arrêtent racontent, par leur silence, où se trouvent les rails mal alignés. En resserrant les vis — cache discipliné, délégations nettes, transport ajusté, signatures lisibles — la topologie cesse d’être une énigme et redevient un service de base, furtif et solide.

La progression des usages chiffrés — DoT, DoH, bientôt DoQ — continuera de redistribuer la charge vers des connexions persistantes et des métriques plus riches. Ce déplacement ne change pas l’essentiel : une résolution bien conçue n’éblouit pas, elle se fait oublier. Et quand il s’agit de l’infrastructure du web, c’est souvent la plus belle des qualités.