Résumé

  • Le greasing envoie périodiquement des valeurs non attribuées pour obliger les serveurs et intermédiaires DNS à tolérer l’inconnu avant qu’une vraie extension en dépende.
  • Une relance sans extension protège l’utilisateur, mais elle doit rester liée à l’échec initial ; sinon, la récupération de disponibilité supprime l’indice nécessaire à la réparation.

La première requête expire. Elle contenait une valeur DNS non attribuée choisie pour tester l’extensibilité. Le résolveur recommence sans cette valeur, reçoit une réponse et la remet à l’application. Dans la métrique finale, la résolution a réussi en 180 millisecondes.

Le service est disponible. Le protocole, lui, vient de révéler une fracture. Si le journal ne garde que la réponse finale, cette fracture cesse d’exister pour l’opérateur.

La révision 03 de Greasing Protocol Extension Points in the DNS cherche précisément à rendre ces fractures visibles avant qu’une extension réelle en paie le prix. Daté du 6 juillet 2026 et expirant le 7 janvier 2027, le texte est un Internet-Draft actif du groupe DNSOP, à visée informative. Ce n’est pas une RFC, une attribution IANA ni une mesure de déploiement. Plusieurs sections restent ouvertes, notamment les plages réservées, le comportement détaillé, le repli et la télémétrie.

Tester l’inconnu avant qu’il devienne indispensable

Un point d’extension n’existe pas seulement parce qu’un registre contient des cases libres. Il existe si les logiciels et les équipements traversés acceptent une valeur qu’ils ne connaissent pas selon la règle prévue par le protocole.

Avec le temps, l’expérience quotidienne pousse dans l’autre sens. Les implémentations ne voient que les valeurs attribuées. Un pare-feu fige une liste. Un proxy interprète un champ plus étroitement que la spécification. Un serveur considère l’inconnu comme une erreur. Aucun incident n’apparaît tant que le trafic réel reste dans l’ensemble ancien.

Le greasing introduit volontairement une valeur non attribuée pendant qu’elle n’a pas encore de sémantique. Un récepteur conforme doit la tolérer là où l’inconnu est conçu pour être ignoré. Une défaillance signale qu’un futur changement risque d’être bloqué.

Le projet recense plusieurs surfaces : le dernier drapeau d’en-tête DNS, Opcode, la version EDNS, les drapeaux EDNS, Class, le type d’enregistrement et le code d’option EDNS. Leur taille et leur structure diffèrent. Une position d’un bit ne peut pas recevoir la même politique qu’un registre de 65 536 valeurs. Une option EDNS exige aussi des données arbitraires, pas seulement un code inconnu.

RCODE et Extended RCODE sont écartés. Ils expriment un état produit par le répondant ; les modifier changerait l’interprétation de la réponse. Le greasing n’est sûr que lorsque le traitement de l’inconnu est déjà borné.

La relance est un second événement

Le projet recommande en général de recommencer sans l’extension non attribuée lorsqu’une requête graissée échoue. Une exception apparaît quand le test construit une requête différente, par exemple un nouveau type d’enregistrement : retirer le type ne répète plus la même opération.

Dans le cas ordinaire, le repli est utile. Il évite qu’un test de maintenance rende le nom indisponible. Mais son succès ne remplace pas l’échec. Il ajoute une observation de contrôle : sous une condition presque identique, sans la valeur inconnue, le chemin a répondu.

La paire apporte davantage qu’un échec isolé. Elle implique la différence testée. Elle ne localise pas automatiquement le responsable. Le serveur faisant autorité, un répartiteur, un proxy, un pare-feu ou un autre intermédiaire peut avoir rejeté le paquet. Deux tentatives peuvent aussi atteindre des instances anycast ou des états de cache différents.

Une trace défendable relie les deux requêtes et conserve la destination, la valeur, le point d’extension, le transport, l’instant, la réponse ou l’expiration, l’identité de serveur disponible et le résultat applicatif. « Réussi après relance » ne suffit pas.

Le parallèle évite la latence, pas l’incertitude

Pour ne pas faire attendre l’utilisateur, le résolveur peut envoyer une requête ordinaire et une requête graissée en parallèle. L’ordinaire sert la résolution ; l’autre ne sert qu’à mesurer. Une petite fraction du trafic peut suffire à construire une vue.

Ce choix protège mieux la latence, au prix de requêtes supplémentaires. Il crée aussi deux expériences. Pour comparer leurs résultats, il faut savoir si elles ont suivi des conditions assez proches. Le même nom et la même seconde ne garantissent pas la même instance anycast, le même chemin, le même cache ou la même politique de limitation.

La requête témoin réussie renforce l’hypothèse d’une intolérance à la valeur ajoutée. Elle ne donne toujours pas l’adresse du composant fautif. L’observabilité doit préserver ce degré d’incertitude au lieu de transformer une corrélation en verdict à distance.

Le repli peut devenir une surface de rétrogradation

La récupération de disponibilité a un autre coût. Une future extension peut porter une propriété de sécurité. Si un attaquant provoque un échec dès que cette extension apparaît, le résolveur peut apprendre à recommencer sans elle. Le service continue alors en abandonnant silencieusement la protection.

Le but du greasing est d’identifier les chemins intolérants assez tôt pour les réparer et réduire le besoin de repli. Il ne doit pas institutionnaliser une permission permanente de supprimer tout ce qui échoue.

Une politique de repli a donc besoin d’une échéance, d’un propriétaire et d’un critère de retrait. Les tableaux de bord doivent distinguer le nombre d’utilisateurs protégés par la reprise et le nombre de chemins qui exigent encore cette reprise. Le premier ne peut pas masquer le second.

Aléatoire ou réservé, chaque choix déplace le risque

Choisir au hasard dans l’espace non attribué oblige les récepteurs à appliquer une règle générale. Mais une valeur libre aujourd’hui peut recevoir une vraie sémantique demain. Un logiciel ancien peut continuer à l’émettre comme test ou à l’ignorer parce qu’il l’a apprise comme bruit.

Une plage réservée évite la collision et rend le test identifiable. Elle peut aussi devenir une exception codée en dur : la plage de test passe, tout autre inconnu échoue. Le mécanisme anti-ossification devient lui-même ossifié.

La révision 03 ne tranche pas. Elle expose les avantages et les défauts, note que certains registres sont trop petits ou structurés en sous-espaces, et laisse la section des valeurs réservées inachevée. Aucun rapport ne doit présenter une plage comme décidée.

Une date de fin de test peut réduire le risque des valeurs aléatoires. Mais la date n’arrête pas un équipement ancien qui n’a jamais reçu la mise à jour. L’état du registre, la version logicielle et la configuration active forment une chaîne de garde. « Non attribué à la compilation » n’est pas « non attribué lors de l’envoi ».

Un échantillon n’est pas la population

Le projet évoque « peut-être une requête sur mille » comme ordre de grandeur interrogatif, pas comme norme. Un résolveur à grand volume peut obtenir un signal avec peu de duplication. Cela ne transforme pas l’échantillon en recensement de l’écosystème.

Les noms populaires, grandes plateformes autoritatives, régions dominantes et heures de pointe peuvent être surreprésentés. Les anciens systèmes rarement interrogés peuvent manquer. Agréger plusieurs opérateurs élargit la vue, mais leurs politiques de sélection, transports, clientèles, chemins anycast et seuils diffèrent.

Un taux de panne sans dénominateur ni plan d’échantillonnage emprunte la précision des nombres. La meilleure restitution peut être une carte de populations testées, avec provenance, plutôt qu’un pourcentage mondial.

DNS Error Reporting pourrait signaler un comportement déficient à un opérateur autoritatif. Le rapport reste une assertion du résolveur, soumise à ses propres contraintes de livraison et d’anti-usurpation. Il ouvre une enquête ; il ne condamne pas un serveur.

Le répondant ne voit pas forcément l’effet

Un serveur faisant autorité peut lui aussi renvoyer un drapeau, une option, une version EDNS ou un type inattendu. Ce sens est plus risqué. Le serveur ignore souvent si le demandeur a accepté, essayé un autre serveur, échoué ou provoqué un abandon dans l’application.

L’émission est un fait local. L’acceptation et le résultat sont ailleurs. Des expériences ciblées peuvent fermer la boucle avec des clients contrôlés ou des retours utilisateurs. Sans cela, le silence est ambigu. Le projet recommande donc de désactiver par défaut le greasing initié par le répondant.

Enfin, un choix de valeurs prévisible peut servir d’empreinte à un produit ou une version de résolveur. La variabilité protège l’extension, mais elle doit aussi limiter ce nouveau signal d’identification.

La réussite ne se mesure pas au nombre de reprises qui ont sauvé l’utilisateur. Elle se mesure à la capacité de conserver le premier échec, de trouver le bon point de contrôle, de réparer, puis de retirer le repli avant qu’une vraie extension dépende du chemin. Sans ce cycle, la récupération devient une machine à rendre l’ossification invisible.

Sources