Résumé

  • Le point terminal rend explicite la racine dans la forme de présentation stricte d’un nom DNS complet ; l’usage courant l’omet. Cette équivalence DNS ne s’impose pas d’elle-même aux politiques applicatives.
  • Le projet DNSOP en appel à commentaires recommande de stocker et d’afficher les noms complets sans ce point et exclut les simples opérations de chaîne. Un commentaire demande encore une règle exécutable pour comparer les deux formes.
  • CVE-2026-8924 fournit une preuve limitée mais concrète : dans curl, la variante avec point a contourné un contrôle fondé sur la Public Suffix List. Le problème est l’ordre des décisions, pas un pouvoir caché dans le signe de ponctuation.

Le point qui suit uk ne crée pas un nouveau domaine. Il représente la racine vide du DNS. RFC 9499 distingue une présentation stricte, où cette racine et son séparateur apparaissent, de l’affichage courant, où ils sont facultatifs et presque toujours absents. Le résolveur peut traiter les deux graphies comme le même nom absolu. Rien n’oblige cependant une base de cookies, un cache ou un vérificateur de certificats à partir de la même représentation.

C’est précisément l’intervalle que le groupe de travail DNSOP examine. Le 24 août, draft-ietf-dnsop-integration-04 est entré en appel à commentaires du groupe, avec une échéance au 7 septembre. Il s’agit d’un projet à vocation informative, pas d’un RFC approuvé. Son objectif est d’aider les applications qui emploient un nom du DNS mondial comme identifiant sans créer de collision ni fragiliser le DNS.

Le texte organise les risques autour du cycle de vie du domaine, de la validation du contrôle, de l’exhaustivité, de la synchronisation, de l’évolution du protocole, des interfaces de gestion et du soutien des types d’enregistrement. Il formule déjà une consigne nette : conserver et montrer les noms pleinement qualifiés sans le point final, sauf lorsqu’un domaine de recherche local est nécessaire. Il précise aussi qu’afficher, normaliser, comparer, encoder et décoder un nom exige un traitement spécialisé.

Cette orientation indique le bon lieu du problème, mais pas encore l’ordre testable de toutes les opérations. Dans sa réponse, Paul Wouters n’a pas fait objection à la publication ; il a toutefois regretté le manque de conseils techniques concrets. Parmi ses exemples figurent la comparaison avec ou sans point terminal, l’insensibilité à la casse du DNS, le passage entre A-label et U-label, les caches négatifs, les alias pendants et la conservation du nom demandé à travers CNAME ou DNAME. Wes Hardaker a soutenu le texte en le jugeant plus utile comme contexte que comme aide immédiate.

Tim Wicinski a également accepté sa progression tout en notant la proximité de certains passages avec les considérations opérationnelles. Ces prises de position ne constituent pas une décision collective.

La vulnérabilité CVE-2026-8924 donne un poids particulier au premier exemple. Dans son avis du 24 juin 2026, curl décrit une faille de faible gravité, présente des versions 7.46.0 à 8.20.0 et corrigée en 8.21.0. Un serveur hostile pouvait proposer un cookie pour un domaine avec point final, tel que co.uk., lorsque l’URL utilisée par curl comportait elle aussi ce point. Le contrôle de la Public Suffix List ne bloquait alors pas correctement le domaine trop large, et le cookie pouvait être transmis à des domaines sans rapport.

Le DNS n’avait pas besoin de produire deux destinations. La divergence se trouvait dans la façon dont une frontière de sécurité applicative recevait le nom. L’avis curl ajoute que le point terminal ne peut pas être placé dans le SNI TLS. Une même entrée pouvait donc être résolue, rangée dans une base de cookies et présentée à TLS selon des conventions textuelles différentes. CVE-2022-30115 avait déjà montré une divergence distincte dans l’état HSTS. Ce précédent ne prouve pas une défaillance générale ; il montre que la couture revient lorsque chaque sous-système canonise seul.

La casse et les noms internationalisés prolongent la difficulté. RFC 4343 impose l’insensibilité à la casse pour les étiquettes DNS ASCII ordinaires, mais avertit qu’un nom réutilisé hors du DNS peut devenir une clé sensible à la casse ou une entrée d’authentification. RFC 5890 sépare U-label Unicode et A-label ASCII compatible, tout en laissant hors de son champ la convention du point terminal. Abaisser la casse puis enlever le point n’est donc pas une politique universelle, surtout si une décision a déjà été prise avant cette transformation.

Une intégration vérifiable doit garder plusieurs reçus. Elle conserve l’entrée brute et le fait que la racine était explicite ; la suite d’étiquettes réellement analysée ; la forme canonique choisie pour une décision déterminée ; la version de la liste de suffixes, du profil IDNA ou de la règle de certificat ; enfin la décision et son effet observé. Un journal qui n’enregistre que la chaîne nettoyée efface justement l’écart qu’il faudrait expliquer.

Cette discipline empêche d’attribuer trop de pouvoir à un seul résultat. L’égalité de deux noms dans le DNS ne prouve pas la maîtrise du domaine. Une validation de contrôle ne vaut pas certificat pour tous les services. Un certificat ne donne pas toute autorisation applicative. Et l’acceptation d’un cookie ne prouve ni sa bonne destination ni son usage ultérieur.

L’appel à commentaires fait donc apparaître une question plus précise que « faut-il enlever le point ? ». Il faut savoir quel composant le retire, avant quelle décision et selon quelle version de politique. Si la forme canonique n’apparaît qu’après le contrôle du suffixe, de l’origine ou du droit d’accès, l’application n’a pas normalisé sa frontière de confiance. Elle a seulement rendu son journal plus propre.

Sources