Résumé

  • La RFC 9520 oblige les résolveurs à mettre en cache un échec de résolution pendant au moins une seconde et au plus cinq minutes. Une entrée correspondante bloque le travail sortant ; elle ne prouve ni NXDOMAIN ni NODATA.
  • L’échec n’est établi que si aucun serveur et aucun transport disponible ne fournit de réponse utile. Une seule donnée exploitable, délégation descendante ou réponse négative valable suffit à l’écarter.
  • Le dossier probant doit conserver les chemins essayés, les répétitions, le regroupement des clients, la clé et la portée du cache, le recul temporel, les requêtes vers les ancêtres évitées et la première sonde de reprise.

Une panne chez Facebook, une onde de charge chez les autres

Le 4 octobre 2021, une commande de maintenance destinée à évaluer la capacité du réseau dorsal de Facebook a involontairement déconnecté les centres de données de l’entreprise. Le compte rendu technique de Meta précise que les sites DNS faisant autorité ont alors retiré leurs annonces BGP : incapables de joindre les centres de données, ils se considéraient en mauvaise santé. Les serveurs DNS continuaient de fonctionner, mais l’Internet ne disposait plus d’un chemin pour les atteindre.

Le silence n’est pas resté confiné à ces serveurs. Verisign a observé environ 7 000 requêtes ordinaires par seconde sur ses infrastructures .com et .net pour facebook.com, instagram.com et whatsapp.net. Pendant la panne de presque six heures, le débit a dépassé 900 000 requêtes par seconde. Les sources de résolution Google et Cloudflare les plus actives ont atteint, pour ces noms, près de 7 000 et 2 000 fois leurs débits habituels respectifs.

Les délégations parentes n’avaient pas changé. Les redemander ne pouvait pas rétablir les routes retirées par l’opérateur du domaine enfant. Pourtant, la répétition des essais a transféré la charge d’une zone injoignable vers une infrastructure parente saine. La question opérationnelle n’était donc pas seulement « pourquoi Facebook ne répond-il plus ? », mais « à quel moment un résolveur doit-il cesser d’ajouter du bruit à une panne qu’il ne peut réparer ? »

La RFC 9520 répond sans donner au silence une valeur qu’il n’a pas. Lorsque toutes les voies disponibles ont échoué, le résolveur doit conserver temporairement cet échec. Tant qu’une requête correspond à l’entrée non expirée, aucune requête sortante équivalente ne doit être émise. C’est un mécanisme local de contention, pas une déclaration sur le contenu de la zone.

NXDOMAIN affirme que le nom effectif n’existe pas ; NODATA affirme que le nom ne possède pas le type demandé. Un échec de résolution affirme seulement que la machine n’a obtenu aucune information utile sur cette existence. Le premier couple relève d’une preuve DNS négative. Le second justifie uniquement une pause de travail, limitée dans le temps et réversible.

Pas d’échec tant qu’un chemin utile subsiste

Un résolveur dispose rarement d’un seul interlocuteur. Un client peut connaître plusieurs services récursifs. Un résolveur itératif peut trouver plusieurs serveurs NS, plusieurs adresses par NS et, parfois, plusieurs transports pour la même adresse. L’échec d’un paquet, d’une adresse ou d’une session ne suffit donc pas.

Pour la RFC 9520, une réponse utile contient soit les données demandées, soit une délégation vers une zone descendante, soit une indication valable que les données n’existent pas au nom interrogé. Si un seul serveur disponible fournit l’un de ces résultats, la résolution n’a pas échoué. L’opérateur doit alors pouvoir produire l’inventaire des adresses et transports éligibles, l’ordre des essais, leur début et leur fin, ainsi que le résultat terminal de chacun.

La répétition reste possible, mais elle est plafonnée. Pour une même question, une même adresse et un même transport, deux nouvelles tentatives seulement sont autorisées après la première émission : trois requêtes au total. Un autre transport connu comme disponible peut être essayé sur la même adresse s’il respecte la politique de sécurité locale. La RFC ne fixe aucun délai universel ; elle note que les implémentations utilisent souvent des valeurs allant approximativement de trois à trente secondes.

Ce choix local est légitime parce que les délais, les établissements de transport, les points anycast et les engagements envers les clients diffèrent. Il n’autorise pas l’opacité. La configuration, le chemin concerné et la durée effectivement observée doivent rester dans le relevé. Une ligne échec serveur sans la liste des possibilités encore ouvertes ne démontre pas que la résolution était terminée.

SERVFAIL n’est pas une explication complète

SERVFAIL couvre de nombreuses situations. Un serveur faisant autorité peut ne plus posséder de copie valable de sa zone. Un résolveur récursif peut avoir échoué à joindre l’amont ou à valider DNSSEC. REFUSED traduit souvent une politique : service non autoritaire pour ce nom, source refusée par une liste de contrôle ou requête interdite. Un délai dépassé ne dit que l’absence de réponse avant l’échéance locale. Une erreur ICMP, un refus TCP ou un échec de négociation TLS peut interrompre le transport plus tôt.

Les boucles de délégation et d’alias ont encore une autre mécanique. Deux zones peuvent dépendre l’une de l’autre pour l’adresse de leurs serveurs ; des CNAME ou DNAME peuvent ramener le traitement à son point de départ. Les validations DNSSEC peuvent échouer à cause d’une signature, d’une clé, d’une preuve de non-existence ou du temps. FORMERR peut signaler un problème de message ou de compatibilité EDNS.

Le cache peut conserver ces catégories séparément, mais il ne reçoit qu’un effet commun : suspendre les requêtes sortantes correspondantes durant une période bornée. Il ne doit pas transformer REFUSED en SERVFAIL, un échec DNSSEC en réponse validée, ni un manque d’information en inexistence du nom.

Les erreurs DNS étendues de la RFC 8914 permettent d’ajouter un contexte comme Cached Error, No Reachable Authority ou DNSSEC Bogus. Elles sont utiles dans les journaux et les réponses aux clients. Elles ne modifient pas le traitement du RCODE. Leur précision descriptive ne les transforme ni en preuve signée ni en nouvelle autorité.

Regrouper la demande avant qu’elle ne devienne une attaque involontaire

Si les serveurs d’un nom très demandé deviennent muets, des centaines de clients peuvent présenter le même triplet QNAME, QTYPE, QCLASS pendant que le premier essai attend son délai. Un résolveur qui regroupe les demandes rattache ces clients à une seule résolution en cours. Un résolveur qui ne le fait pas lance autant de transactions amont, puis répète chacune d’elles.

La différence peut être énorme. L’expérience présentée à DNS-OARC 35 et reprise dans la RFC 9520 a mesuré environ 50 requêtes par seconde pour un domaine de botnet lorsque l’autorité répondait normalement. Quand tous ses serveurs renvoyaient SERVFAIL, le débit atteignait environ 60 000 requêtes par seconde. La racine et le TLD recevaient eux aussi davantage de trafic alors que leurs délégations demeuraient inchangées.

Le regroupement réduit également un risque de falsification. La RFC 5452 explique que plusieurs questions équivalentes ouvertes en même temps augmentent la surface d’une attaque dite des anniversaires : une réponse forgée peut correspondre à l’une quelconque des transactions. La discipline comporte donc trois contrôles distincts : regrouper les demandes identiques, limiter les essais par adresse et transport, puis mettre en cache l’échec épuisé.

Leur chronologie ne se confond pas. Le regroupement décide combien de transactions vivent simultanément. Le plafond décide combien de travail un chemin reçoit. Le cache décide combien de temps les demandes futures restent locales. La conformité au troisième ne prouve pas la présence des deux premiers.

Entre une seconde et cinq minutes, le coût de la reprise

Chaque échec doit être conservé au moins une seconde et jamais plus de cinq minutes. La durée minimale devrait être configurable. En cas d’échecs persistants, un recul linéaire ou exponentiel peut augmenter la durée, toujours sous le plafond de cinq minutes.

Un intervalle long protège mieux les serveurs et les parents contre la répétition, mais il peut retarder la découverte d’une réparation transitoire. Un intervalle court favorise la reprise, au prix d’un trafic supérieur pendant une panne durable. Le recul n’est donc pas seulement un gain de capacité ; il contracte une dette de reprise.

Une entrée exploitable doit indiquer sa clé, sa portée, l’ensemble de causes, l’heure d’insertion, la durée choisie, l’étape de recul, l’expiration et la version de configuration. À l’expiration, une seule sonde contrôlée devrait tester le retour du service, au lieu de libérer toute la foule accumulée. La première réponse utile supprime la base du refus local. L’écart entre le retour réel d’une réponse possible et sa restitution au client doit être mesuré.

La structure du cache change la portée de la décision. Un échec de validation DNSSEC peut être indexé par nom, classe et type. Une adresse injoignable peut justifier une entrée liée à l’adresse. Le SERVFAIL d’un serveur ne condamne pas nécessairement tous les autres. La RFC 2308, à l’époque où ce cache était facultatif, définissait des portées précises par question et serveur. La RFC 9520 rend la fonction obligatoire mais laisse les détails d’implémentation ouverts : l’éditeur du logiciel doit donc documenter ce que chaque entrée immobilise.

Le parent n’est pas un bouton de réinitialisation

Lorsqu’aucun serveur d’une zone ne répond, certains résolveurs ont historiquement redemandé au parent l’ensemble NS. La RFC 4697 interdisait cette répétition agressive. La RFC 9520 élargit la règle : toutes les catégories de requêtes adressées au parent et aux autres ancêtres doivent être limitées comme celles destinées à la zone en panne.

Un parent sain peut répéter une délégation parfaitement exacte sans pouvoir réparer le réseau de l’enfant. Sa réponse n’est pas une instruction de recommencer indéfiniment. Éviter la requête ne signifie pas que la délégation est erronée ou périmée ; cela signifie seulement qu’une répétition identique, dans la fenêtre de panne, n’ajouterait pas d’information utile.

L’opérateur devrait compter les requêtes parentes et ancestrales évitées. Cette mesure montre où la panne aurait déplacé sa charge. Après expiration, une sonde contrôlée peut toujours découvrir une nouvelle délégation ou une nouvelle adresse. La limitation est protectrice parce qu’elle est bornée ; une interdiction permanente cacherait précisément le changement qui permet la reprise.

Le cache BAD de DNSSEC et l’impossibilité de faire confiance au TTL

La RFC 4035 autorisait déjà un cache BAD pour éviter de répéter des validations vouées à l’échec. Certaines erreurs de signature ou d’administration durent ; les redemander ne crée que du trafic. Mais une donnée qui n’a pas été validée ne fournit pas un TTL fiable. Le résolveur doit donc assigner une petite durée locale et protéger ce cache contre l’épuisement.

La RFC 9520 remplace l’autorisation par une obligation : les échecs de validation doivent être mémorisés. Cette règle ne permet toujours pas de restituer l’ensemble RR invalide comme une donnée sûre. Elle permet de conserver le fait que les essais récents n’ont produit aucune donnée acceptable.

Un EDE peut expliquer au client qu’il voit une erreur en cache ou une validation bogus. Le dossier technique doit néanmoins garder la chaîne, l’instant, la portée et la prochaine sonde. Un libellé intelligible n’est pas le substitut d’une preuve de signature.

Serve Stale répond avec des données ; le cache d’échec retient du travail

La RFC 8767 permet de rendre des données expirées lorsque leur actualisation échoue et qu’une politique locale autorise leur usage. Elle recommande notamment d’espacer les nouvelles tentatives vers une autorité défaillante, souvent par un délai de trente secondes. Son but est la continuité lorsqu’une ancienne réponse exploitable existe encore.

La RFC 9520 s’applique même sans ancienne réponse. Il peut s’agir d’un nom jamais demandé, d’un nouveau type ou d’un résolveur qui n’active pas le service de données périmées. La réponse stale dit : « cette donnée était utile et peut être réutilisée selon ma politique ». Le cache d’échec dit : « aucune voie n’a produit de donnée utile ; je ne répète pas ce travail avant l’échéance locale ».

Les deux états doivent apparaître séparément. Un client qui reçoit une ancienne adresse et un autre qui reçoit une erreur ne vivent pas la même continuité, même si le nombre de requêtes amont évitées est identique.

Le dispositif de protection peut devenir une cible

Un attaquant peut provoquer des échecs sur une multitude de noms ou de types afin de saturer la mémoire et le traitement du cache. Les opérateurs doivent borner les entrées et suivre leur nombre, leurs octets, les insertions, les évictions, la concentration par source ou par zone, les étiquettes aléatoires et le temps CPU consacré à leur classement.

Une seconde attaque vise la décision elle-même. Les messages de défaillance ne sont pas des données DNS signées. Une réponse forgée qui correspond à la transaction peut convaincre le résolveur de suspendre ses requêtes vers une autorité réelle. Le plafond de cinq minutes limite un épisode, mais des falsifications répétées peuvent le renouveler. D’où l’importance de conserver les détails du transport, de réduire les transactions ouvertes et de comparer les résultats entre serveurs et points d’observation.

Le cache est un disjoncteur assorti d’une charge de preuve. Sans borne, les répétitions deviennent une attaque distribuée contre l’autorité et ses parents. Sans portée ni expiration, la contention devient elle-même un déni de service.

Le relevé minimal d’un échec défendable

Conserver QNAME, QTYPE, QCLASS, l’instant initial et l’identifiant du groupe de clients. Nommer la coupure de zone, l’ensemble NS, les adresses, le point de vue du résolveur et chaque transport. Pour chaque essai : début, fin, rang de répétition, résultat brut et test de réponse utile.

Après épuisement, enregistrer séparément RCODE, erreur de transport, état DNSSEC et EDE. Ajouter la clé de cache, la portée, l’insertion, la durée configurée, l’étape de recul, l’expiration et la priorité d’éviction. Noter les requêtes parentes évitées, l’existence de données périmées et l’usage éventuel de Serve Stale.

Au niveau de la flotte, rapprocher le nombre de demandes clientes, de groupes joints et de requêtes réellement envoyées aux autorités et aux ancêtres. Publier le rapport d’amplification, la latence, le CPU, la mémoire et la cardinalité. À l’expiration, identifier la sonde, sa cible, la première réponse utile et le délai de reprise visible par le client.

Ce relevé maintient le choix au niveau de l’opérateur qui en supporte les conséquences. Il ne demande pas au parent, au registre ou à l’IETF de certifier un minuteur local. Il oblige le résolveur à expliquer pourquoi il a cessé de travailler et quand il a recommencé.

Sources