Résumé

  • La RFC 1591 indiquait que l’IANA créerait l’Internet DNS Names Review Board (IDNB) pour trancher les désaccords non résolus sur la gestion d’un domaine de premier niveau ; ses décisions devaient s’imposer aux parties.
  • En 2017 puis en 2024, des documents du ccNSO ont indiqué que l’IDNB n’avait jamais été créé. Une politique distincte, aux décisions non contraignantes, a été adoptée en 2025 ; son statut restait « planification de la mise en œuvre » dans le rapport ICANN86 de mai 2026.

Une phrase de la RFC 1591 semble clore un débat avant même qu’il ne commence. Lorsque les parties en concurrence pour gérer un domaine de premier niveau ne parvenaient pas à s’entendre, l’Internet DNS Names Review Board devait intervenir comme instance de réexamen. Ses décisions seraient contraignantes. Cette phrase figure dans un texte publié par Jon Postel en mars 1994, au milieu d’un exposé sur la structure du DNS et la délégation des domaines.

La mention du comité surprend. La RFC 1591 ne se limitait pas à demander un registre techniquement compétent. Elle esquissait une procédure en cas de désaccord sur l’identité du gestionnaire, avec un organe capable de rendre une décision finale. Or des documents ultérieurs du ccNSO indiquent que l’IDNB n’a jamais été créé par l’IANA ni par une autre entité. Le texte décrivait donc une institution qui, d’après les archives rétrospectives, n’a pas vu le jour.

Le cadre de 1994 reste important. La RFC se classait comme « Informational » et précisait qu’elle ne définissait aucun standard Internet. Elle attribuait à l’IANA la coordination générale du DNS, tandis que l’Internet Registry central — alors l’InterNIC — assurait une grande partie de l’administration quotidienne. Chaque domaine devait avoir un gestionnaire désigné, disposant de serveurs de noms fonctionnels, d’un contact administratif local pour un domaine national et de la compétence nécessaire à l’exploitation.

La RFC qualifiait les gestionnaires de dépositaires d’un domaine, au service de la communauté nationale et de la communauté Internet mondiale. Elle jugeait les revendications de propriété inappropriées : les questions pertinentes portaient sur les responsabilités et le service rendu. Elle exigeait aussi un traitement équitable des demandeurs, sans avantage accordé aux clients d’un fournisseur de réseau lié au gestionnaire. Les sous-domaines devaient pouvoir exploiter leurs propres serveurs de noms, à condition que les informations publiées soient exactes.

La partie délicate venait ensuite. Les parties « significativement intéressées » devaient convenir que le gestionnaire proposé était approprié. L’IANA devait chercher à faire aboutir un accord et, en général, éviter de modifier une délégation si tous les concurrents n’y consentaient pas, sauf faute grave du gestionnaire. Les parties intéressées devaient avoir « une certaine voix » dans le choix. Mais le texte prévoyait aussi une délégation partielle si les candidats ne parvenaient pas à s’entendre ou si l’un d’eux ne pouvait représenter tout un pays. Pour ces désaccords, la RFC nommait l’IDNB et annonçait des décisions contraignantes.

Le texte distinguait ainsi la participation à la procédure de l’acte qui tranche le conflit. Les parties concernées devaient être entendues ; leur présence ne suffisait pas, à elle seule, à résoudre le litige. Le gestionnaire devait remplir des obligations d’exploitation tandis que l’IANA gardait un rôle de coordination. L’IDNB devait fournir l’étape d’arbitrage en cas d’échec de l’accord. Savoir si cette étape a existé n’est donc pas un détail historique : cela indique si la procédure écrite avait une destination réelle.

En juin 1996, un Internet-Draft de Postel reprit l’IDNB dans un autre débat. Il proposait une structure de contrôle pour les domaines internationaux tels que COM, ORG et NET, et étendait le rôle du comité aux recours techniques concernant cette proposition. Le projet répartissait aussi les responsabilités entre l’IANA, l’IETF, l’ISOC et un groupe ad hoc. Mais le Datatracker classe le texte comme Internet-Draft individuel, non approuvé par l’IETF et sans statut dans son processus de normalisation. Il a expiré en décembre 1996.

Il montre que l’idée du comité a été reprise dans une proposition, pas que l’organe a été constitué ni que le projet est devenu une politique.

L’absence a ensuite été formulée explicitement. Un groupe de travail du ccNSO, dans sa charte adoptée en mars 2017, indiquait que l’IDNB n’avait jamais été créé. Il constatait aussi l’absence de mécanisme de recours pour les décisions de délégation, de transfert ou de révocation de ccTLD. Le rapport final du ccNSO de septembre 2024 reprenait ce constat et indiquait qu’aucun réexamen indépendant ne s’appliquait alors à ces décisions. Ces documents décrivent une lacune institutionnelle ; ils ne démontrent pas que chaque différend serait resté sans réponse ni ne racontent l’issue de cas particuliers.

Une seconde conclusion intervient, mais l’IDNB n’a pas été créé après coup. Le 8 juin 2025, le Conseil d’administration de l’ICANN a adopté une autre politique de mécanisme de réexamen des ccTLD, élaborée par le ccNSO. L’annonce publique présente un moyen indépendant de réexaminer certaines décisions de l’opérateur de la fonction IANA, tout en précisant que les résultats ne seraient pas contraignants. Le rapport d’orientation politique d’ICANN86, daté du 14 mai 2026, indiquait que la politique était en « planification de mise en œuvre ».

Son périmètre, son cadre institutionnel et la portée de ses décisions diffèrent de l’instance imaginée en 1994. Ce mécanisme ne doit pas être présenté comme la création tardive de l’IDNB.

La distinction historique est simple, mais lourde de conséquences. La RFC reconnaissait que les parties affectées avaient un intérêt dans le choix d’un gestionnaire, privilégiait le service et l’équité sur la propriété, et envisageait un organe de réexamen contraignant si l’accord échouait. Pourtant, un comité nommé dans un texte n’est pas nécessairement un organe en activité. Les efforts ultérieurs ont dû partir de cette absence et passer par une procédure politique distincte. La participation peut apporter des connaissances, des objections et des éléments de preuve.

Un mécanisme de recours exige davantage : un organe, un périmètre, une procédure et une conséquence définie. Dans l’histoire du DNS, ces éléments ne sont pas arrivés ensemble.

Sources