Mon blog

Vous vendez un ou plusieurs noms de domaine ? Alors, marquez-les comme étant en vente, en ajoutant le sous-domaine _for-sale, dont le contenu permettra de donner des informations à d'éventuels clients.

C'est une simple convention, qui ne modifie en rien le DNS et ne nécessite pas de changer les logiciels. Voici un exemple, avec un domaine de test :

% dig +short +nodnssec  _for-sale.example.nl. TXT
"v=FORSALE1;furi=https://example.nl/for-sale.txt"
"v=FORSALE1;ftxt=See the URL for important information!"
…

  

Il existe en effet toute une activité d'achat et de vente de noms de domaine. On la nomme en anglais domaining et ses pratiquants sont les domainers (parfois francisés en domaineurs). Quels que soient les sentiments que peuvent inspirer les pratiques, pas toujours très belles, de ces domaineurs, il faut noter qu'il s'agit d'une activité légale, explicitement prévue par de nombreux registres. Comment travaillent ces domaineurs ? Ils cherchent des noms « intéressants », regardent s'ils sont libres et les enregistrent, dans l'espoir de les revendre plus cher. Ou bien, s'ils ne sont pas libres, essaient parfois des les racheter à leurs titulaires, toujours dans l'espoir d'un bénéfice.

Comment savoir si un domaine est libre ? (Non, pas en faisant une requête DNS ; un nom peut être enregistré mais pas publié dans le DNS.) Il existe des solutions normalisées comme whois (RFC 3912) ou RDAP (RFC 9083). Même si le nom n'est pas libre, on peut tenter de le racheter. Il existe des plate-formes de mise en contact de vendeurs et d'acheteurs, comme par exemple Sedo :

(Sedo est juste un exemple ; il y en a d'autres, parfois gérés par des BE. Par exemple Afternic est propriété de GoDaddy. On trouve aussi des noms de domaine sur des plate-formes plus classiques par exemple en France Boischaut en vend sur InterEnchères. Attention, ces noms de plate-formes ne sont donnés qu'à titre d'exemple et ne sont certainement pas une recommandation. Une liste à jour de ces plate-formes est disponible.)

Mais il est préférable de pouvoir se passer d'intermédiaire. Notre nouveau RFC propose donc une solution sans intermédiaire pour prévenir que le nom de domaine est en vente : vous ajoutez un sous-domaine _for-sale à votre domaine, qui indique explicitement que vous vendez ce nom. Pourquoi le précéder d'un tiret bas ? Pour limiter les risques de collision avec les autres noms enregistrés (RFC 8552). Quelles valeurs associer à ce nom ? Un enregistrement de type TXT, qui va donner des détails sur ce que le vendeur propose. Plus précisément (section 2 du RFC), vous devez commencer chaque enregistrement par v=FORSALE1;. Vous pouvez ensuite ajouter au choix (un seul par enregistrement mais vous pouvez mettre plusieurs enregistrements) des couples clé=valeur :

• Une référence pour vous, avec la clé fcod, qui peut permettre d'indiquer un identificateur sur une plate-forme d'achat et vente.
• Un texte libre, avec ftxt. Il est fortement recommandé qu'il soit en UTF-8 (RFC 3629), même si la norme DNS ne l'impose pas. En prime, le RFC recommande d'utiliser le profil limité du RFC 5198 et celui du RFC 9839, section 4.3.
• Un URI, pour aller chercher davantage d'informations (clé furi). Le RFC recommande de se limiter aux plans http, https, mailto et tel. Et de ne pas suivre automatiquement ces liens, ils peuvent être malveillants (section 4). Demandez confirmation plutôt deux fois qu'une.
• Le prix demandé, avec la clé fval. La monnaie utilisée doit être indiquée en suivant la norme ISO 4217.

Les enregistrements TXT associés au nom _for-sale qui ne commenceraient pas par v=FORSALE1; peuvent être ignorés (mais ils peuvent contenir des informations supplémentaires). Si aucun enregistrement TXT de ce sous-domaine ne commence par v=FORSALE1;, il faut ignorer ce nom, et ne pas considérer que le domaine est réellement en vente (cela peut être l'effet d'un joker DNS, regardez par exemple unipol-tech.com, il n'est pas en vente mais il y a un joker, vous verrez un TXT pour n'importe quel nom comme _for-sale.unipol-tech.com, cf. section 3.1).

Vous avez des exemples dans le RFC, section 2 et annexe A mais, sinon, regardons le domaine cours-dns.fr. Vous pouvez regarder avec dig :

    
%  dig _for-sale.cours-dns.fr TXT


; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> _for-sale.cours-dns.fr TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50746
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;_for-sale.cours-dns.fr.	IN TXT

;; ANSWER SECTION:
_for-sale.cours-dns.fr.	300 IN TXT "Read RFC 10023 to learn more"
_for-sale.cours-dns.fr.	300 IN TXT "v=FORSALE1;furi=https://www.afnic.fr/en/products-and-services/training/"
_for-sale.cours-dns.fr.	300 IN TXT "v=FORSALE1;fcod=42"
_for-sale.cours-dns.fr.	300 IN TXT "v=FORSALE1;fval=BTC1000"
_for-sale.cours-dns.fr.	300 IN TXT "v=FORSALE1;ftxt=Make money fast / Soyez friqu\195\169 rapidement"
_for-sale.cours-dns.fr.	300 IN RRSIG TXT 15 3 300 (
				20260303165737 20260216165737 37133 cours-dns.fr.
				pxYB9Wxx95+vSgzM1A+HfKyelYeHaHnbq/OIiK5IDW4L
				oC9ir7wG4pb4ehjHg8mrBEHguxiyT9UIL7ROSU/BAQ== )

;; Query time: 10 msec
;; SERVER: 192.168.2.254#53(192.168.2.254) (UDP)
;; WHEN: Thu Feb 19 10:50:27 CET 2026
;; MSG SIZE  rcvd: 454

  

(Notez que dig n'affiche pas le texte UTF-8 correctement.) Ou bien, plus joli, avec le DNS Looking Glass (là, l'Unicode est bien affiché). Ou bien via le démonstrateur de SIDN Labs, qui permet d'afficher plus proprement (en néerlandais) ces informations.

Bon, si vous voulez la même chose avec un vrai domaine vraiment en vente :

% dig _for-sale.actuals.nl TXT

; <<>> DiG 9.20.18-1~deb13u1-Debian <<>> _for-sale.actuals.nl TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61541
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;_for-sale.actuals.nl.	IN TXT

;; ANSWER SECTION:
_for-sale.actuals.nl.	1800 IN	TXT "v=FORSALE1;fcod=NLFS-OTQ0NTY5Y2YtY2ExNS00YWM0LTljNTgtN2I2YmU3Mzc4Njg5"
_for-sale.actuals.nl.	1800 IN	TXT "v=FORSALE1;furi=https://api.nameshift.com/sidn?domain=actuals.nl"

;; Query time: 32 msec
;; SERVER: ::1#53(::1) (UDP)
;; WHEN: Thu Feb 19 10:57:33 CET 2026
;; MSG SIZE  rcvd: 208

  

Vous noterez que le fcod est reconnu par la plate-forme du .nl et l'URI donné vous y emmène directement.

Question sémantique, le RFC note que le _for-sale n'est pas une promesse : le titulaire du domaine qui met ce sous-domaine ne s'engage pas à vendre, il a parfaitement le droit de renoncer à l'opération. C'est d'autant plus vrai que le _for-sale récupéré peut avoir été supprimé mais que votre résolveur DNS l'avait gardé en mémoire (la section 3.4 met en garde contre les TTL trop longs, la FAQ suggère une heure).

Autre point amusant : un sous-domaine _for-sale peut apparaitre partout dans l'arbre des noms de domaines, donc on pourrait voir Verisign publier un _for-sale.com si cette entreprise voulait vendre .com 😃. Seul .arpa est exclu par le RFC. (Et la racine ? Le RFC n'en parle pas.)

La section 4, sur la sécurité, rappelle qu'il faut considérer que le contenu de ces enregistrements TXT n'est pas sûr : il peut y avoir du XSS ou des tentatives d'injection SQL par exemple. Si vous écrivez un programme qui analyse ces enregistrements, soyez très paranoïaque.

Il y a aussi un risque non-technique, celui de malhonnêtes publiant des enregistrements _for-sale alléchants mais trompeurs (_for-sale.sex.com. TXT "V=FORSALE1; ftxt=Make money fast!!! Only $100!") afin de vous amener à visiter un site Web de publicité ou de hameçonnage. Il ne faut surtout pas, par exemple, lancer automatiquement un achat sur la base de ces enregistrements.

Et puis rappelez-vous que les informations dans le DNS sont publiques, et que n'importe qui peut donc savoir que vous voulez vendre (c'est bien le but, mais il faut se souvenir que tout le monde, pas juste les acheteurs potentiels sérieux, verra ces informations, et elles peuvent contenir des données que vous ne voudriez pas trop diffuser comme les noms et adresses des personnes à contacter).

Le principal registre promoteur de cette technique est celui du .nl. Son interface Web permet de voir, lorsqu'on affiche des informations sur un domaine, qu'il est en vente (regardez par exemple https://www.sidn.nl/en/whois?q=123huren.nl)

Il y a une page officielle du projet avec beaucoup d'information, d'outils et de détails. Le code source est disponible. Il y a même un MCP ! (Je ne l'ai pas testé.) Il existe aussi un vérificateur d'enregistrements (notez qu'il a été écrit en partie par un LLM à qui on a fait lire le brouillon du RFC). La zone testdns.nl a une incroyable collection d'enregistrements _for-sale, pour tester les outils. Et évidemment, vous avez un assistant IA.

Le composant _for-sale a été ajouté au registre IANA des noms préfixés d'un trait bas, registre qui avait été défini par le RFC 8552.

Ce n'est pas tous les jours qu'on normalise une nouvelle méthode HTTP. Bienvenue, donc, à QUERY, qui rejoint des méthodes bien plus anciennes comme GET et POST. QUERY peut être décrit comme « GET mais avec un corps dans la requête ». Comme GET, elle est idempotente et donc sûre à répéter.

L'idée est de pouvoir interroger, par exemple, un service de recherche (vous verrez un exemple plus loin sur mon blog). Sans QUERY, on envoyait quelque chose du genre :

    
GET /feed?q=foo&limit=10&sort=published HTTP/1.1    

  

On est donc obligés de mettre les paramètres dans l'URL. Cela peut poser problème si les paramètres sont nombreux et de grande taille, cela oblige à les pourcent-encoder et cela peut poser des problèmes de vie privée (l'URL demandé a des chances d'être enregistré dans un journal).

Des gens utilisent donc POST pour une recherche, bien qu'il n'ait pas la bonne sémantique :

    
POST /feed HTTP/1.1

q=foo&limit=10&sort=published

  

Mais on ne voit plus que la requête est idempotente. Un navigateur Web n'osera pas la répéter ou bien demandera confirmation à l'utilisateur. Et on ne pourra pas facilement mémoriser le résultat (puisque le client ne sait pas si la requête n'a pas d'effets de bord). QUERY résout le problème :

    
QUERY /feed HTTP/1.1

q=foo&limit=10&sort=published

  

La méthode est idempotente, le résultat peut être mémorisé.

La section 2 du RFC décrit avec précision QUERY. À lire si vous écrivez des clients ou des serveurs qui l'utilisent. Par exemple, puisque QUERY, contrairement à GET, inclut un corps dans la requête, le client doit indiquer le type de média utilisé, et sans se tromper, sinon le serveur lui renverra un 400. (Et un 415 si le type est bien là mais que le serveur ne le connait pas.) Autre chose à noter : en cas de redirection, le client ne doit pas changer de méthode (alors qu'on pouvait changer un POST en GET si la redirection était faite avec 301 ou 302). Autrement, QUERY ressemble beaucoup dans son comportement à GET. QUERY est désormais enregistré dans le registre des méthodes HTTP.

Un serveur HTTP qui met en œuvre QUERY n'accepte pas forcément n'importe quel format en entrée. Pour documenter ce qu'il accepte comme corps de la requête, notre RFC introduit un nouveau champ HTTP, Accept-Query: (section 3) qui est la liste des types de média acceptés.

Vous avez plein d'exemples de requêtes et de réponses dans l'annexe A.

Il y a une mise en œuvre de QUERY sur ce blog, pour fournir un moteur de recherche des articles. L'URL est https://www.bortzmeyer.org/methodquery et voici un exemple d'utilisation avec curl :

% curl --request QUERY --data query=framasoft https://www.bortzmeyer.org/methodquery 

    Query of "framasoft" OK

    https://www.bortzmeyer.org/capitole-du-libre-2023.html "Capitole du Libre 2023, et mon exposé sur la censure de l'Internet"
    …
  

Vous pouvez avoir une documentation plus détaillée de ce service au début de son code source (en Python), method-query.py. D'autre part, si vous n'aimez pas curl et que vous préférez un programme en Python, essayez ce client : test-http-query.py. (Par contre, pas de formulaire Web pour utiliser ce service, car je ne connais pas de navigateur qui gère QUERY.)

En parlant de curl, notez que, lorsqu'il suit une redirection HTTP (option --location), il ne transmet pas actuellement le corps de la requête, ce qui casse ce service. Il faut de toute façon utiliser --follow.

La création de cette nouvelle méthode (ce qui est rare, je crois que la précédente avait été PATCH dans le RFC 5789 il y a quinze ans) a pris du temps. Le premier projet avait été rédigé en 2015 et le travail a connu plusieurs interruptions. Une des discussions avait porté sur le nom de la méthode, qui aurait pu s'appeler SEARCH (réutilisant une méthode normalisée dans le RFC 5323). L'annexe B du RFC discute le choix qui a été fait.

Une autre discussion portait sur le code de retour HTTP, un problème classique de tous les services tournant sur HTTP : si la requête est bien transmise et traitée mais qu'on n'a pas de résultat, doit-on quand même renvoyer le 200, qui signifie que tout s'est bien passé ? Avec GET, on utilise souvent 404 dans ce cas, mais c'est parce que le terme de recherche est dans l'URL, ce qui n'est plus le cas ici. On aurait pu aussi avoir un nouveau code commençant par 2. Finalement, le choix a été de renvoyer 200 quand la requête est bien arrivée et que le moteur de recherche a fonctionné, même s'il n'a rien trouvé. (Une discussion analogue avait eu lieu pendant le développement de DoH. Le RFC 8484 avait finalement décidé de répondre 200 même si le nom de domaine demandé n'existait pas.)

Ah, et si vous voulez superviser votre service HTTP utilisant QUERY, le programme check_http des monitoring plugins le permet. Voici un exemple de configuration pour Icinga :

vars.http_vhosts["query"] = {
    http_uri = "/methodquery"
    http_vhost = "www.bortzmeyer.org"
    http_ssl = true
    http_sni = true
    http_method = "QUERY"
    # Notez que le nom de la variable n'est pas très heureux.
    http_post = "query=foobar"
    http_content_type = "application/x-www-form-urlencoded"
    http_string = "foobar\" OK"
    http_timeout = 15
}

Sinon, si vous voulez d'autres lectures, il y a un bon article de Tykok.