Résumé

  • Le projet draft-ranjbar-regext-rdap-subordinate-referrals-01 propose deux relations directionnelles pour découvrir un service RDAP choisi par le titulaire et consacré aux ressources situées sous un objet enregistré.
  • Les données aval sont affirmées par le titulaire, non par l’opérateur du registre. La subordination stricte, le lien retour et la limite d’un saut bornent leur portée, tandis que le titulaire voit les requêtes reçues.
  • L’interface devrait conserver une couture d’autorité : objet couvrant du registre, désignation et réponse subordonnée du titulaire doivent rester trois faits distincts.

Le parcours RDAP habituel part des registres d’amorçage de l’IANA. Il conduit au service chargé d’un domaine de premier niveau ou d’un ensemble de ressources numériques, puis à l’objet le plus précis détenu dans sa base. Cette descente ordonnée donne à la réponse un air d’unité.

Elle s’arrête pourtant à une frontière voulue. Un registre connaît le domaine enregistré, pas nécessairement les milliers de noms créés en dessous par une plateforme. Un RIR conserve une allocation ou une affectation agrégée, pas chaque réseau plus spécifique ni chaque adresse distribuée par le titulaire. La donnée fine vit souvent dans le système qui la produit.

Le projet individuel rendrait ce système découvrable. Le titulaire pourrait désigner un serveur RDAP exploité par lui ou pour son compte. Le registre pointerait vers le bas ; le service du titulaire pointerait vers le registre couvrant. La centralisation n’augmenterait pas, mais le client disposerait d’une nouvelle route.

Descendre ne transmet pas la qualité de registre

La révision 01 propose rdap-base-down pour viser l’URL de base du service aval et rdap-base-up pour revenir vers l’URL de base du service couvrant. Ces noms décrivent la direction du déplacement entre services. Ils ne confèrent pas au service aval le mandat de l’opérateur qui tient l’objet parent.

Le texte limite ce service aux ressources entièrement subordonnées à l’objet référent. La cible doit employer HTTPS et le client ne doit reconnaître aucune autorité au-delà de ce périmètre. Le lien retour rend la hiérarchie navigable dans les deux sens. Le nombre de renvois doit rester borné ; un seul saut de niveau titulaire suffit aux cas décrits.

Cette géométrie empêche le titulaire d’utiliser le renvoi pour parler d’un préfixe frère, d’une allocation supérieure ou d’un autre domaine. Elle ne garantit pas la véracité de chaque objet enfant. L’opérateur du registre affirme qu’une cible a été désignée pour ce périmètre. Le titulaire affirme ensuite le contenu subordonné. Fusionner les deux transforme une désignation en approbation.

La compatibilité masque facilement le changement de locuteur

Le mécanisme protège les clients anciens. Lorsqu’un pointeur a été enregistré, le serveur du registre continuerait de rediriger la recherche d’une ressource subordonnée. Un client inchangé obtiendrait ainsi l’objet le plus précis. Un client averti découvrirait la relation et choisirait consciemment de la suivre ; un client qui veut la fiche couvrante pourrait supprimer la redirection selon le mécanisme étudié dans le projet compagnon.

C’est utile, mais un code HTTP 3xx est discret. Les bibliothèques le suivent souvent sans avertir l’utilisateur. L’écran final peut sembler provenir de la source d’amorçage alors que l’opérateur, le niveau de preuve, la disponibilité et la visibilité de la requête ont changé pendant le trajet.

Le projet de groupe draft-ietf-regext-rdap-referrals-04 définit une demande de redirection explicite vers une ressource liée. Quand un lien unique convient et que le client est autorisé, le serveur répond avec un statut HTTP de redirection et un champ Location. Il traite la sélection de relation, la négociation de contenu, les caches et les chaînes. Ce transport économise une réponse complète ; il ne décide pas comment attribuer le contenu obtenu.

Source, observateur et continuité changent ensemble

La section sécurité est nette : les données du serveur désigné sont affirmées par le titulaire, non par le registre. Un client devrait rendre cette provenance visible. Elle indique qui peut corriger la fiche, qui assure sa continuité, qui répond d’une erreur et quelle valeur probante conserver dans un dossier.

Le titulaire voit aussi l’intérêt porté à ses ressources lorsque les requêtes arrivent chez lui. Le projet compare cette visibilité à celle d’un opérateur DNS et permet au client soucieux de confidentialité de ne pas suivre. Ce choix n’existe réellement que si le logiciel le présente avant la redirection et conserve l’accès à l’objet couvrant.

La panne doit elle aussi rester attribuée. L’indisponibilité du serveur du titulaire retire les détails subordonnés ; elle n’efface pas la réponse propre du registre. Écrire « RDAP indisponible » sans préciser la couche confond une panne de registre, une désignation cassée et un service aval arrêté.

L’acte de désignation demeure hors protocole

Le projet ne fixe pas la manière dont le titulaire communique sa cible au registre. Un portail ou une future extension EPP ne sont que des exemples. Or cette étape administrative décide qui peut déplacer les requêtes.

Il faut donc poser des questions que le lien ne répond pas. Quel acteur est autorisé à créer ou révoquer le pointeur ? Un prestataire qui exploite le serveur peut-il modifier la désignation ? À quel moment un changement devient-il actif ? Le transfert du domaine ou de l’allocation invalide-t-il automatiquement l’ancienne cible ? Quelle preuve subsiste après une compromission ?

Le registre devrait vérifier la conformité RDAP de la cible avant d’émettre le renvoi. Mais une syntaxe conforme ne prouve ni la titularité ni la justesse des données. La gouvernance de la désignation a besoin d’une création authentifiée, d’une portée explicite, d’une validation, d’une activation, d’un renouvellement, d’une révocation et d’un nettoyage lors du transfert.

Une couture d’autorité rend la réponse honnête

Je propose de conserver une fiche de couture d’autorité pour chaque renvoi suivi. Cette fiche ne figure pas dans le projet. Elle empêche une découverte utile de devenir une approbation implicite.

La première couche consigne l’amorçage, l’objet couvrant, le service de registre, la relation, la cible désignée, l’acteur et le canal de désignation, la date d’activation, la portée et le dernier contrôle de conformité. Les données absentes restent inconnues.

La deuxième couche décrit la traversée : chemin demandé, redirection ordinaire ou relation explicite, statut, choix de suppression, cible, résultat TLS, heure, nombre de sauts et avertissement de confidentialité. La troisième couche conserve séparément le service répondant, l’objet subordonné, la durée de cache, les marqueurs de conformité et le lien retour.

Si le service aval tombe, le client garde l’objet couvrant et nomme la panne. Si la désignation est révoquée ou si le parent change de titulaire, les affirmations mises en cache expirent. Si la réponse sort de la subordination stricte, elle est rejetée au lieu d’être blanchie par le renvoi.

Les relations sont volontairement réutilisables pour la découverte RPKI déléguée ou hybride et pour la modernisation de RWhois ou SWIP. Cette économie de vocabulaire ne doit pas uniformiser les mandats. « Aval » indique une topologie, pas une qualité juridique ni une garantie.

La révision 01, datée du 21 juillet 2026, est un Internet-Draft individuel. Datatracker ne lui attribue ni statut formel, ni flux, ni statut RFC visé, alors que l’en-tête indique Standards Track. L’auteur préfère une fusion dans le projet de groupe sur les renvois. La section d’implémentation signale un service côté titulaire, mais dit que le renvoi côté registre manque encore. Ce n’est ni un consensus adopté ni une preuve de déploiement général.

Le besoin est réel : les données utiles peuvent exister sous le point où l’amorçage s’arrête. La solution durable permet à la découverte de descendre sans faire disparaître les deux autorités dans une seule réponse.

Sources