Résumé

  • RFC 5144 définit DCHK comme un sous-ensemble léger du modèle de registre de domaines IRIS-DREG.
  • active et inactive décrivent la présence dans le DNS, non un droit à enregistrer le nom.
  • reserved signifie explicitement que la procédure normale d’enregistrement n’est pas ouverte.
  • Les états de litige et de grâce empêchent de réduire le cycle de vie à un voyant binaire.
  • Une création, un transfert ou une restauration peut être pending ou prohibited ; le verbe ne prouve pas l’achèvement.
  • L’acteur, la portée et l’autorité du sous-statut disent qui parle et dans quel contexte.
  • La date de dernière actualisation concerne la base source, pas l’écran ou la décision ultérieure.
  • Une référence d’enregistrement indique le prochain interlocuteur sans garantir sa réponse.
  • Les renvois IRIS peuvent traverser types et instances de registre et peuvent former des boucles.
  • La couche XML d’IRIS n’authentifie ni ne protège seule la confidentialité de l’échange.
  • Les identifiants DCHK demeurent inscrits chez l’IANA, sans démontrer un déploiement actif.
  • La gouvernance doit conserver des reçus distincts pour observation, politique, commande, mutation et résultat DNS.

Un chemin de renvoi n’est pas une chaîne de délégation

RFC 5144 a été conçu pour une consultation publique à grand volume. Son schéma DCHK reprend une partie stricte de DREG. L’opérateur peut placer les deux services dans le même processus, ou isoler le service détaillé sur une infrastructure soumise à des contrôles plus stricts. Pour l’utilisateur, l’ensemble peut paraître continu. Pour l’autorité, il ne l’est pas.

Cette différence devient visible avec registrationReference. Une réponse fournie par un registre peut pointer vers un service de bureau d’enregistrement ou de titulaire. Le champ est utile : il évite de charger l’interface publique de tous les détails. Mais il dit seulement où poser la question suivante. Le service désigné peut exiger une identité, un compte, une compétence territoriale, une politique commerciale ou une autorisation absente de la première requête.

Le noyau IRIS connaît aussi les références d’entité et les continuations de recherche. Elles peuvent franchir des instances et des types de registre. Le protocole conseille de ne les suivre qu’une fois afin d’éviter une boucle. Une chaîne navigable n’est donc pas nécessairement une hiérarchie de pouvoir ; c’est un itinéraire documentaire dont chaque étape doit être attribuée.

L’erreur naît avant même le mot « disponible »

Dans DCHK, active signifie disponible dans le DNS par délégation ou publication directe. inactive signifie indisponible dans le DNS. Le français courant pousse à lire « actif » comme « enregistré » et « inactif » comme « libre ». La norme parle pourtant d’un autre plan : la publication.

Un nom sans présence DNS peut être reserved, donc exclu de la procédure normale. Il peut être en litige ou dans une période de grâce après création, renouvellement, transfert ou suppression. RFC 3915 montre qu’un nom supprimé traverse des états de rédemption et de suppression en attente avant de devenir, éventuellement, disponible pour un nouvel enregistrement. L’absence dans le DNS ne raccourcit pas cette machine d’états.

Les opérations constituent un autre piège. DCHK peut mentionner création, suppression, renouvellement, restauration, transfert ou mise à jour. Leur disposition peut être pending ou prohibited. Dire « transfert » sans conserver cette qualification transforme une intention ou un blocage en fait accompli.

RFC 5731 formule la limite dans le contexte voisin d’EPP : une commande de contrôle donne un indice sur la possibilité de provisionner, car les exigences finales relèvent de la politique du serveur. Même une commande de transformation traitée peut rester en attente. DCHK n’est pas EPP, mais l’ordre des preuves ne change pas : consulter, anticiper, accepter et achever sont quatre actes.

La fraîcheur doit suivre la donnée, pas l’interface

Le champ lastDatabaseUpdateDateTime indique quand la base à l’origine du résultat a été actualisée. Il ne date ni la réponse réseau, ni l’affichage, ni la décision de l’utilisateur. Une interface fraîche peut donc présenter une donnée ancienne avec une parfaite disponibilité technique.

Il faut conserver au moins trois temps : celui de l’état source, celui de l’observation et celui de la décision. Un cache ajoute son propre temps. Un journal de commande en ajoute un autre. Les écraser dans un unique updated_at rend ensuite impossible de déterminer si le conflit vient d’une réplication lente, d’un changement de politique ou d’une course entre deux demandeurs.

Le statut lui-même possède une provenance. Il peut inclure une date d’application, des tickets, des descriptions localisées et un sous-statut dont l’autorité doit être nommée. L’attribut actor distingue registre, bureau d’enregistrement et prestataire. scope limite le contexte. Ces champs protègent l’interprétation ; les retirer pour simplifier l’interface revient à fabriquer une certitude universelle.

Une connexion sûre ne confère pas le droit de décider

RFC 3981 précise que la couche XML d’IRIS n’offre par elle-même ni authentification ni confidentialité. Elle s’appuie sur le transport et met en garde contre des identifiants rejouables lors du suivi des renvois. RFC 5144 impose IRIS-LWZ à ses clients et serveurs ; XPC et BEEP restent optionnels.

Même correctement authentifié, l’échange ne prouve que ce que son interlocuteur est habilité à attester. Il ne rend pas la base plus récente, ne change pas la portée du statut et n’autorise pas une opération commerciale. La sécurité de la conversation et le droit de modifier le registre sont deux contrôles séparés.

L’IANA conserve le schéma et l’espace de noms dchk1, le service DCHK1 et le profil BEEP correspondant. Ce sont des reçus d’attribution de protocole. Ils ne comptent ni les serveurs, ni les requêtes, ni les enregistrements réussis. Le seul erratum vérifié corrige l’orthographe de « Straightforward-NAPTR » ; il ne modifie aucune sémantique.

Enfin, le champ IDN de RFC 5144 renvoie à Nameprep, RFC 3491, aujourd’hui obsolète. RFC 5891 décrit IDNA2008. RFC 5144 n’est pas formellement déclaré obsolète pour autant, mais sa référence ancienne interdit de présumer une compatibilité automatique avec les politiques contemporaines de noms internationalisés.

Le bon produit montre les limites de son propre témoin

Un système responsable expose le serveur interrogé, la version du protocole, les octets reçus, le temps de la base source, tous les statuts et leurs qualifications. Il enregistre séparément le renvoi suivi et l’autorité atteinte. Puis il ouvre une nouvelle série de reçus : identité du demandeur, règle applicable, prix, soumission, acceptation, examen en attente, mutation engagée, publication DNS et résolution observée.

Cette séparation n’alourdit pas seulement l’audit ; elle accélère le diagnostic. Un statut périmé relève de la réplication. Un nom réservé relève de la politique. Une création en attente relève du processus. Un objet créé mais non délégué relève de la publication DNS. Un domaine résolu sans service utile relève encore d’un autre système.

La clarté retire au voyant vert un pouvoir symbolique qu’il n’a jamais reçu. C’est précisément son intérêt.

Sources

  1. RFC 5144, HTML
  2. RFC 5144, texte
  3. Notice RFC Editor
  4. Notice IETF Datatracker
  5. Historique du document
  6. Recherche des errata
  7. Rendu avec errata vérifié
  8. Registre XML de l’IANA
  9. Paramètres S-NAPTR de l’IANA
  10. Paramètres BEEP de l’IANA
  11. RFC 3981 : noyau IRIS
  12. RFC 3982 : registre de domaines IRIS
  13. RFC 3983 : IRIS sur BEEP
  14. RFC 4992 : XML pipeliné pour IRIS
  15. RFC 4993 : transport UDP léger pour IRIS
  16. RFC 3915 : périodes de grâce EPP
  17. RFC 5731 : correspondance EPP des domaines
  18. RFC 3491 : Nameprep
  19. RFC 5891 : protocole IDNA2008
  20. RFC 9083 : réponses JSON de RDAP
  21. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  22. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  23. Running-Code Primacy