Résumé

  • Un RRset _for-sale valide atteste qu’une zone publie une intention conforme à la RFC 10023 ; il n’atteste pas l’identité civile du vendeur, son mandat, la qualité du titre ni un prix contractuel.
  • Une place de marché prudente doit conserver séparément observation DNS, validation DNSSEC, autorité du mandataire, conditions, consentement et transfert, puis produire un reçu reliant ces étapes sans les confondre.

La simplicité de l’annonce est sa force. Le titulaire ou l’opérateur d’une zone place un enregistrement TXT sous _for-sale, commence la valeur par v=FORSALE1; et peut ajouter une seule indication : code, texte, URI ou valeur. Un chercheur peut ainsi repérer une disponibilité sans explorer une page d’accueil, interpréter une bannière ou dépendre d’un intermédiaire particulier.

Cette simplicité crée aussi un raccourci dangereux. Dans une interface commerciale, « trouvé dans le DNS » peut devenir « mis en vente par le propriétaire », puis « achetable à ce prix ». Ces trois propositions ne sont pas équivalentes. La première décrit une observation technique ; la deuxième attribue un pouvoir à une personne ; la troisième prétend connaître un accord encore inexistant.

Le marqueur établit une syntaxe, pas un mandat

La chaîne de version est sensible à la casse et doit ouvrir l’enregistrement. Si elle est valide sans autre étiquette, la RFC invite le processeur à présumer que le nom est proposé, sous réserve de sa politique locale. Si aucune étiquette reconnue n’est valide, l’enregistrement est ignoré. Plusieurs enregistrements uniques peuvent coexister dans le RRset, mais chaque enregistrement ne porte qu’une étiquette optionnelle.

Voilà un contrat de traitement, non un registre de propriété. La notion de disponibilité est volontairement large : vente, location ou droit d’usage peuvent tous être visés. Le détenteur n’est pas obligé de conclure et l’annonce peut résulter d’une erreur ou avoir été retirée. Même fval, qui ressemble à un prix, reste non contraignant. Une application qui transforme cette valeur en « prix ferme » ajoute une promesse que le protocole ne fournit pas.

Une réponse fraîche reste une preuve DNS

Il faut d’abord dater l’observation : nom demandé, RRset exact, résolveur, moment de collecte, TTL restant, chaîne de délégation et résultat de validation. La recommandation d’un TTL ne dépassant pas 3 600 secondes réduit la durée d’une annonce périmée ; elle ne garantit ni retrait immédiat ni cohérence de tous les caches. La disparition ultérieure du RRset est elle-même un événement de contrôle, pas un détail à lisser.

DNSSEC resserre une question importante. Une validation réussie peut établir que les données reçues appartiennent à la chaîne signée attendue et n’ont pas été altérées en chemin. Elle ne transforme cependant pas une clé de zone en procuration commerciale. La personne qui exploite la zone peut différer du titulaire inscrit, du vendeur économique, du courtier autorisé ou du signataire capable de transférer le nom. C’est une inférence de gouvernance : la provenance cryptographique d’un message et l’autorité juridique de son auteur sont des contrôles distincts.

Un pointeur n’est pas une contrepartie vérifiée

furi peut conduire vers une page ou un service de vente. La RFC déconseille toute redirection automatique sans confirmation explicite de l’utilisateur, notamment parce qu’une URI peut être malveillante et doit être nettoyée. Ce garde-fou protège l’ouverture du lien ; il ne vérifie pas l’opérateur situé au bout.

Avant d’afficher « vendeur vérifié », il faut donc établir qui contrôle le compte de vente, au nom de qui cette personne agit, quelle preuve de mandat elle présente, comment les conditions ont été acceptées et quel canal de transfert sera utilisé. Un sous-domaine ajoute une difficulté : il peut ne pas exister de registre public permettant de déterminer le titulaire du droit. Pour .arpa, la RFC ordonne d’ignorer le mécanisme. La portée de la preuve dépend ainsi du contexte du nom, pas seulement de la présence du préfixe.

Séparer les états de la transaction

Un modèle opératoire robuste conserve au moins neuf états : nom observé ; RRset frais ; syntaxe valide ; origine DNSSEC validée ou non ; intention de mise à disposition ; contrepartie identifiée ; mandat vérifié ; conditions acceptées ; transfert terminé. Chacun possède son horodatage, sa source et sa décision.

Cette séparation évite deux erreurs symétriques. La première consiste à refuser toute utilité à l’annonce parce qu’elle ne vaut pas contrat : on perd alors un signal de découverte standardisé. La seconde consiste à lui faire porter toute la transaction : on expose l’acheteur à un prix caduc, un intermédiaire sans mandat ou une zone compromise. Le bon système laisse le signal faire ce qu’il sait faire, puis exige d’autres preuves pour le reste.

Construire un reçu de l’annonce au transfert

La pièce utile n’est pas une capture d’écran verte, mais un reçu structuré. Il devrait contenir le nom et le RRset brut, la date, le TTL et le résultat DNSSEC ; l’étiquette interprétée et les avertissements ; l’identité du canal de contact ; la preuve de contrôle du compte et du mandat ; la version des conditions ; les consentements ; l’identifiant du service de paiement ou d’entiercement ; enfin le résultat du transfert au bureau d’enregistrement.

Ce reçu ne rend pas le DNS responsable du contrat. Il montre au contraire où sa responsabilité s’arrête. Une contestation peut alors être examinée sans reconstruire une histoire à partir d’un badge : l’annonce était-elle encore fraîche ? le lien observé était-il celui approuvé par l’utilisateur ? le mandataire avait-il pouvoir ? le prix avait-il été accepté ? le registre ou le registrar a-t-il exécuté le changement ?

Le retrait doit couper l’affirmation publique

Une plateforme qui indexe ces annonces doit réinterroger au rythme du TTL, distinguer « vu récemment » de « actif maintenant » et cesser de présenter une offre comme courante lorsque le signal disparaît. Elle peut conserver la preuve historique pour l’audit, mais ne doit pas confondre mémoire et disponibilité. Un changement de furi ou de fval mérite un nouvel état, pas l’écrasement silencieux de l’ancien.

L’enjeu dépasse la vente de domaines. Dès qu’une donnée publiée dans une infrastructure devient une affirmation commerciale, l’interface attribue du pouvoir. Nommer précisément l’auteur de chaque preuve — zone, validateur, place de marché, mandataire, registrar — empêche cette attribution de se produire en silence.

Sources