Résumé

  • La RFC 9539 est une expérience IETF permettant à chaque opérateur d’essayer unilatéralement DoT ou DoQ sur le saut entre résolution récursive et serveurs faisant autorité.
  • Le client accepte tout certificat et peut revenir à Do53. Le mécanisme protège surtout contre l’écoute passive ; il ne résiste ni au déclassement actif ni à l’interposition et ne remplace pas DNSSEC.
  • La capacité d’une adresse et la confidentialité d’une requête sont deux preuves différentes. Il faut conserver le transport gagnant, l’échec d’authentification, SNI, les temporisations, le motif du repli et la cohorte réseau.

Un succès mesuré avec le mauvais dénominateur

Imaginons un résolveur dont la table ne contient encore aucune expérience concernant l’adresse autoritaire X. Pour ne pas retarder son client, il lance la requête en clair sur le port 53 et, presque simultanément, une connexion DoT ou DoQ sur le port 853. La réponse Do53 arrive en premier. Elle correspond à la question en attente et devient la réponse traitée. La copie chiffrée de la question est marquée comme déjà satisfaite.

La négociation cryptographique réussit ensuite. L’adresse X obtient un état de succès récent ; les requêtes suivantes pourront éviter Do53 pendant la période de persistance. Pourtant, la première question a traversé le réseau en clair. Compter les adresses ayant réussi une négociation et compter les questions réellement transportées sous chiffrement ne produit pas le même résultat.

Cette différence est le cœur de l’exploitation. Une console peut annoncer que 90 % des IP autoritaires « prennent en charge le chiffrement » alors que les recherches froides, les changements de route et les sorties de temporisation exposent une part bien plus grande des questions. La RFC 9539 demande une expérimentation mesurable, pas une médaille de configuration.

Le certificat ne comble pas l’écart. Dans ce profil unilatéral, le résolveur doit accepter le certificat présenté. Il peut noter que le nom ou la chaîne n’ont pas été vérifiés, mais il ne doit pas rejeter le canal pour cette seule raison, car son repli immédiat en clair aiderait l’observateur passif que l’expérience cherche à gêner. Confidentialité de transport et identité de l’autorité restent séparées.

Une décision locale qui ne devient pas une obligation mondiale

La RFC 9539, publiée en février 2024 avec le statut Experimental, cible la portion située après le résolveur récursif. DoT et DoQ fournissent les transports ; le texte expérimental explique comment les essayer envers des IP autoritaires sans nouveau registre d’inscription.

Le serveur peut écouter sur 853 avant que ses clients ne s’y attendent. Le résolveur peut sonder une adresse obtenue par la résolution DNS normale avant que l’opérateur autoritaire n’ait annoncé une politique. Aucun vote de l’écosystème, aucune date de bascule et aucun enregistrement d’autorisation n’est nécessaire.

Cette adoption graduelle correspond à l’« opportunistic security » de la RFC 7435. Le clair constitue le point de départ ; chiffrer quand les deux extrémités le peuvent améliore la situation face à l’observation passive. Une politique explicite plus forte garde la priorité. Le modèle de Heng Lu conduit à la même discipline : la spécification commune reste limitée, les décisions ultérieures demeurent chez les participants qui exécutent le code, et l’adoption devient réelle par le déploiement plutôt que par la publication.

La limite évite une nouvelle hiérarchie de confiance. Offrir DoT ou DoQ ne modifie pas une délégation DNS. Une poignée de main réussie n’accorde aucun mandat à la machine sur 853. L’expérience ne défend pas contre un attaquant actif capable de couper l’essai chiffré ou de se placer entre les pairs. DNSSEC continue, séparément, à décider si les données DNS possèdent une chaîne valide.

L’état exact : source, destination et transport

La RFC conseille de mémoriser la capacité par adresse IP autoritaire. Un même nom NS peut conduire à plusieurs adresses ; un même service peut cacher plusieurs installations derrière une IP d’équilibrage ou d’anycast. Étendre le succès d’un nœud au nom NS entier provoquerait des tentatives chiffrées et des délais vers des nœuds qui ne sont pas encore prêts.

La clé d’état utile peut inclure l’adresse source du résolveur. Un répartiteur peut sélectionner son backend par IP cliente, et deux sorties du même résolveur peuvent atteindre des cohortes différentes. La preuve devient donc : telle source a joint telle destination avec tel protocole à telle heure. « Le serveur sait faire DoQ » est une généralisation qu’un seul essai ne justifie pas.

Le dossier conserve initiated, completed, status, last-response, les tickets de reprise, la session active, les questions associées et last-activity. Une reprise de processus ne ressuscite ni socket ni file d’attente, mais l’historique récent de capacité peut survivre. Cette distinction empêche un ancien état de session d’être utilisé comme présence actuelle.

Trois jours de persistance après succès, un jour de damping après échec et quatre secondes de timeout sont les valeurs suggérées par le document. Ce ne sont pas des constantes de sécurité. Un anycast en migration, un résolveur très chargé ou une liaison longue distance peut devoir les modifier. Ces choix doivent être publiés, car ils règlent la durée pendant laquelle un succès évite le clair et celle pendant laquelle un incident interdit un nouvel essai privé.

Plusieurs pannes, plusieurs décisions

Une négociation qui échoue place le transport en état fail, remet en Do53 les questions sans autre chemin et bloque un nouvel essai jusqu’à la fin du damping. Une erreur sur une connexion déjà établie mène également au repli.

Une fermeture propre ne dit pas la même chose. Le serveur autoritaire peut libérer les connexions les plus anciennes lorsque la mémoire se tend. Les questions restantes doivent être reprises ailleurs, mais la prochaine question peut retenter le chiffrement rapidement. Un timeout propre à une seule question n’est pas davantage une panne de toute la session ; une autre adresse ou un autre transport peut encore répondre.

Un indicateur binaire détruit ces nuances. Une alerte TLS peut révéler une incompatibilité. Un port silencieux peut être absent, filtré ou limité. Une fermeture propre peut prouver que le budget de ressources fonctionne. Un SERVFAIL bien formé est une réponse DNS, non un échec de transport. Pour chaque déclassement, le registre doit nommer l’événement, la question, l’heure, le chemin de secours et la date du prochain sondage.

Le repli en clair est assumé parce qu’aucun engagement authentifié n’existe. Pour fermer en cas d’échec, un futur protocole devrait fournir un signal résistant au déclassement, authentifier l’autorité et dire si l’engagement porte sur une zone, un nom de serveur ou un autre objet. Avant cela, transformer une option en obligation fail-closed donnerait à toute panne du port 853 un nouveau pouvoir d’interruption.

Trois preuves cryptographiques indépendantes

La première preuve porte sur le canal : les octets de cette session étaient-ils chiffrés ? La deuxième porte sur le pair : l’extrémité était-elle le serveur autoritaire attendu ? Le profil RFC 9539 ne l’établit pas. La troisième porte sur les données : les RRsets ont-ils été validés par DNSSEC ? Cette validation ne dépend pas du transport.

Une réponse DNSSEC valide en Do53 peut être authentique sans être confidentielle. Une réponse DoT accompagnée d’un certificat non vérifié peut être confidentielle contre un observateur passif sans authentifier le pair. Sans chaîne DNSSEC, elle ne prouve pas non plus l’origine des données. L’étiquette générale « DNS sécurisé » empêche de savoir quelle propriété manque.

SNI dispose de sa propre frontière. Lorsqu’une IP dessert plusieurs noms NS, un SNI visible peut révéler la relation de zone recherchée. La recommandation consiste à l’omettre ; ECH peut réduire la fuite s’il est nécessaire. Le padding EDNS de la RFC 7830, sa politique dans la RFC 8467 et la minimisation QNAME traitent respectivement la taille et la quantité de nom exposée. Aucun de ces outils n’authentifie le serveur.

L’adresse unique peut cacher un parc incohérent

Les réponses chiffrées et non chiffrées doivent provenir des mêmes données de zone. Taille, EDNS et bit TC peuvent varier à cause du transport ; le contenu DNS de fond ne doit pas diverger.

Un parc peut néanmoins offrir DoT de manière intermittente si le répartiteur envoie les connexions vers des backends à des stades différents. Un changement de route anycast produit le même symptôme. La RFC propose une activation rapide du parc, une affinité par IP cliente ou une sélection consciente des membres compatibles.

L’opérateur doit donc comparer les sources, sites et périodes. Il recherche les connexions établies sans réponse DNS, les alternances succès/timeout et les écarts de contenu au-delà des différences de transport autorisées. Un succès ne décrit qu’un chemin ; il ne certifie pas toute l’IP anycast.

Le reçu d’une question

Chaque ligne commence par l’identifiant de requête, QNAME, QTYPE, QCLASS et l’heure. Elle ajoute source du résolveur, destination autoritaire, contexte NS/zone, point d’observation, transports tentés, ports, ALPN et temps de négociation.

Elle désigne ensuite la réponse traitée et les files où la question restait en attente. Pour le canal chiffré : empreinte et forme du certificat, verdict d’identité, SNI/ECH, session ou reprise, early data et classe exacte de panne. Pour la politique : persistence, damping et timeout. Pour la réponse : octets ou hash, RCODE, flags et verdict DNSSEC.

La conclusion indique si la question a traversé Do53, à quel moment, pour quelle raison, dans quelle cohorte et quand le chiffrement redeviendra éligible. Le bilan agrégé compte les questions protégées par transport, pas seulement les IP ayant une fois négocié TLS.

Sources