Résumé

  • RFC 10023 permet de publier, sous _for-sale, un TXT commençant exactement par v=FORSALE1;. Un enregistrement peut porter un code fcod, un texte ftxt, une URI furi ou un montant indicatif fval, tandis que le domaine continue à fonctionner.
  • La convention organise la découverte, pas la cession. Un prix n’engage pas le titulaire, une URI n’est pas réputée sûre, et DNSSEC authentifie des données DNS sans établir la capacité juridique de celui qui les a fait publier.
  • Il faut donc instruire séparément la maîtrise de la zone, l’identité du titulaire, le mandat du négociateur, les conditions contractuelles, le paiement, la mutation chez le registrar et la continuité des services.

Le conseil d’administration apprend la « vente » par un robot

Une équipe de marque reçoit une alerte : le domaine principal du groupe, encore utilisé pour le courrier et l’authentification des clients, figure dans un inventaire de noms à vendre. La fiche indique 75 000 dollars, un lien HTTPS et un badge DNSSEC. Aucun dirigeant n’a pourtant ouvert de processus de cession.

Le robot n’a pas nécessairement menti. Il a peut-être fidèlement rendu deux TXT présents dans le DNS. Mais sa fiche a assemblé plusieurs propositions que les enregistrements ne contiennent pas : la personne qui contrôlait la zone représentait le titulaire ; le montant était actuel ; le lien menait à un mandataire encore habilité ; l’objet offert comprenait bien la maîtrise d’enregistrement ; le registrar pouvait exécuter la mutation ; les services survivraient à l’opération.

Cette différence entre observation et pouvoir est le vrai sujet de RFC 10023. Publié en juillet 2026 comme RFC Informational, le texte définit une convention opérationnelle : un titulaire peut ajouter une feuille réservée _for-sale à sa zone pour indiquer que le domaine parent est disponible à l’achat. Le sens est large et peut comprendre une location ou la mise à disposition contractuelle du droit d’usage. Le signal cohabite avec les usages existants et n’exige aucun changement de protocole.

Les services d’enregistrement répondent déjà à la question « ce nom est-il enregistré ? ». Ils ne disent pas nécessairement « son titulaire veut-il négocier ? ». La nouvelle convention réduit ce coût de découverte. Elle ne désigne pas le propriétaire, ne qualifie pas son représentant et ne règle pas la vente.

La grammaire reconnaît un signal, non un contrat

La chaîne d’ouverture est stricte : v=FORSALE1;, avec la casse exacte et sans espace. Elle peut rester seule ou être suivie d’une unique paire étiquette-valeur. Quatre étiquettes initiales sont définies :

  • fcod= pour un code opaque dont des processeurs coopérants connaissent la sémantique ;
  • ftxt= pour une indication courte destinée aux personnes ;
  • furi= pour une seule URI ou IRI de contact ou d’information ;
  • fval= pour des lettres de devise en capitales suivies d’un nombre.

Un RRset peut contenir plusieurs TXT. La même étiquette peut revenir avec des valeurs différentes, à condition que chaque paire complète soit unique. Le processeur est libre d’en retenir une ou plusieurs.

Cette liberté fait de l’affichage un acte local. Un registrar peut ne reconnaître que son préfixe fcod. Un comparateur peut extraire uniquement fval. Une interface humaine peut privilégier ftxt et furi. Aucune de ces vues n’est le RRset complet. Pour qu’une décision reste contestable, il faut conserver la réponse entière et la règle de sélection appliquée.

La convention distingue aussi le signal de son contenu auxiliaire. Une version valide accompagnée d’un contenu absent ou invalide conduit normalement à présumer la disponibilité, sauf politique locale contraire ; le processeur peut alors rechercher un contact par des moyens habituels. À l’inverse, une phrase « à vendre » dépourvue de version valide ne constitue pas l’indicateur RFC 10023 et le nœud doit être ignoré si aucun TXT valide n’y figure.

La syntaxe dit : « cette publication appartient à cette convention ». Elle ne dit pas : « cet interlocuteur peut engager le titulaire ».

Le code privé peut gouverner la destination publique

Avec fcod, les parties coopérantes fixent la signification ailleurs. Un registre ou un réseau de registrars peut convertir un code reconnaissable en page de vente. Le routage peut être corrigé dans un système central sans modifier la zone. C’est une manière efficace de garder la maîtrise des destinations proposées.

Mais la preuve se déplace. Un tiers ne peut pas déchiffrer le code à partir de la RFC. Si le service modifie sa table de correspondance, le même TXT peut conduire ailleurs demain. Sans journal daté de cette table, l’acheteur ne peut plus reconstruire la fiche qu’il a vue. Le processeur devient alors l’autorité pratique du sens sans que le DNS ne montre le changement.

ftxt pose un risque différent. Sa souplesse accepte les langues humaines, mais aussi des caractères de contrôle, des homographes, du balisage dangereux ou une séquence ressemblant à une deuxième étiquette. Un fcod peut contenir ;ftxt= dans sa valeur sans créer de champ ftxt. Découper naïvement la chaîne au point-virgule fabrique une affirmation inexistante.

furi réserve une URI ou IRI unique. HTTP, HTTPS, mailto et tel sont recommandés, HTTPS étant préférable lorsque pertinent. Une URI bien formée peut néanmoins viser un site de hameçonnage ou un contenu malveillant. RFC 10023 interdit donc de rediriger automatiquement l’utilisateur sans confirmation explicite. La présence dans le DNS n’est pas une analyse de réputation.

fval structure un montant, par exemple EUR999. Les monnaies fiduciaires standard devraient utiliser leur code à trois lettres en capitales ; la grammaire accepte aussi des abréviations de cryptoactifs. Le texte précise que le prix est indicatif et non contraignant. Toute information actuelle et fiable exige un contact direct. Un système automatisé ne doit pas prendre d’engagement d’achat sur ce seul chiffre.

Ces quatre indications peuvent orienter la prochaine étape. Elles ne définissent ni le périmètre de l’actif, ni les garanties, ni les impôts, ni l’acceptation, ni le séquestre, ni la mutation.

Deux cent cinquante-cinq octets pour rester modeste

Le RDATA de chaque TXT doit être une seule character-string, limitée à 255 octets. Les informations multiples prennent la forme de plusieurs enregistrements. RFC 1035 fournit les bases du type TXT et des TTL ; RFC 10023 ajoute les contraintes propres au signal.

Le parseur doit travailler sur le RDATA brut, pas sur la représentation échappée d’un outil de requête. Pour les caractères non ASCII, la RFC recommande UTF-8, Network Unicode et un répertoire maîtrisé. Une interface peut neutraliser des caractères de contrôle problématiques, mais doit garder la trace de ce qui a réellement été reçu.

Cette petite capacité oblige à nommer correctement la fonction du mécanisme. Le DNS transporte une invitation compacte. Il n’est ni un data room ni un acte de cession. Ajouter des conventions privées dans des codes ou du texte ne les rend pas communes ; cela crée une couche de dépendance supplémentaire.

La position de la feuille détermine le nom concerné

_for-sale.example vise le parent example. xyz._for-sale.example n’est pas conforme, car _for-sale n’est plus une feuille. La forme _for-sale.*.example ne permet pas de proposer d’un coup tous les noms d’une zone. RFC 4592 décrit les wildcards DNS, et RFC 10023 exclut explicitement cette construction.

Des wildcards existants peuvent néanmoins synthétiser des réponses trompeuses, notamment avec CNAME ou DNAME. Un collecteur sérieux garde le nom interrogé, le propriétaire de la réponse, la chaîne d’alias, le caractère autoritatif et les indices de synthèse ; le dernier TXT seul ne suffit pas.

La feuille peut se placer à plusieurs niveaux. Sous un sous-domaine sans registre public des droits, une convention contractuelle distincte peut être nécessaire pour définir ce qui est transmissible. Les processeurs doivent ignorer les occurrences sous .arpa, qui pourraient être prises pour une offre portant sur de l’espace d’adressage ou des numéros E.164. Les noms à usage spécial restent hors champ.

RFC 8552 explique la réservation des noms soulignés globaux afin d’éviter les collisions entre usages. Le registre IANA des paramètres DNS porte désormais l’entrée TXT / _for-sale / RFC 10023. Cette inscription établit l’allocation du nom, pas la sincérité d’une annonce, sa diffusion ni la qualité du vendeur.

Le registre des errata de RFC 10023 contient un erratum technique, le 9090, au statut Reported. Il conteste la mention « Root zone » de la première ligne du tableau de la section 2.6 et propose une formulation TLD ou zone apex. Reported ne signifie pas Verified : c’est un point de revue, non une correction normative acquise.

La durée du cache n’est pas celle du consentement

Le titulaire doit supprimer l’indicateur quand le domaine n’est plus disponible. Pour limiter les disponibilités ou prix périmés, RFC 10023 recommande un TTL d’au plus 3 600 secondes.

Ce délai gouverne un cache DNS, pas les bases de courtiers, les captures d’écran ou les agrégateurs. Une annonce aspirée peut vivre des mois. Un mandat peut être retiré avant l’expiration du TXT. À chaque étape, l’observation doit donc comporter heure, TTL, résolveur, RRset complet et état DNSSEC, puis être renouvelée sur le chemin autoritatif.

L’absence n’est pas davantage un verdict. Une période de redemption, un état pendingDelete ou une validation DNSSEC bogus peuvent rendre le nom irrésolvable. « Je n’ai pas vu le signal » et « le titulaire refuse de vendre » sont deux propositions différentes.

DNSSEC atteste la donnée DNS, pas le mandat social

RFC 4033 attribue à DNSSEC l’authentification d’origine et la protection d’intégrité des données DNS au sein d’une chaîne de confiance. Il ne fournit pas de confidentialité. Une réponse validée prouve mieux que le RRset appartient aux données authentifiées sous les clés pertinentes.

Elle ne prouve pas qui avait qualité pour demander sa publication.

Un prestataire DNS peut contrôler la zone sans pouvoir disposer du nom. Un jeton API compromis peut modifier les données, ensuite correctement signées par l’infrastructure. Une ancienne automatisation peut continuer après le départ de son propriétaire. Le signataire DNS et le signataire du contrat ne sont pas le même rôle.

RFC 9083 décrit les réponses JSON de RDAP, utiles pour rapprocher entités, statuts et serveurs de noms. Ces données peuvent être masquées ou présentées par rôles. Elles ne démontrent pas à elles seules le bénéficiaire économique, la délégation interne, le pouvoir du courtier ou l’absence de litige.

Une annonce DNSSEC valide, un interlocuteur non rapproché et un compte registrar verrouillé ne doivent pas être moyennés en « confiance moyenne ». Les preuves répondent à des questions différentes ; certaines incohérences doivent arrêter l’opération.

La vente commence là où le signal s’arrête

Le dossier de découverte conserve la requête, le RRset, le TTL, les alias et la validation. Le dossier de contrôle de zone identifie le compte, le prestataire, le credential, la délégation et le ticket ayant permis le changement.

Le dossier d’identité rapproche le registrar ou RDAP d’une personne morale vérifiée et définit le droit offert : contrôle d’enregistrement, bail, licence, sous-domaine ou ensemble d’actifs. Le dossier de représentation prouve que le salarié, le courtier ou le service peut engager le titulaire, dans quelles limites et jusqu’à quelle date.

Une offre formelle remplace ensuite le prix DNS. Elle versionne la devise, les actifs inclus, les taxes, les garanties, les conditions de transfert et le mode d’acceptation. Le paiement et le séquestre apportent leurs propres preuves. La mutation chez le registrar apporte les siennes.

Enfin, la continuité traite les nameservers, les clés et DS DNSSEC, le courrier, les certificats, les identités, les API et le renouvellement. On peut réussir juridiquement une cession, réussir techniquement un changement de titulaire et échouer opérationnellement le lendemain.

Running-Code Primacy remet les actes dans leur ordre : le serveur DNS produit l’observation, le validateur produit un état de sécurité, les systèmes d’identité et de contrat produisent un mandat, le registrar change le contrôle, les applications produisent la continuité. Aucun registre symbolique ne reçoit par transitivité le pouvoir des autres.

Minimum Initial Specification justifie une grammaire commune réduite. Elle rend la découverte interopérable sans instituer un courtier, une place de marché, un séquestre ou un droit unique. Les choix locaux restent légitimes s’ils sont exposables, remplaçables et décrits sans exagération.

Reality Layers sépare le TXT symbolique, la publication opérationnelle, le droit institutionnel, l’accord commercial et l’expérience des services. Le badge unique les comprime et attribue à son émetteur une autorité qu’aucune couche ne lui a donnée.

Data Sovereignty pose enfin la question de la reconstruction. Celui qui conserve RRset brut, historique de zone, table fcod, identités, versions négociées, paiement, mutation et continuité contrôle le récit d’un litige. Exporter seulement « vente vérifiée » ne donne pas au client la maîtrise de ses preuves.

Sources