DNS : résolution, délégation et exploitation

DNS répond à la question de savoir quelle information est publiée pour un nom donné et qui en est responsable. Le système est à la fois un espace de noms hiérarchique, une base de données distribuée et un protocole de requête binaire. Il fournit non seulement des adresses IP, mais aussi des serveurs de noms, des destinations de messagerie, des points de terminaison de services, des clés et des politiques. Considérer DNS uniquement comme une « résolution de noms » revient donc à ignorer précisément les enregistrements dont dépendent la messagerie et l’identité (RFC 9499).

Le chemin suivant commence au niveau du stub resolver d’une application, suit le cache et les délégations jusqu’au serveur autoritatif, puis ramène la réponse. Ce déroulement permet de situer TTL, Glue, repli TCP, DNSSEC, exploitation des zones et scénarios d’erreur typiques.

Pour les administrateurs de messagerie, DNS est un système de pilotage en amont. Un MTA y détermine la prochaine destination de messagerie, l’authentification de l’expéditeur y lit les politiques et les clés, les procédures de certificats peuvent intégrer des données sécurisées par DNSSEC, et les clients d’annuaire ou Kerberos recherchent des services via des enregistrements SRV. DNS ne vérifie toutefois pas si le service trouvé est sain. Une réponse MX syntaxiquement correcte peut pointer vers un écouteur SMTP inaccessible ; une recherche A réussie ne dit rien sur TLS, l’authentification ou l’état de l’application.

Architecture et rôles

La responsabilité des noms est organisée sous forme d’arbre. À la racine sans nom . commencent les domaines de premier niveau tels que ch., suivis de domaines délégués et d’autres labels. Un point final rend un nom complet et empêche l’ajout de suffixes de recherche locaux. Cette petite différence d’écriture est pertinente en exploitation : mail.example.ch peut être complété par un domaine de recherche sur un client, mail.example.ch. ne le peut pas.

Un domaine est une partie de l’espace de noms. Une zone, en revanche, est un ensemble de données administrativement cohérent pour lequel un serveur autoritatif assume une responsabilité locale. Une délégation extrait une zone enfant de la zone parente. Le parent publie à cet effet un RRset NS et, lorsqu’un nom de serveur de noms se trouve dans la zone enfant déléguée, les données A ou AAAA nécessaires pour l’atteindre en tant que Glue. La distinction fondamentale entre espace de noms, zones et délégation provient de RFC 1034; les termes actuels sont résumés dans RFC 9499, section 7.

Quatre rôles logiques expliquent le chemin de résolution :

Un produit peut implémenter plusieurs rôles, mais il convient tout de même de les considérer séparément en exploitation. Une défaillance du service autoritatif affecte la publication des zones propres ; une défaillance du service récursif affecte la résolution de noms des propres clients. Des processus, adresses ou domaines de défaillance communs rendent cette distinction plus difficile.

Résolution de noms étape par étape

Une application n’interroge normalement pas elle-même les serveurs racine et autoritatifs. Son stub resolver transmet une requête récursive à un resolver. Si celui-ci ne possède pas d’entrée de cache exploitable, il suit les délégations depuis la racine, via le domaine de premier niveau, jusqu’à la zone responsable. Chaque referral indique le RRset NS suivant et, si nécessaire, les adresses Glue. Le resolver compose la réponse finale à partir de ces éléments, valide DNSSEC le cas échéant et met le résultat en cache (RFC 1034, section 4.3).

Le parcours linéaire représenté est un modèle de démarrage à froid. Dans le cache chaud d’un resolver, les délégations racine et TLD sont généralement déjà présentes, de sorte qu’une partie seulement des étapes est nécessaire. La minimisation QNAME, le forwarding, les zones locales ou les caches DNSSEC agressifs peuvent également modifier le chemin visible des paquets. L’essentiel reste d’attribuer chaque observation à un rôle : une réponse de cache non autoritative ne prouve pas ce que le serveur autoritatif responsable délivre à cet instant.

Structure technique d’un message DNS

Sur le réseau, un message DNS se compose d’un en-tête, de sections Question, Answer, Authority et Additional. La question désigne QNAME, QTYPE et QCLASS. Les réponses et renvois apparaissent sous forme de Resource Records dans les autres sections. Les flags indiquent notamment l’autorité, la demande de récursion et la troncature ; le Response Code décrit le résultat. L’analyse ne porte donc pas uniquement sur le texte de la réponse, mais aussi sur le serveur dont elle provient et les flags qui l’accompagnent (RFC 1035, section 4.1).

Pour un diagnostic, les éléments suivants sont particulièrement pertinents :

EDNS(0) ajoute, au moyen d’un pseudo-enregistrement OPT, des flags, options et une charge utile UDP annoncée plus importante, sans remplacer le format de base (RFC 6891). Le bit DNSSEC DO se trouve dans ce champ de flags étendu, et non dans l’en-tête DNS d’origine.

Resource Records et RRsets

Le contenu métier se trouve dans les Resource Records. Le nom propriétaire, le type et la classe déterminent à quoi appartiennent les données ; TTL et RDATA fournissent la durée de cache et la valeur spécifique au type. Tous les enregistrements ayant le même propriétaire, le même type et la même classe forment un RRset et partagent un TTL. Plusieurs valeurs MX, A ou AAAA constituent donc un ensemble mis en cache conjointement, et non des objets individuels pouvant être gérés indépendamment (RFC 2181, section 5).

Le texte d’un fichier de zone n’est que la forme de présentation. Sur le réseau, les noms sont transmis par labels, les nombres en binaire et certains noms peuvent être compressés. Lorsqu’on copie une chaîne depuis une interface, il faut donc distinguer si celle-ci a déjà assemblé des guillemets, séquences d’échappement ou plusieurs chaînes TXT en une charge utile logique.

Délégation, Glue et autorité

Par une délégation, une zone transmet la responsabilité d’un sous-arbre. Le parent publie le RRset NS de la zone enfant ; la zone enfant indique elle-même à nouveau ses serveurs autoritatifs. Si les deux côtés divergent, les resolvers peuvent emprunter des chemins différents. Les adresses Glue du parent ne résolvent que le problème de l’œuf et de la poule de l’accessibilité. Les valeurs A/AAAA autoritatives au nom du serveur de noms restent des données indépendantes, avec leur propre TTL et leur propre maintenance.

Le Glue in-bailiwick est particulièrement critique : si example.ch. est délégué à ns1.example.ch., le resolver a besoin de l’adresse de ns1.example.ch. avant de pouvoir interroger la zone enfant. Sans Glue, une boucle de résolution se produirait. Si la délégation pointe au contraire vers ns1.provider.net., son adresse peut être déterminée via une autre chaîne de délégation.

Lors d’un changement de serveur de noms, il faut donc vérifier au minimum quatre états : la nouvelle zone est chargée sur tous les serveurs, le RRset NS enfant est adapté, la délégation parent est adaptée et le Glue nécessaire est actualisé. Ce n’est qu’ensuite que les anciens serveurs doivent être retirés de l’exploitation ou de l’accessibilité.

Cache, TTL et réponses négatives

Après la résolution, une réponse continue d’exister dans les caches. Son TTL est la durée maximale d’utilisation à partir du moment où chaque resolver l’a apprise. Il n’existe donc pas de décompte commun à l’échelle mondiale. Les stub resolvers, redirecteurs, resolvers récursifs et applications peuvent abandonner le même ancien RRset à des moments différents. Une réduction du TTL avant une migration n’aide que pour les réponses rechargées ensuite ; les données déjà mises en cache ne peuvent pas être rappelées.

La non-existence est également mise en cache. NXDOMAIN signifie que le nom demandé n’existe pas ; NODATA est une réponse NOERROR dans laquelle le nom existe, mais sans RRset du type interrogé. Le serveur autoritatif place son RR SOA dans la section Authority pour ces deux réponses. La durée du cache négatif est le minimum entre le TTL du SOA et SOA.MINIMUM (RFC 2308, sections 3 à 5). Cela explique pourquoi un sélecteur DKIM ou un nom d’hôte nouvellement créé peut continuer à sembler absent après une tentative précédente ayant échoué.

SERVFAIL doit être distingué de cela : le resolver n’a pas pu produire de réponse exploitable. Parmi les causes figurent des timeouts vers les serveurs autoritatifs, une délégation défectueuse, une erreur de validation DNSSEC ou une limitation interne de ressources. REFUSED signifie en revanche que le serveur interrogé n’exécute pas l’opération en raison de sa politique. Un outil de diagnostic doit donc afficher le RCODE, le bit AA, le serveur répondant et les sections ; une sortie indiquant seulement « pas d’adresse » masque des différences essentielles.

Transport : UDP, TCP et chemins de resolver chiffrés

Pour cet échange, le chemin réseau doit autoriser UDP et TCP sur le port 53. TCP n’est pas limité aux transferts de zone : un resolver peut l’utiliser directement et doit pouvoir s’y replier après une réponse UDP tronquée. Le blocage de TCP n’apparaît donc souvent qu’avec des RRsets volumineux, riches en DNSSEC ou comportant de nombreuses réponses. Les petites requêtes A restent vertes et donnent une image trompeuse (RFC 7766).

Sans EDNS, la charge utile DNS sur UDP est limitée à 512 octets. EDNS permet au demandeur d’annoncer une charge utile recevable plus importante. Une valeur trop élevée peut toutefois imposer une fragmentation IP ; si un chemin perd ou bloque des fragments, on obtient le scénario typique où les petites réponses fonctionnent et les grandes expirent. La spécification EDNS recommande de tenir compte de la capacité de réception réelle et du chemin, et de se replier vers des valeurs plus petites ou TCP en cas de problème (RFC 6891, section 6.2).

DNS over TLS, DNS over HTTPS ou DNS over QUIC chiffrent un chemin de transport DNS. Ces mécanismes ne modifient ni le contenu des zones ni la délégation et ne remplacent pas DNSSEC : le chiffrement du transport protège la connexion à un resolver, DNSSEC authentifie les données le long de la chaîne de délégation. Le DNS classique sur le port 53 n’est pas chiffré ; la terminologie commune des types de transport est définie dans RFC 9499, section 6.

DNSSEC et chaîne de confiance

DNSSEC complète la résolution de noms par une origine et une intégrité vérifiables. Une zone signe les RRsets avec RRSIG et publie les clés publiques sous forme de DNSKEY. Le parent relie la zone enfant à la chaîne de confiance supérieure par DS ; NSEC ou NSEC3 peut aussi prouver la non-existence. Un resolver validant commence à son Trust Anchor et vérifie cette chaîne jusqu’à la réponse. Le contenu reste public : DNSSEC ne chiffre aucune requête (RFC 4033, RFC 4034).

Pour l’exploitation, les fichiers de clés ne sont pas les seuls éléments pertinents, plusieurs états liés dans le temps doivent être pris en compte :

• Les RRSIG ont un début et une expiration ; une heure système erronée ou un échec de re-signature peut rendre toute une zone bogus.
• Un DS dans le parent doit correspondre à une DNSKEY exploitable de la zone enfant. Un DS orphelin est pire pour les resolvers validants qu’une délégation délibérément non signée.
• Lors des rollovers, publication, signature, modification du parent, TTL et durées de cache doivent être planifiés comme une machine à états.
• Un resolver validant fournit souvent SERVFAIL pour des données bogus. Un test sans validation peut afficher simultanément une réponse apparemment normale.

Le flag AD seul n’est fiable qu’à la hauteur du resolver et du chemin qui mène à lui. Pour une vérification indépendante, un administrateur doit examiner la chaîne avec un outil validant et localiser la transition défectueuse entre DS, DNSKEY et RRSIG.

Exploitation autoritative et flux de données

Derrière la réponse autoritative se trouve son propre chemin de distribution. Dans un modèle classique, une source primaire gère la zone, DNS NOTIFY informe les secondaires d’un nouveau SOA Serial et AXFR ou IXFR transfèrent respectivement les données complètes ou incrémentielles. Un écouteur sain ne prouve donc pas encore que le serveur a chargé la nouvelle zone. Serial, statut de transfert et réponse de chaque nœud autoritatif doivent être considérés ensemble (RFC 1996, RFC 5936, RFC 1995).

La zone peut être générée à partir de fichiers texte, d’une base de données, d’une API, d’Active Directory ou d’un pipeline Git/CI. Ce choix d’implémentation ne modifie pas le protocole DNS sur le réseau, mais détermine les limites transactionnelles, l’auditabilité et la récupération. RFC 2136 définit les mises à jour dynamiques atomiques avec des prérequis ; un appel d’API de fournisseur constitue en revanche un protocole de contrôle distinct et doit documenter ses propres règles de cohérence et de gestion des erreurs (RFC 2136).

Une sauvegarde DNS n’est exploitable que si elle permet de restaurer la zone réellement servie. Selon la plateforme, cela inclut :

• la zone ou la base de données source, y compris le SOA Serial et le journal dynamique ;
• la configuration du serveur, les vues, ACL, redirecteurs et associations de catalogue ;
• les secrets TSIG, les clés privées DNSSEC et les états des rollovers automatiques ;
• les données parent hors de sa propre zone, en particulier délégation, Glue et DS ;
• une méthode testée pour réapprovisionner les secondaires et vérifier sémantiquement les données de zone.

Les secondaires sont des copies de disponibilité, mais pas automatiquement une sauvegarde historique. Une modification erronée ou malveillante peut être rapidement répliquée sur tous les serveurs autoritatifs via NOTIFY et transfert de zone.

Implémentations et pile technologique

DNS ne désigne pas un daemon unique. La pile technologique commune se compose de noms et RRsets, d’un format binaire de requête/réponse, d’UDP et TCP, de logique de cache et, en option, de DNSSEC. Les serveurs autoritatifs, resolvers récursifs, redirecteurs et DNS managés implémentent ces composants différemment. Pour l’exploitation, le rôle d’un produit compte donc d’abord, puis son langage ou son packaging :

La séparation des rôles est plus importante que le nom du produit. Pour une plateforme autoritative publique, la fourniture des zones, les secondaires, la signature DNSSEC et la résilience DDoS comptent ; pour un resolver d’entreprise, ce sont le cache, le forwarding, les espaces de noms internes, les politiques, la confidentialité et la validation.

DNS dans l’exploitation de messagerie et d’identité

En messagerie, une réponse DNS devient directement un chemin de livraison. Un MTA émetteur interroge les RRsets MX du domaine destinataire, préfère la valeur la plus faible et traite les préférences identiques comme équivalentes. Ce n’est que lorsqu’aucun MX n’existe que le domaine lui-même constitue une destination implicite. Dès que des enregistrements MX sont présents, une valeur A/AAAA à l’apex du domaine ne les remplace pas. Chaque cible MX nécessite ses propres adresses et ne doit pas être un alias ; un domaine qui n’accepte pas de messagerie publie le Null MX 0 . (RFC 5321, section 5, RFC 2181, section 10.3, RFC 7505).

Les enregistrements PTR sont résolus via l’arbre d’adresses inversé. Les zones directe et inverse ont souvent des propriétaires différents ; les modifications doivent donc être coordonnées entre l’opérateur du domaine et celui de l’adresse IP. Un PTR est un nom, pas une preuve cryptographique d’identité. Les plateformes de messagerie destinataires peuvent utiliser une résolution directe/inverse cohérente comme signal, mais leur politique concrète de réputation ou d’acceptation n’est pas une propriété DNS.

SPF, DKIM et DMARC utilisent DNS comme canal de publication, mais définissent leurs propres règles d’évaluation. SPF lit une seule charge utile TXT logique et limite les termes qui provoquent des requêtes DNS ; DKIM adresse les clés via des sélecteurs ; DMARC se trouve sous _dmarc. Ces mécanismes sont traités fonctionnellement dans SPF, DKIM et DMARC. L’administrateur DNS doit surtout maîtriser correctement pour eux le nom propriétaire, la répartition des chaînes TXT, la taille de réponse, le TTL, la délégation et les durées de cache négatif.

LDAP et Kerberos utilisent également souvent des enregistrements SRV pour découvrir les services. Un enregistrement SRV contient, outre la cible et le port, une priorité et un poids. Ces valeurs ne constituent pas une configuration universelle d’équilibrage de charge ; seuls les clients qui implémentent le mécanisme SRV correspondant les interprètent.

Diagnostic

Le diagnostic ne commence donc jamais par « DNS ne fonctionne pas », mais par le nom, le type, la classe, le serveur interrogé, le transport et le moment. Les resolvers d’entreprise, les resolvers publics et les serveurs autoritatifs peuvent fournir temporairement ou en raison du Split DNS et des politiques des réponses différentes. Cette divergence n’est pas du bruit de mesure, mais l’indice le plus important de l’endroit où le chemin de résolution diverge.

Interroger les RRsets de manière ciblée

$server = "192.0.2.53"
Resolve-DnsName example.ch. -Type SOA -Server $server -DnsOnly
Resolve-DnsName example.ch. -Type MX -Server $server -DnsOnly
Resolve-DnsName _dmarc.example.ch. -Type TXT -Server $server -DnsOnly
Resolve-DnsName 25.113.0.203.in-addr.arpa. -Type PTR -Server $server -DnsOnly

server=192.0.2.53
dig @"$server" example.ch. SOA +noall +answer +authority
dig @"$server" example.ch. MX +noall +answer +authority
dig @"$server" _dmarc.example.ch. TXT +noall +answer +authority
dig @"$server" -x 203.0.113.25 +noall +answer +authority

Resolve-DnsName peut forcer un serveur spécifique, un type d’enregistrement, le DNS pur et TCP. dig affiche en outre les flags, sections, RCODE, le serveur répondant et le temps de requête. Sans -Server ou @server explicite, c’est le resolver configuré qui est testé, et pas nécessairement la source autoritative.

Vérifier séparément TCP et DNSSEC

$server = "192.0.2.53"
Resolve-DnsName example.ch. -Type MX -Server $server -DnsOnly -TcpOnly
Resolve-DnsName example.ch. -Type DNSKEY -Server $server -DnsOnly -DnssecOk

server=192.0.2.53
dig @"$server" example.ch. MX +tcp
dig @"$server" example.ch. DNSKEY +dnssec
delv @"$server" example.ch. MX

delv utilise la logique de resolver et de validateur BIND pour vérifier une chaîne DNSSEC. Une requête réussie avec +dnssec prouve en revanche uniquement que des données DNSSEC ont été demandées et fournies ; elle ne valide pas automatiquement la chaîne. Le test TCP séparé détecte les pare-feu qui autorisent UDP/53 mais bloquent TCP/53.

Vider de manière ciblée les caches locaux

Clear-DnsClientCache

sudo resolvectl flush-caches
resolvectl statistics

Clear-DnsClientCache vide le cache du client DNS Windows. resolvectl contrôle le cache de systemd-resolved; sur les systèmes équipés de nscd, dnsmasq, d’un Unbound local ou d’un cache applicatif, un autre cache est responsable. Un vidage du client ne modifie jamais le cache d’un resolver en amont.

Attribuer le scénario d’erreur au point de transition

Monitoring et critères d’exploitation

Le monitoring doit reproduire le même chemin. Une seule recherche A contre le resolver local par défaut ne détecte ni une délégation défectueuse, ni TCP bloqué, des signatures expirées ou un secondaire avec un Serial ancien. Pour la messagerie et l’identité, les signaux suivants doivent donc au minimum être relevés séparément :

• réponses autoritatives de chaque NS publié via UDP et TCP, y compris bit AA et SOA Serial ;
• délégation parent, RRset NS enfant, Glue et, pour les zones signées, transition DS/DNSKEY ;
• latence récursive, taux de cache hit, taux de timeout, SERVFAIL, REFUSED et NXDOMAIN ;
• taille de réponse, troncature, erreurs EDNS et repli TCP ;
• dates d’expiration des RRSIG, état du rollover de clés et files d’attente de signature ;
• succès de NOTIFY, AXFR et IXFR ainsi que l’ancienneté de la zone sur chaque secondaire ;
• RRsets fonctionnels tels que MX, adresses A/AAAA associées, PTR et noms TXT nécessaires à l’authentification de la messagerie.

Un test synthétique doit vérifier à la fois le chemin normal du client et la source autoritative. C’est la seule façon de distinguer si une perturbation se trouve dans le jeu de données publié, la délégation, le cache d’un resolver ou l’application.

Sécurité et domaines de défaillance

Les deux rôles de serveur requièrent des mesures de protection différentes. La récursion ne doit être accessible qu’aux clients de confiance ; un resolver ouvert peut être utilisé pour des attaques par réflexion et amplification. Les serveurs autoritatifs doivent en revanche rester accessibles dans le monde entier, mais ne doivent pas résoudre récursivement des noms tiers arbitraires. Mélanger les rôles augmente la surface d’attaque et rend les causes de charge plus difficiles à identifier (RFC 5358).

DNSSEC protège les RRsets publiés contre des modifications non détectées, mais ni le processus serveur ni la disponibilité. TSIG authentifie des messages DNS individuels au moyen d’une clé partagée et est notamment utilisé pour les mises à jour et les transferts de zone ; il ne constitue pas une signature publique des données de zone (RFC 8945). Les ACL de transfert, secrets TSIG et clés privées DNSSEC sont des objets de protection distincts.

Le Split DNS et les réponses de politique peuvent être nécessaires, mais créent plusieurs vérités pour le même QNAME/QTYPE. Il faut documenter au minimum le critère d’attribution, la zone source, le chemin de forwarding, le comportement DNSSEC et le monitoring par vue. Sinon, une divergence voulue sera interprétée lors de la prochaine perturbation comme une erreur de cache ou un problème de réplication.

Histoire technique

Avant DNS, Internet distribuait des tables d’hôtes gérées de manière centralisée. Avec l’augmentation du nombre de réseaux, d’hôtes et d’opérateurs indépendants, cette méthode est devenue un goulot d’étranglement. En 1983, Paul Mockapetris a décrit dans RFC 882 et RFC 883 un service de noms hiérarchique et délégable. RFC 1034 et RFC 1035 ont remplacé cette version en 1987 et constituent encore, sous STD 13, le cœur du système.

La première implémentation de serveur fonctionnelle, Jeeves, a tourné en 1983/84 sur des systèmes DEC-TOPS-20. Peu après, l’University of California, Berkeley, a créé sous financement DARPA le Berkeley Internet Name Domain Package BIND pour Unix. BIND 8 est apparu en 1997, BIND 9 en septembre 2000 comme une réécriture majeure. ISC documente cette histoire dans A Brief History of the DNS and BIND.

Le protocole s’est développé progressivement sans remplacer le cœur hiérarchique : NOTIFY et IXFR ont accéléré la synchronisation des zones dans les années 1990, EDNS a étendu le modèle de message en 1999 et a été consolidé plus tard dans RFC 6891, DNSSEC a reçu en 2005 les mécanismes DNSKEY/DS/RRSIG aujourd’hui fondamentaux, et des transports de resolver chiffrés sont venus s’ajouter avec DoT, DoH et DoQ. DNS n’est donc pas un protocole figé de 1987, mais un système extensible dont la rétrocompatibilité et les longs états de cache façonnent chaque modification en exploitation.