Les deux enregistrements derrière un handle de domaine personnalisé Bluesky

Qu'est-ce qu'un handle de domaine personnalisé Bluesky ?

Un domaine qui vous appartient devient votre handle de domaine personnalisé Bluesky dès que vous publiez un enregistrement prouvant que vous le contrôlez : soit un enregistrement DNS TXT sur le sous-domaine _atproto, soit un fichier en texte brut servi sur /.well-known/atproto-did. Bluesky tourne sur l'AT Protocol, et c'est sa spécification des handles qui décide si votre enregistrement fonctionne. Les articles d'aide décrivent les boutons de l'application. La spécification décrit ce que le réseau vérifie ensuite.

À lire avant de toucher au DNS : « Handles are mutable and human-friendly account usernames, in the form of a DNS hostname. » Votre handle est un nom d'hôte, et c'est pourquoi mozilla.org fonctionne alors que mozilla seul échoue : « 'bare' top-level domains are not allowed as handles, even if valid 'hostnames' and 'DNS names.' »

Derrière chaque handle se trouve un DID, que la spécification range parmi « the long-term persistent identifiers for accounts in atproto ». Vous collez votre DID dans l'enregistrement que vous choisissez, et c'est la seule partie qui compte ici. Le reste de ce qu'est un DID mérite sa propre page.

Quel enregistrement publier, et que contient-il ?

Publiez l'un de ces deux, avec votre propre DID à la place de l'exemple.

Le préfixe est l'erreur de copier-coller la plus fréquente, et aucune des deux méthodes ne vous prévient. Les résolveurs DNS ignorent « TXT records with values not starting with did=. » En HTTPS, ce même préfixe casse le corps de la réponse, que la spécification veut sous la forme « the DID... with no prefix or wrapper formatting ».

L'enregistrement DNS pour un handle à l'apex de example.com :

Type:  TXT
Name:  _atproto
Value: did=did:plc:ewvi7nxzyoun6zhxrhs64oiz
TTL:   300

Pour un handle en sous-domaine comme alice.example.com, le nom est _atproto.alice. La plupart des panneaux DNS ajoutent la zone à votre place, donc saisir _atproto.alice.example.com en entier produit _atproto.alice.example.com.example.com et un échec silencieux.

Un seul enregistrement peut exister : « If multiple valid records with different DIDs are present, resolution should fail. » Un ancien enregistrement issu d'un compte précédent casse le nouveau.

La réponse HTTPS demandée par la spécification, reproduite telle quelle :

HTTP/1.1 200 OK
Content-Length: 33
Content-Type: text/plain
Date: Wed, 14 Jun 2023 00:47:21 GMT

did:plc:ewvi7nxzyoun6zhxrhs64oiz

Un paragraphe plus loin, dans la même section, la spécification assouplit sa propre exigence : « The response Content-Type header does not need to be strictly verified. » Servez quand même text/plain, puisque vous ne savez pas quel résolveur lit quelle ligne.

Votre DID vient de l'application. Le tutoriel de Bluesky donne le chemin « Settings », puis « Account », puis « Handle », et montre l'hôte de l'enregistrement _atproto avec la valeur "did=did:plc:[your value here]".

Quelles sont les règles de syntaxe des handles ?

Sept règles, et un handle doit toutes les respecter :

1. Le handle entier est en ASCII uniquement et fait au plus 253 caractères.
2. Les segments sont séparés par des points ASCII, et il en faut au moins deux.
3. Pas de point en début ni en fin, et pas de point final à la manière DNS.
4. Chaque segment fait de 1 à 63 caractères, pris parmi les lettres ASCII a-z, les chiffres 0-9 et le trait d'union -.
5. Un segment ne peut ni commencer ni finir par un trait d'union.
6. Le dernier segment, le domaine de premier niveau, ne peut pas commencer par un chiffre.
7. Les handles ne distinguent pas la casse et sont normalisés en minuscules.

Sur la dernière règle : « the handle input string BlueskyWeb.xyz should be normalized, stored, and displayed as blueskyweb.xyz. » Si votre marque s'écrit avec des majuscules, le handle, lui, n'en aura pas.

L'expression régulière de référence de la spécification :

/^([a-zA-Z0-9]([a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?\.)+[a-zA-Z]([a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?$/

253 est le chiffre affiché, pas celui sur lequel construire. Enfoui dans les recommandations d'implémentation, il y en a un plus petit : « handles should be limited to at most 244 characters... because DNS verification works with the prefix _atproto., which adds 9 characters. » Tout ce qui se situe entre 245 et 253 caractères est légal selon la section syntaxe et impossible à résoudre par DNS, et l'issue de secours figure dans une autre section : « The HTTPS method will work for such handles. »

Des exemples que la spécification marque comme valides, à côté de ceux qu'elle rejette :

Les domaines internationalisés ne fonctionnent que sous forme encodée : « Such handles must be stored and transmitted in encoded ASCII form. »

Quels TLD ne peuvent jamais servir de handle Bluesky ?

Huit domaines de premier niveau sont exclus d'office. Extrait de la spécification : « the initial list of disallowed TLDs includes: .alt, .arpa, .example, .internal, .invalid, .local, .localhost, .onion. »

Leur mode d'échec est délibéré et déroutant. Les TLD réservés « should not fail syntax validation... but they must immediately fail any attempt at registration, resolution, etc. » Ainsi laptop.local et blah.arpa passent une vérification par regex et échouent définitivement à la résolution. Un validateur qui ne fait tourner que la regex déclare le handle correct jusqu'à ce que le réseau le refuse.

Trois entrées comportent des conditions supplémentaires :

• .onion est bloqué pour une raison énoncée plutôt que définitive : « Resolution of handles via Tor would require ecosystem-wide support, so they are currently disallowed. » La section sur les évolutions futures ajoute que « .onion handles would be allowed at some point in the future ».
• .invalid est réservé à une seule valeur sentinelle, handle.invalid, que l'API renvoie « to indicate that there is no bi-directionally valid handle for the given DID. »
• .test ne figure pas sur la liste des interdits et n'est pas utilisable pour autant. Ce TLD « may be used in atproto development, but should fail in real-world environments. »

Notez le mot « initial ». La liste n'est pas présentée comme définitive, et la spécification renvoie vers la section des domaines réservés de Wikipédia au lieu de tenir son propre registre. Huit noms, c'est ce à quoi le protocole s'engage par écrit, et la frontière au-delà se trace sur une page que personne dans le projet AT Protocol ne contrôle.

Comment résoudre un handle vers son DID ?

Lancez-le sur un vrai compte et les deux moitiés de la vérification se déroulent sous vos yeux. Chaque valeur ci-dessous a été résolue le 10 septembre 2026.

Commencez par l'enregistrement DNS de bsky.app, le handle de Bluesky lui-même :

dig +short TXT _atproto.bsky.app

"did=did:plc:z72i7hdynmk6r22z27h6tvur"

Retirez le préfixe did= et vous avez le DID. Le point de terminaison du protocole, que les clients appellent au lieu de faire du DNS eux-mêmes, renvoie la même réponse :

curl -s "https://public.api.bsky.app/xrpc/com.atproto.identity.resolveHandle?handle=bsky.app"

{ "did": "did:plc:z72i7hdynmk6r22z27h6tvur" }

Récupérez maintenant le document DID, qui constitue l'autre moitié de la vérification :

curl -s https://plc.directory/did:plc:z72i7hdynmk6r22z27h6tvur

{
  "@context": ["https://www.w3.org/ns/did/v1", "https://w3id.org/security/multikey/v1", "https://w3id.org/security/suites/secp256k1-2019/v1"],
  "id": "did:plc:z72i7hdynmk6r22z27h6tvur",
  "alsoKnownAs": ["at://bsky.app"],
  "verificationMethod": [
    {
      "id": "did:plc:z72i7hdynmk6r22z27h6tvur#atproto",
      "type": "Multikey",
      "controller": "did:plc:z72i7hdynmk6r22z27h6tvur",
      "publicKeyMultibase": "zQ3shQo6TF2moaqMTrUZEM1jeuYRQXeHEx4evX9751y2qPqRA"
    }
  ],
  "service": [
    {
      "id": "#atproto_pds",
      "type": "AtprotoPersonalDataServer",
      "serviceEndpoint": "https://puffball.us-east.host.bsky.network"
    }
  ]
}

Le champ qui décide de tout est alsoKnownAs, qui contient at://bsky.app. Le handle pointait vers le DID, et le document DID pointe en retour. La spécification exige les deux sens : « The link between handle and DID must be confirmed bidirectionally, otherwise anybody could create handle aliases for third-party accounts. » Publier un enregistrement TXT nommant le DID de quelqu'un d'autre ne vous apporte rien, car son document DID ne nomme pas votre domaine.

Quand un handle ne se résout pas, le point de terminaison répond par une seule chaîne :

{ "error": "InvalidRequest", "message": "Unable to resolve handle" }

Cela arrive avec un HTTP 400, et c'est le même message pour un enregistrement absent, un handle valide sur un TLD réservé et un domaine qui n'existe pas. Diagnostiquez avec dig et curl plutôt qu'en lisant la réponse de l'API.

Quatre handles résolus ce jour-là, tous confirmés dans les deux sens auprès de plc.directory :

Cette répartition, c'est le design de la spécification qui fonctionne tel qu'il est écrit. Les organisations disposant d'un panneau DNS utilisent l'enregistrement TXT. Le handle qui répond en HTTPS est un sous-domaine bsky.social, soit le cas des « large-scale web services which may not have the infrastructure to automate the registration of thousands or millions of DNS TXT records » pour lequel la méthode a été conçue.

Demander https://mozilla.org/.well-known/atproto-did renvoie une page HTML 404, et theverge.com fait pareil. Les deux handles se résolvent très bien. Une seule méthode doit répondre, et un 404 sur le chemin que vous n'utilisez pas ne vous coûte rien.

Où les handles de domaine personnalisé cassent-ils ?

Les redirections méritent une note, car d'autres spécifications well-known les interdisent et pas celle-ci : « HTTP redirects (eg, 301, 302) are allowed, up to a reasonable number of redirect hops. » Une redirection de l'apex vers www ne pose pas de problème. Une redirection qui aboutit sur un 404, si, et c'est ce qui arrive quand l'apex renvoie vers www et que le fichier n'y a jamais été déployé.

Qu'arrive-t-il à vos publications programmées quand le handle change ?

Rien, et la raison est structurelle. Votre compte, c'est le DID, que le protocole qualifie de persistant, tandis que le handle est une étiquette modifiable résolue à neuf chaque fois qu'un client en a besoin. Passer de you.bsky.social à yourbrand.com laisse le DID intact, si bien qu'une file d'attente construite dans un planificateur de publications Bluesky survit au changement, tout comme les chiffres d'un outil d'analyse Bluesky. C'est le comportement du protocole, pas une faveur qu'un outil de publication accorde ou refuse.

Deux choses changent quand même. Les publications déjà parues s'affichent désormais sous le nouveau handle, parce que les clients affichent le handle qu'ils résolvent et non celui figé au moment de la publication. Et tout texte qui nomme votre ancien handle est maintenant faux, ce qui fait le plus mal quand vous publiez le même contenu sur plusieurs réseaux à la fois et que le handle Bluesky se trouve dans une légende partagée avec X, LinkedIn et Threads. Cherchez l'ancienne chaîne dans vos brouillons en file d'attente avant de basculer. Cinq minutes dans un calendrier de contenu, contre un mois de publications à corriger après coup.

Foire aux questions

Ai-je besoin à la fois de l'enregistrement DNS et du fichier well-known ?

Non. Un seul suffit, et la spécification qualifie la méthode DNS TXT de « the recommended and preferred resolution method for individual handle configuration. » Si vous publiez les deux et qu'ils nomment des DID différents, les résolveurs privilégient la réponse DNS. Supprimez l'obsolète plutôt que de laisser le conflit en place.

Pourquoi mon enregistrement TXT a-t-il besoin de did= alors que le fichier HTTPS non ?

Les deux méthodes s'analysent différemment. Le DNS suit la RFC-1464 pour stocker des attributs dans les enregistrements TXT, la valeur est donc une clé et une valeur, et les résolveurs ignorent « TXT records with values not starting with did=. » La méthode HTTPS renvoie « the DID as the HTTP body with no prefix or wrapper formatting », si bien que le même préfixe rend le corps illisible.

Puis-je utiliser un domaine .local ou .internal pour mes tests ?

Non. Les deux figurent sur la liste des interdits, et les TLD réservés « must immediately fail any attempt at registration, resolution, etc. » même s'ils passent la validation de syntaxe. Le TLD .test est celui prévu pour le développement, et la spécification attend malgré tout qu'il « fail in real-world environments ».

Quelle longueur un handle Bluesky peut-il atteindre ?

253 caractères ASCII selon les règles de syntaxe, 244 en pratique. Le préfixe _atproto. utilisé pour la vérification DNS « adds 9 characters, and that overall name needs to be valid. » Au-delà de 244, seule la méthode HTTPS se résout.

Qu'est-ce que handle.invalid et pourquoi est-ce que je le vois ?

C'est la valeur que renvoie l'API quand un DID n'a aucun handle fonctionnel, utilisée « to indicate that there is no bi-directionally valid handle for the given DID. » Elle apparaît après qu'un handle qui se résolvait a cessé de le faire. Republier le bon enregistrement l'efface.

Changer mon handle casse-t-il les liens que les gens ont déjà partagés ?

Non. Le tutoriel de Bluesky indique que « Any tags or mentions with your old handle will still point to your account », car les mentions stockent le DID et non le texte du handle. Depuis décembre 2024, votre ancien nom d'utilisateur en .bsky.social vous est en plus réservé au lieu d'être libéré.

Pourquoi publier le DID de quelqu'un d'autre dans mon enregistrement TXT ne fonctionne-t-il pas ?

Le protocole vérifie le lien dans les deux sens. Votre enregistrement peut nommer n'importe quel DID, mais le document DID doit aussi pointer vers votre domaine dans le champ alsoKnownAs, via une URI at://. Le document DID de bsky.app liste at://bsky.app pour cette raison précise, et sans ce lien retour n'importe qui pourrait créer des alias de handle pour des comptes tiers, donc un enregistrement TXT nommant le DID de quelqu'un d'autre ne mène à rien.

Puis-je publier sous mon handle de domaine personnalisé juste après avoir publié l'enregistrement ?

Pas toujours tout de suite. Les services mettent en cache les résultats de résolution de handle pendant un certain temps, donc une réponse périmée peut persister même une fois l'enregistrement correct. Le TTL de l'enregistrement d'exemple ci-dessus est de 300 secondes, et fixer un TTL court avant le changement puis résoudre à nouveau ensuite réduit justement cette attente.

Qu'arrive-t-il à mon ancien nom d'utilisateur .bsky.social après le passage à un domaine personnalisé ?

Il reste à vous. Depuis décembre 2024, Bluesky réserve votre ancien handle .bsky.social plutôt que de le relâcher quand vous passez à un domaine personnalisé, donc personne d'autre ne peut le récupérer.

Une redirection de mon domaine racine vers www casse-t-elle la vérification du handle ?

Pas en soi. La spec autorise les redirections HTTP jusqu'à un nombre raisonnable de sauts, donc rediriger du domaine racine vers www pour le chemin well-known ne pose pas de problème en lui-même. Ça casse la vérification seulement si la redirection atterrit là où le fichier n'a jamais été déployé, puisqu'une redirection qui finit sur une 404 ne résout rien.