Résumé

  • Le profil IETF Datatracker de Ray Bellis affichait dix RFC au 5 août 2026, dont le RFC 10029 publié en juillet 2026. Il n'affichait alors aucun Internet-Draft actif. Ce relevé établit une activité documentaire, pas une invention individuelle ni un déploiement généralisé. [1]
  • Le RFC 5966, écrit par Bellis en 2010, a été remplacé par le RFC 7766, signé par cinq auteurs en 2016. Le texte plus récent exige la prise en charge de TCP dans une implémentation DNS générale complète et considère TCP comme un transport normal, pas seulement comme une solution de secours exceptionnelle. [3] [4]
  • Les RFC 7828 et 8490 rendent une partie de l'état des connexions persistantes visible : durée d'inactivité, établissement de session, échec, temporisation et fermeture. Ils définissent des mécanismes ; ils ne promettent pas qu'un serveur dispose toujours de ressources suffisantes. [5] [6]
  • Le RFC 8906 explique pourquoi l'absence de réponse est un problème d'exploitation. Perte de paquet, filtrage, fonction non prise en charge et limitation de débit peuvent produire le même silence pour le client. Le document préfère une réponse explicite lorsque les conditions le permettent. [7]
  • Les RFC 9619 et 10029 conservent une question DNS principale tout en permettant de demander des types supplémentaires. Le nouveau mécanisme indique ce qui a été traité et prévoit des requêtes séparées pour le reste. Publié récemment avec le statut Proposed Standard — une spécification proposée de l'IETF —, il ne doit pas être présenté comme déjà courant partout. [8] [9]

Ce qui se passe réellement après la saisie d'un nom

DNS signifie Domain Name System, le système qui relie des noms lisibles à des informations utilisables par les machines. Une application peut demander une adresse IPv4, appelée enregistrement A, une adresse IPv6, appelée enregistrement AAAA, ou d'autres données nécessaires pour trouver et sécuriser un service.

La demande passe généralement par un résolveur, c'est-à-dire le logiciel ou le service chargé de chercher la réponse. Un résolveur récursif consulte des serveurs successifs jusqu'à atteindre un serveur faisant autorité, celui qui publie les données officielles pour la zone concernée. Des caches peuvent raccourcir le trajet. Des proxys, pare-feu, répartiteurs de charge et équipements de traduction d'adresses peuvent aussi se placer au milieu.

Ces éléments appartiennent à des acteurs différents. L'éditeur du système d'exploitation écrit une partie du client. L'opérateur du résolveur choisit sa capacité et sa politique de reprise. Le détenteur du domaine maintient ses délégations et ses serveurs faisant autorité. Les réseaux intermédiaires appliquent leurs propres filtres. Un RFC coordonne leur langage ; il ne pilote aucun de ces systèmes.

Une réponse explicite permet à chaque partie de décider. « Ce nom n'existe pas » n'a pas le même sens que « cette opération n'est pas prise en charge ». Un message signalé comme tronqué indique que la réponse entière ne tient pas dans l'échange en cours. Un refus de connexion est différent d'une attente sans fin.

Le silence efface ces différences. Le résolveur peut attendre, réessayer, changer de serveur, retirer une extension ou passer à un autre transport. Chacune de ces réactions prend du temps. Une méthode qui finit par fonctionner peut même cacher la cause initiale, si seule la réussite finale est enregistrée.

Les travaux publics associés à Bellis reviennent souvent à cette frontière : rendre assez clair ce qu'un serveur a compris, accepté, terminé ou refusé pour que le système voisin sache quoi faire ensuite. Cette clarté n'est pas une forme de pouvoir central. Elle permet au contraire à des opérateurs indépendants de conserver leurs décisions tout en échangeant des faits compatibles.

TCP est devenu une capacité DNS ordinaire

Deux moyens de transport apparaissent souvent dans le DNS. UDP envoie un message sans établir de connexion durable. Pour de petites questions, il est rapide et économe. TCP commence par établir une connexion, puis permet d'échanger davantage de données et de réutiliser cette connexion. Il demande en contrepartie plus d'état, de mémoire et de gestion au serveur.

Une vieille simplification disait que le DNS utilise UDP, sauf pour les transferts de zone ou lorsqu'une réponse trop grande doit être reprise par TCP. Cette image peut pousser une équipe à traiter TCP comme une option secondaire. Or les réponses signées, les messages plus volumineux et la fragilité de la fragmentation ont rendu cette séparation insuffisante.

Le RFC 5966, publié en août 2010 avec R. Bellis comme auteur, fixait des exigences pour le transport DNS sur TCP. [3] En mars 2016, le RFC 7766, signé par John Dickinson, Sara Dickinson, Ray Bellis, Allison Mankin et Duane Wessels, l'a rendu obsolète. [4] Le document collectif plus récent exige qu'une implémentation DNS générale complète prenne en charge UDP et TCP. Il permet aussi à un résolveur de choisir TCP pour ses propres raisons d'exploitation, sans devoir d'abord échouer en UDP.

Ce remplacement est important. Un standard devenu obsolète n'est pas simplement effacé ; il dirige les lecteurs vers le texte qui le remplace. Bellis figure sur les deux documents, mais l'évolution appartient à une chaîne de travail plus large. Le second RFC apporte d'autres auteurs, d'autres considérations et une définition plus actuelle de l'interopérabilité.

Pour un utilisateur, la conséquence peut être très concrète. Le nom et l'adresse peuvent être corrects, mais un pare-feu qui laisse passer UDP et abandonne silencieusement TCP peut provoquer une page lente ou inaccessible. Un serveur peut répondre aux petits messages de test et échouer seulement sur une réponse plus grande. Dire que « le DNS fonctionne » après un seul essai ne suffit donc pas.

Le RFC ne prouve pas que tous les produits respectent l'exigence. Il donne une base de vérification. L'opérateur peut envoyer la même question par les deux transports, observer l'établissement et la réutilisation des connexions, comparer la réponse et vérifier si un refus est explicite ou se transforme en temporisation.

Le proxy est un intermédiaire capable de changer le sens

Un proxy DNS reçoit la question d'un client et la transmet à un autre service. De nombreux routeurs domestiques et réseaux locaux utilisent ce rôle. Pour l'application, le proxy ressemble au résolveur. En réalité, il doit conserver correctement les champs, les tailles, les codes de réponse, les extensions et les méthodes de reprise.

Le RFC 5625, publié en 2009 avec Bellis comme auteur nommé, présente des lignes directrices d'implémentation pour ces proxys. [2] Le document n'établit pas que chaque passerelle les suit. Il montre pourquoi un intermédiaire apparemment transparent doit être testé comme une partie active du chemin.

Un proxy peut réussir les requêtes A les plus simples et échouer face à une réponse signée plus grande, un type inconnu, une option EDNS ou une connexion TCP. EDNS est un mécanisme qui ajoute des capacités négociables au DNS sans modifier la question principale. Si le proxy supprime une option qu'il ne connaît pas ou transforme une erreur valide en silence, le résolveur peut accuser à tort le serveur faisant autorité.

Le test utile varie donc les conditions, pas seulement le nom demandé. Il compare UDP et TCP, messages ordinaires et étendus, réponses petites et tronquées, types connus et inconnus. Le but n'est pas d'obliger chaque vieux équipement à comprendre toute nouveauté. Il est d'obtenir une différence visible entre « non pris en charge » et « information disparue en chemin ».

L'attribution reste limitée : Bellis a écrit le document public. Les fabricants choisissent l'implémentation, les opérateurs choisissent le déploiement, et les sources ne donnent ni taux d'adoption ni classement de produits.

Une connexion persistante oblige à parler de ressources

Réutiliser une connexion TCP peut éviter de répéter son établissement pour chaque question. Mais le serveur doit garder des sockets, de la mémoire, des files d'attente et des informations sur chaque client. Fermer trop vite annule l'avantage ; garder tout ouvert indéfiniment peut épuiser la capacité.

Le RFC 7828, signé par Paul Wouters, Joe Abley, Sara Dickinson et Ray Bellis, définit l'option edns-tcp-keepalive. [5] Elle permet à un serveur d'indiquer une durée d'inactivité variable. Le client peut signaler son intérêt pour la réutilisation ; le serveur répond selon ses contraintes locales. Il peut même annoncer zéro lorsqu'il manque de ressources et veut que les clients ferment après les échanges en cours.

Cette valeur zéro n'est pas nécessairement une panne. Elle peut être une décision de protection explicite. Elle est plus utile qu'une fermeture inexplicable, car le client et l'équipe d'exploitation peuvent l'enregistrer. Le standard définit le sens du signal, mais il ne choisit pas une durée universelle et ne réserve aucune mémoire à la place de l'opérateur.

Le document mentionne aussi les sessions longues qui traversent une adresse anycast. Avec l'anycast, plusieurs sites annoncent la même adresse et le routage conduit le client vers l'un d'eux. Un changement de route peut donc perturber une connexion existante. Des équipements intermédiaires peuvent également mal gérer les options EDNS. [5]

Une équipe attentive mesure alors le temps d'établissement, le taux de réutilisation, la durée inactive, la cause de fermeture, les requêtes encore en attente et les différences entre sites. Le mécanisme ne garantit pas une meilleure disponibilité. Il rend une décision de ressources plus visible et donc plus facile à comparer au système en fonctionnement.

DSO donne un nom aux étapes d'une session

Une connexion TCP ouverte ne signifie pas que les deux extrémités ont accepté toutes les opérations de session. Pour traiter ce niveau, le RFC 8490 définit DNS Stateful Operations, ou DSO : un ensemble d'opérations DNS avec état pour les sessions persistantes. [6]

Le document, qui compte six auteurs dont Bellis, distingue plusieurs moments : connexion établie, demande de session, acceptation, rejet, temporisation, fonctionnement établi et arrêt. Il définit notamment des opérations de maintien de connexion, de délai avant nouvelle tentative et de bourrage destiné à limiter certaines fuites d'information. Une réponse indique le succès ou l'échec de l'opération principale.

Cette distinction évite de résumer tout incident par « la socket était ouverte » ou « la connexion a disparu ». Une tentative de session peut échouer avec un code explicite et laisser le DNS ordinaire continuer sur la connexion. Une absence de réponse pendant l'établissement mène à une temporisation et à l'abandon de la connexion ; selon le contexte, le client peut revenir sans DSO. [6]

Le mot anglais timeout, souvent traduit par temporisation ou délai dépassé, désigne le moment où un système cesse d'attendre parce que la limite prévue est atteinte. Il ne donne pas automatiquement la cause. Dans DSO, il correspond toutefois à une étape connue, différente d'un rejet reçu.

Le RFC ne prouve pas que DSO soit largement déployé. Il fournit des états que les journaux et les tests peuvent préserver. Une équipe qui voit « session refusée » possède un fait différent de celle qui ne voit qu'une panne DNS générique.

L'absence de réponse mélange plusieurs pannes

Le RFC 8906, écrit par Mark Andrews et Ray Bellis et publié en 2020, aborde directement les serveurs DNS qui ne répondent pas à des demandes bien formées. [7] Il décrit un problème opérationnel commun : depuis le client, la perte d'un paquet, un filtre, une extension inconnue, une limite de débit ou une implémentation défectueuse peuvent tous ressembler à une attente vide.

Le document recommande, hors conditions d'attaque, qu'un serveur faisant autorité réponde aux demandes bien formées. Il rappelle des réponses attendues pour des types, indicateurs, codes d'opération et requêtes TCP inconnus ou non pris en charge. Il reconnaît aussi qu'un serveur attaqué peut devoir limiter ou abandonner du trafic. [7]

Cette exception conserve l'autorité opérationnelle locale. Aucun RFC ne peut exiger qu'un serveur sacrifie sa disponibilité pour répondre sans limite. Mais si le silence devient le comportement normal, les résolveurs ne peuvent plus séparer une mesure de protection d'un défaut.

La reprise, ou fallback, est le chemin de remplacement utilisé lorsque la méthode préférée ne fonctionne pas. Après un silence sur une demande EDNS, un résolveur peut réessayer sans EDNS. Cela peut rendre le nom accessible, mais peut aussi retirer une capacité nécessaire à DNSSEC, le système de signatures DNS, ou à une extension récente. Le succès final masque alors une incompatibilité durable.

Le RFC relie aussi la réponse aux délégations. Une délégation indique quels serveurs font autorité pour une zone. Le document conseille aux opérateurs de la zone parente de vérifier l'accord entre les enregistrements NS de délégation et ceux publiés dans la zone déléguée. [7] Une liste périmée peut envoyer les clients vers un serveur qui ne parle plus au nom de la zone.

Une erreur explicite protège donc le budget de temps du client. Elle réduit le nombre d'hypothèses à essayer et permet de compter la cause. Elle ne garantit pas une réponse positive, mais transforme un échec en information exploitable.

Une question principale, plusieurs types supplémentaires

Le format DNS comporte un champ QDCOUNT qui compte les questions. Bien que l'ancien format laisse entrevoir plusieurs questions, les implémentations n'ont pas développé de comportement commun fiable pour cette pratique. Le RFC 9619, écrit par Ray Bellis et Joe Abley en 2024, clarifie qu'une requête DNS ordinaire contient généralement une question. [8]

Une application moderne demande pourtant souvent plusieurs données pour le même nom. Pour préparer une connexion, elle peut vouloir A, AAAA et HTTPS. Envoyer une requête séparée pour chaque type ajoute des échanges et du travail.

Le RFC 10029, écrit par Bellis et publié comme Proposed Standard en juillet 2026, conserve une question principale et ajoute une option EDNS qui énumère les types supplémentaires souhaités. [9] La réponse contient sa propre option indiquant les types complètement traités. Même si le message global est tronqué, un serveur conforme renvoie cette option pour une demande valide.

Le client n'est pas obligé de deviner ce qui manque. Si l'extension n'est pas comprise, si une erreur de format apparaît ou si un type n'est pas annoncé comme complet, il envoie une requête autonome pour ce type. L'ancien chemin reste donc disponible.

Cette efficacité potentielle a un coût. Une seule demande peut augmenter le travail du serveur et la taille de la réponse, donc le risque d'amplification lorsqu'une adresse source est usurpée. Le RFC demande des limites configurables et laisse leur valeur au contexte d'exploitation. [9]

Il serait prématuré de conclure que le mécanisme est déjà largement présent. La publication récente établit un comportement proposé et testable. Les implémentations doivent encore l'ajouter ; les opérateurs doivent choisir les limites, observer le taux de reprise et mesurer la charge réelle.

Une suite de documents, pas une conception privée achevée

Le profil Datatracker associait Bellis à dix RFC au jour de la consultation. [1] Cette liste ne constitue pas une biographie complète. Elle ne dit rien, à elle seule, sur ses activités privées, son emploi actuel ou la qualité de chaque déploiement.

La forme du crédit change au fil du temps. Les RFC 5625 et 5966 nomment Bellis comme auteur. Les RFC 7766, 7828, 8490, 8906 et 9619 ont plusieurs auteurs. Le RFC 10029 le nomme comme auteur tout en restant le résultat du processus de consensus de l'IETF. [2] [3] [4] [5] [6] [7] [8] [9]

Les documents se remplacent et se complètent. Le RFC 7766 rend le RFC 5966 obsolète. Le RFC 8490 prolonge les discussions sur les connexions persistantes par une structure de session. Le RFC 10029 s'appuie sur la clarification d'une question principale du RFC 9619. Cette chaîne laisse à d'autres la possibilité de relire, tester et modifier les règles.

La contribution attribuable à Bellis est donc une participation documentée à cette continuité. Elle ne justifie ni le récit d'un inventeur unique ni celui d'un opérateur central du DNS. Les standards enregistrent des comportements communs ; les serveurs, résolveurs, proxys et réseaux restent exploités séparément.

Ce qui reste à vérifier sur les réseaux vivants

Une publication ne met pas à jour un vieux routeur domestique. Elle n'ouvre pas automatiquement TCP dans un pare-feu et n'ajoute pas de mémoire à un serveur. Elle ne garantit pas non plus qu'un chemin anycast conserve une session longue ni qu'un résolveur expose clairement ses reprises.

Les nouvelles fonctions apportent leurs propres risques. DSO ajoute de l'état à protéger et à surveiller. Multiple QTYPEs peut réduire le nombre de demandes, mais augmenter la charge d'une demande unique. Une limite prudente peut laisser plusieurs types incomplets. Une reprise réussie peut cacher une faible prise en charge si les mesures ne regardent que le résultat final.

La leçon la plus solide de ce parcours est donc mesurable. Un standard écrit offre un point de comparaison, pas une preuve de résultat. Les équipes doivent confronter le texte aux paquets, aux réponses, aux états de connexion, aux journaux et aux délais ressentis par les applications.

Dans cette couche de réalité, la continuité ne vient pas du prestige d'un document ou d'une institution. Elle vient du fait que les systèmes en fonctionnement gardent des réponses précises, des délégations cohérentes, des limites explicites et des chemins de reprise testés. Les RFC facilitent cette coordination sans retirer aux opérateurs leur responsabilité.

Qui supporte le coût quand le DNS ne donne aucune raison

Une réponse DNS intéresse bien plus que l'équipe qui exploite le serveur. Le résolveur récursif doit décider s'il réessaie. L'application doit choisir entre attendre et afficher une erreur. Le service d'assistance reçoit le signalement de l'utilisateur. Le détenteur du domaine cherche si ses données ou sa délégation sont en cause. Un intermédiaire peut pourtant avoir supprimé le seul message qui aurait permis de localiser la panne.

Le coût du silence est ainsi réparti sur des acteurs qui ne contrôlent pas la décision initiale. Chaque résolveur invente une hypothèse, chaque application dépense une partie de son délai et chaque équipe recommence une enquête. Une réponse négative ou un code d'erreur consomme lui aussi des ressources, mais il concentre l'information au moment où le serveur connaît encore le contexte.

Cette différence touche directement les activités non techniques. Une boutique en ligne peut voir une ouverture de page retardée alors que ses serveurs d'application sont disponibles. Un système de courrier peut retarder une livraison parce qu'il ne sait pas si une destination est absente ou temporairement inaccessible. Un outil de supervision peut signaler plusieurs services à la fois lorsqu'ils partagent le même résolveur ou le même proxy. Ces exemples décrivent les conséquences générales du DNS ; ils ne sont pas des résultats privés attribués à Bellis.

Les équipes de sécurité ont une tension particulière à gérer. Répondre sans limite pendant une attaque peut aggraver la charge ou l'amplification. Ne jamais répondre aux fonctions inconnues transforme cependant la prudence en ambiguïté permanente. Le RFC 8906 préserve cette distinction : la protection en situation d'attaque reste nécessaire, tandis que le comportement ordinaire devrait fournir des réponses de protocole. [7]

Les responsables d'applications doivent aussi comprendre qu'un succès final ne clôt pas l'analyse. Si une requête EDNS silencieuse est suivie d'une requête plus simple qui réussit, l'utilisateur reçoit son contenu, mais la nouvelle capacité n'a pas traversé le chemin. Si une demande Multiple QTYPEs est suivie de plusieurs demandes séparées, l'interopérabilité est préservée, mais l'économie d'échanges n'a pas été obtenue. [9]

Pour le serveur, rendre l'échec explicite ne signifie pas tout révéler. Les journaux peuvent compter des états et des codes sans conserver indéfiniment les noms demandés par les utilisateurs. Les politiques de confidentialité et de durée de conservation restent locales. Ce qui importe pour le diagnostic est de ne pas réduire toutes les branches à un compteur de délai dépassé.

La même prudence vaut pour les chiffres de disponibilité. Un service peut annoncer un taux élevé de réponses finales tout en imposant plusieurs secondes de reprises à une petite partie des demandes. Un autre peut produire rapidement une réponse explicite d'indisponibilité. Le premier semble meilleur dans une mesure binaire, alors que le second donne peut-être aux applications une base plus nette pour changer de serveur ou avertir l'utilisateur.

Les documents associés à Bellis ne définissent pas le contrat commercial de ces services. Ils rendent seulement certains événements comparables : transport choisi, réponse reçue, session établie, valeur d'inactivité, type complètement traité et chemin de reprise. Les organisations peuvent ensuite fixer leurs propres objectifs à partir de ces événements.

Cette séparation évite aussi de transformer un registre de standards en autorité opérationnelle. L'IETF et le RFC Editor publient des textes, mais ils ne dimensionnent pas un résolveur, ne corrigent pas une délégation et ne filtrent pas un paquet. La responsabilité reste avec les personnes qui exploitent le code et peuvent observer les conséquences.

La question à surveiller n'est donc pas seulement le nombre d'erreurs. Il faut regarder combien de demandes ont changé de transport, combien de connexions ont été fermées pour ressources, combien d'extensions ont déclenché une reprise, quels serveurs restent silencieux et combien de types supplémentaires n'ont pas été traités. Une tendance qui augmente avant que les utilisateurs ne voient des pannes peut offrir le temps de corriger un proxy, une capacité ou une délégation.

Enfin, une réponse explicite facilite le passage de relais. L'équipe suivante peut relire un code et un état, reproduire la demande et comparer avant et après. « Rien n'est revenu » oblige au contraire à reconstruire toutes les possibilités. Dans un système distribué, cette capacité de transmission est une composante de la continuité aussi importante que la réussite immédiate.

Sources

  1. IETF Datatracker, profil de Ray Bellis.
  2. RFC Editor, RFC 5625 : DNS Proxy Implementation Guidelines.
  3. RFC Editor, RFC 5966 : DNS Transport over TCP — Implementation Requirements.
  4. RFC Editor, RFC 7766 : DNS Transport over TCP — Implementation Requirements.
  5. RFC Editor, RFC 7828 : The edns-tcp-keepalive EDNS0 Option.
  6. RFC Editor, RFC 8490 : DNS Stateful Operations.
  7. RFC Editor, RFC 8906 : A Common Operational Problem in DNS Servers: Failure to Communicate.
  8. IETF Datatracker, RFC 9619 : In the DNS, QDCOUNT Is (Usually) One.
  9. IETF Datatracker, RFC 10029 : DNS Multiple QTYPEs.