Résumé

  • Le DNS décrit des noms, des délégations et des réponses. Il ne contient pas un indicateur universel permettant de savoir si deux sous-domaines appartiennent à une seule organisation ou à deux locataires sans lien. La Public Suffix List fournit cette information d’usage aux logiciels.
  • La liste distingue une partie liée aux délégations et politiques de registres d’une partie privée consacrée aux plateformes qui attribuent des sous-domaines à des utilisateurs indépendants. L’inscription de github.io n’en fait pas un domaine de premier niveau ; elle indique aux consommateurs de la liste que ses locataires doivent être séparés.
  • L’ouverture des contributions ne donne pas à chaque participant le pouvoir de modifier le résultat. Les mainteneurs authentifient le demandeur, examinent la finalité et fusionnent ou refusent la modification. Les navigateurs restent ensuite libres de choisir une version, une section et un rythme de mise à jour.
  • Une modification acceptée n’agit pas partout au même instant. Les copies incorporées dans les applications divergent. La bonne gouvernance consiste donc à rendre vérifiables quatre étapes différentes : la preuve fournie par l’opérateur du domaine, la décision amont, la version livrée par chaque logiciel et le comportement réellement observé chez les utilisateurs.

Analyse

Le DNS ne porte pas la réponse administrative

Un nom de domaine est une structure hiérarchique, mais cette hiérarchie n’est pas une carte complète des organisations. La racine délègue uk. Les règles du registre britannique rendent possible l’enregistrement sous co.uk. GitHub contrôle github.io tout en permettant à de nombreux projets de publier sous des noms qui se terminent de la même manière. Dans les trois cas, une application doit décider à quel niveau deux utilisateurs doivent être considérés comme indépendants.

La lecture naïve des deux étiquettes situées le plus à droite fonctionne pour exemple.com. Elle échoue pour exemple.co.uk, car co.uk forme la partie publique et exemple.co.uk est le domaine enregistrable. Elle échoue encore d’une autre façon pour projet.github.io, car github.io n’est pas un domaine de premier niveau mais sert de frontière entre des utilisateurs qui ne partagent ni compte, ni contenu, ni responsabilité.

Le groupe de travail DBOUND de l’IETF avait défini le problème avec une sobriété utile. Le DNS ne permet pas de marquer les relations administratives recherchées par les applications. Les noms et leur représentation publique ne suffisent pas à déterminer si deux domaines relèvent de la même autorité. La question n’est donc pas de découvrir dans le protocole une information qui s’y trouverait cachée ; elle est d’ajouter une connaissance extérieure, avec des limites explicites.

La Public Suffix List, ou PSL, est cette connaissance extérieure devenue commune. Le site du projet définit un suffixe public comme un nom sous lequel des internautes peuvent, ou pouvaient historiquement, enregistrer directement des noms. La norme URL du WHATWG montre le résultat avec github.io : ce nom est traité comme suffixe public, tandis que whatwg.github.io est un domaine enregistrable.

Cette classification ne modifie rien dans la zone DNS. Elle ne change pas le détenteur du domaine, ne déplace pas une délégation et ne crée pas un droit de propriété. Elle modifie la manière dont le logiciel consommateur calcule une frontière. Voilà la première limite à préserver : le registre DNS, le registre commercial du domaine, le détenteur du domaine privé et le mainteneur de la PSL ne réalisent pas la même opération.

La confusion devient politiquement séduisante lorsqu’une liste est largement utilisée. Une entrée influence des milliards de décisions automatisées ; on en déduit facilement que son mainteneur « gouverne les domaines ». C’est excessif. À l’inverse, dire qu’il ne s’agit que d’une documentation sans effet néglige la réalité du code. La position exacte se trouve entre les deux : la PSL est un registre de coordination dont l’effet dépend d’une adoption volontaire mais lourde de conséquences.

Le cookie révèle la chaîne de pouvoir

La protection des cookies fournit le cas le plus net. Un serveur peut demander au navigateur de conserver un cookie pour un domaine parent. Cette possibilité est légitime lorsqu’une organisation veut partager un état entre plusieurs de ses propres hôtes. Elle devient dangereuse si un locataire d’une plateforme peut déposer un cookie au niveau commun à tous les autres locataires.

RFC 6265 prévoit donc qu’un agent utilisateur configuré pour rejeter les suffixes publics refuse, sauf cas étroit, un cookie dont l’attribut Domain est lui-même un suffixe public. Le texte donne la raison : sans cette vérification, attacker.com pourrait perturber example.com en déposant un cookie pour com. Comme l’ensemble des suffixes évolue, le RFC recommande une liste à jour et désigne la ressource issue du projet Mozilla.

Le projet de révision RFC 6265bis conserve ce mécanisme et décrit plus directement son risque. La frontière des cookies dépend du domaine enregistrable, lequel dépend du suffixe public. Une liste obsolète peut laisser fuir des cookies malveillants ou sensibles entre des domaines qui devraient être séparés. Le document signale même une difficulté temporelle : une règle peut changer après la création d’un cookie, si bien qu’un état auparavant accepté ne serait plus accepté aujourd’hui.

Cette séquence distribue l’autorité. Le standard définit une règle et explique la menace. La PSL apporte une donnée évolutive. Le navigateur décide d’incorporer la donnée, de la mettre à jour et d’appliquer la règle. Le service web choisit la portée qu’il demande pour son cookie. L’utilisateur reçoit le résultat, souvent sans savoir que ces décisions existent.

Aucun acteur ne maîtrise l’ensemble. Le mainteneur de la PSL ne peut pas imposer une mise à jour au navigateur installé. Le navigateur ne peut pas garantir que le site a choisi une portée prudente. Le standard ne sait pas quel service privé ouvrira demain des sous-domaines à des clients indépendants. Le détenteur de github.io peut décrire son modèle, mais il ne peut pas modifier les versions anciennes déjà livrées dans des appareils abandonnés.

Une bonne analyse de gouvernance commence par cette cartographie, non par une proclamation abstraite sur le caractère « communautaire » ou « privé » du système. Le pouvoir se mesure à la décision concrète qu’un acteur peut prendre. La responsabilité devrait suivre la même ligne.

Une liste créée pour les navigateurs, reprise bien au-delà

Le site public du projet mentionne trois usages historiques : empêcher les supercookies, mettre en évidence la partie la plus importante d’un nom dans l’interface et classer correctement l’historique. Le guide technique d’ICANN ajoute l’isolation de processus ou de scripts, l’interprétation des noms et la découverte du domaine organisationnel pour DMARC. Des bibliothèques et des services s’en servent aussi pour regrouper du trafic, appliquer des limites, interpréter des certificats ou identifier ce qu’ils pensent être une organisation.

Cette réussite augmente le risque de glissement sémantique. Une frontière utile pour les cookies n’est pas automatiquement une preuve d’identité juridique. Un domaine enregistrable n’est pas nécessairement une société. Deux marques d’un même groupe peuvent utiliser des domaines enregistrables différents. Deux clients sans lien peuvent partager le même domaine parent. Un opérateur peut déléguer techniquement un nom sans céder le contrat commercial. Un système de messagerie, une autorité de certification et un service d’analyse n’ont pas la même définition du risque.

Le vocabulaire entretient parfois l’ambiguïté. « Suffixe public », « domaine organisationnel », « domaine enregistrable » et l’expression historique « effective TLD plus one » sont proches sans être interchangeables. RFC 8499 note d’ailleurs que la notion de suffixe public est controversée dans le DNS et qu’aucun signe inhérent au nom n’en révèle la qualité.

Il serait tentant de résoudre cette pluralité en instituant une autorité centrale capable de déclarer la frontière valable pour tous les usages. Ce serait remplacer une approximation transparente par une fiction institutionnelle. Les relations recherchées ne sont pas identiques. Le groupe DBOUND avait précisément admis que plusieurs solutions pourraient être nécessaires.

La PSL reste solide lorsqu’elle présente son résultat pour ce qu’il est : une représentation commune de frontières largement utiles, fondée sur des faits de registre et d’exploitation. Chaque consommateur doit encore démontrer que cette représentation convient à sa décision. Une autorité de certification ne peut pas justifier une règle d’émission uniquement par « le nom figure dans la PSL ». Un fournisseur de cloud ne peut pas transférer aux bénévoles la responsabilité d’une limite commerciale. Un outil d’analyse ne peut pas transformer un eTLD+1 en propriétaire économique sans preuve supplémentaire.

La limite n’affaiblit pas la liste. Elle protège sa crédibilité. Un instrument étroit peut être réutilisé, à condition que les réutilisateurs gardent la charge de leur propre règle.

Deux sections, deux types de faits

Le fichier principal est divisé en une section dite ICANN et une section privée. La première suit les domaines de premier niveau de la racine IANA et les structures d’enregistrement que leurs opérateurs publient. La seconde contient des domaines privés exploités comme des espaces de sous-domaines pour des utilisateurs qui ne se font pas confiance.

Le mot « ICANN » ne signifie pas qu’ICANN contrôle la liste. Le document de format reconnaît même qu’« IANA » aurait peut-être été un meilleur terme, mais qu’un renommage pourrait casser les intégrations existantes. Le guide OCTO-011 d’ICANN tranche l’ambiguïté institutionnelle : la PSL a commencé comme une initiative Mozilla, elle est aujourd’hui maintenue par un groupe de bénévoles extérieurs, et elle ne relève pas de la direction ou du contrôle direct d’ICANN, des fonctions IANA ou de l’IETF.

Mozilla est ici le sujet institutionnel à deux titres bien délimités : comme initiateur du projet et, par Firefox, comme implémenteur aval de grande portée. L’article examine les responsabilités que créent ces rôles lorsque le fichier commun devient du code exécuté. Ils ne font pas de Mozilla le propriétaire actuel de la liste communautaire et ne lui donnent aucun mandat sur les autres consommateurs.

La relation est donc probatoire, non hiérarchique. Pour les domaines de premier niveau, la liste peut récupérer ou vérifier des données officielles. Pour une structure sous un TLD, elle peut examiner la politique publiée par le registre et demander une confirmation. Elle respecte le principe d’une racine unique et refuse les racines alternatives. Cela ne transforme pas l’organisation qui fournit la preuve en administrateur du dépôt.

La section privée repose sur un autre type de fait. Le détenteur d’un domaine déclare qu’il attribue des sous-domaines à des parties indépendantes. Le DNS prouve qu’il contrôle le nom ; la documentation et les exemples décrivent la manière dont il l’exploite. La PSL encode ensuite cette réalité dans la même syntaxe de correspondance que les suffixes liés aux registres.

Cette combinaison offre une architecture intéressante. Le format et l’algorithme sont communs. Le fait local vient de l’opérateur qui le connaît. Les mainteneurs vérifient l’autorité et la conformité à la finalité. Les logiciels choisissent ensuite d’inclure ou non la partie privée. Il n’est pas nécessaire qu’une institution mondiale décide du modèle commercial des plateformes pour obtenir une isolation cohérente.

La conception doit rester réversible. Si une plateforme cesse d’offrir des sous-domaines indépendants, vend le domaine ou change complètement de service, l’ancienne entrée peut devenir trompeuse. La suppression ne doit pourtant pas être précipitée : des locataires, des redirections, des cookies et de vieilles applications peuvent persister. L’ajout et le retrait sont tous deux des transitions opérationnelles, pas de simples corrections typographiques.

Une contribution ouverte n’est pas une autorisation universelle

Le dépôt public permet à toute personne de proposer une modification. Cette ouverture élargit la capacité de détecter une erreur et rend la discussion vérifiable. Elle ne supprime pas la fonction de décision. Une ligne n’entre dans la source commune qu’après examen et fusion par les mainteneurs.

Les directives actuelles demandent une justification, un format correct, des exemples d’entrée et de sortie et une preuve de l’autorité du demandeur. Pour une entrée privée, la modification doit venir d’un représentant autorisé du détenteur. Pour les noms liés aux registres, les documents officiels et les contacts autorisés sont déterminants. Un enregistrement TXT dans le DNS, relié au numéro de la demande, constitue une preuve privilégiée. Des zones sensibles, par exemple des espaces gouvernementaux ou réglementés, peuvent faire l’objet de vérifications supplémentaires.

Le mécanisme sépare trois rôles que le langage de la participation mélange souvent. Un commentateur peut apporter une information pertinente. Un opérateur de domaine peut attester un fait sur son propre espace. Un mainteneur peut accepter ce fait dans le format partagé. Le premier n’acquiert pas le mandat du second parce qu’il a participé au fil de discussion ; le second ne commande pas le troisième parce qu’il contrôle le DNS ; le troisième ne devient pas propriétaire du domaine parce qu’il fusionne la modification.

Cette séparation est une forme de discipline institutionnelle. L’authentification ne mesure ni la popularité ni l’éloquence. Elle répond à une question délimitée : le demandeur est-il habilité à décrire l’exploitation du nom concerné ? La revue de finalité pose une autre question : cette exploitation justifie-t-elle un traitement comme suffixe public pour les usages annoncés ?

Le dépôt montre aussi les coûts de ce modèle. Les mainteneurs indiquent que la ressource est bénévole et mince, qu’elle n’offre pas de service client et qu’une entrée mal formée peut nuire aux cookies d’un site. L’avis du 6 mai 2026 impose le formulaire normalisé afin de conserver des attestations cohérentes dans le dossier public. L’avis du 27 mai 2025 refuse que la PSL serve à contourner une restriction de sous-domaines propre à Cloudflare.

Ces refus sont essentiels. Lorsqu’un fournisseur attache un avantage commercial à l’inscription, il crée une demande artificielle. Le demandeur peut chercher la PSL non pour isoler des locataires mais pour obtenir plus de certificats, un compte publicitaire différent ou une fonctionnalité de cloud. Si les mainteneurs acceptaient ces motifs comme finalité propre, une liste de sécurité deviendrait un guichet de politique commerciale sans mandat ni moyens adaptés.

La règle saine attribue la responsabilité au bon endroit. La PSL juge la frontière selon sa mission. Le fournisseur de produit assume la règle commerciale qu’il a construite autour du statut PSL. L’utilisateur ne devrait pas avoir à déformer la classification du domaine pour réparer une politique de fournisseur.

Sources

  1. Lu Heng, « Running-Code Primacy: The Patch Needed to Preserve the Internet’s Original Design »
  2. Présentation du projet Public Suffix List
  3. Dépôt source de la Public Suffix List et avis actuels des mainteneurs
  4. Directives de soumission et de validation de la Public Suffix List
  5. Format du fichier et sens des sections de la Public Suffix List
  6. ICANN OCTO-011, « The Public Suffix List: A Guide for TLD Administrators »
  7. RFC 6265, HTTP State Management Mechanism
  8. Projet IETF HTTPbis, Cookies: HTTP State Management Mechanism
  9. Norme URL du WHATWG
  10. Charte du groupe de travail IETF DBOUND
  11. RFC 8499, DNS Terminology
  12. Instantané Firefox de effective_tld_names.dat
  13. Avis PSL du 6 mai 2026 sur le formulaire normalisé et les attestations
  14. Avis PSL du 27 mai 2025 sur les restrictions Cloudflare étrangères à la finalité de la liste