Los dos registros detrás de un handle de dominio personalizado en Bluesky

¿Qué es un handle de dominio personalizado en Bluesky?

Un dominio de tu propiedad se convierte en tu handle de dominio personalizado en Bluesky en cuanto publicas un registro que demuestre que lo controlas: un registro DNS TXT en el subdominio _atproto o un archivo de texto plano servido en /.well-known/atproto-did. Bluesky funciona sobre el AT Protocol, y su especificación de handles decide si tu registro sirve. Los artículos de ayuda describen los botones de la app. La especificación describe lo que la red comprueba después.

Lee esto antes de tocar el DNS: "Handles are mutable and human-friendly account usernames, in the form of a DNS hostname." Tu handle es un nombre de host, por eso mozilla.org funciona y mozilla a secas no: "'bare' top-level domains are not allowed as handles, even if valid 'hostnames' and 'DNS names.'"

Detrás de cada handle hay un DID, uno de los que la especificación llama "the long-term persistent identifiers for accounts in atproto". Pegas tu DID en el registro que elijas, así que esa es la parte que necesitas aquí. El resto de lo que es un DID corresponde a su propia página.

¿Qué registro publicas y qué va dentro?

Publica uno de estos dos, con tu propio DID en lugar del ejemplo.

El prefijo es el error de pegado más común, y ninguno de los dos métodos te avisa. Los resolutores DNS ignoran "TXT records with values not starting with did=." Por HTTPS ese mismo prefijo rompe el cuerpo, que la especificación quiere como "the DID... with no prefix or wrapper formatting".

El registro DNS para un handle en el ápice de example.com:

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

Para un handle de subdominio como alice.example.com, el nombre es _atproto.alice. La mayoría de los paneles DNS añaden la zona por ti, así que escribir el _atproto.alice.example.com completo produce _atproto.alice.example.com.example.com y un fallo silencioso.

Solo puede existir un registro: "If multiple valid records with different DIDs are present, resolution should fail." Un registro antiguo de una cuenta anterior rompe el nuevo.

La respuesta HTTPS que pide la especificación, reproducida tal cual:

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 párrafo después, en la misma sección, la especificación relaja su propio requisito: "The response Content-Type header does not need to be strictly verified." Sirve text/plain de todos modos, porque no sabes qué resolutor lee qué línea.

Tu DID sale de la app. El tutorial de Bluesky da la ruta como "Settings", luego "Account", luego "Handle", y muestra el host del registro como _atproto con el valor "did=did:plc:[your value here]".

¿Cuáles son las reglas de sintaxis de los handles?

Siete reglas, y un handle tiene que cumplirlas todas:

1. El handle completo es solo ASCII y tiene como máximo 253 caracteres.
2. Los segmentos se separan con puntos ASCII, y tiene que haber al menos dos.
3. Sin puntos al principio ni al final, y sin la sintaxis DNS del punto final.
4. Cada segmento tiene de 1 a 63 caracteres, tomados de las letras ASCII a-z, los dígitos 0-9 y los guiones -.
5. Un segmento no puede empezar ni terminar con un guion.
6. El último segmento, el dominio de nivel superior, no puede empezar con un dígito.
7. Los handles no distinguen mayúsculas de minúsculas y se normalizan a minúsculas.

Sobre la última regla: "the handle input string BlueskyWeb.xyz should be normalized, stored, and displayed as blueskyweb.xyz." Si tu marca lleva mayúsculas, el handle no las llevará.

La expresión regular de referencia de la especificación:

/^([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 es la cifra de titular y no la que conviene tomar como guía. Enterrada en las pautas de implementación hay otra más pequeña: "handles should be limited to at most 244 characters... because DNS verification works with the prefix _atproto., which adds 9 characters." Cualquier cosa entre 245 y 253 caracteres es legal según la sección de sintaxis e irresoluble por DNS, y la salida de emergencia está en otra sección: "The HTTPS method will work for such handles."

Ejemplos que la especificación marca como válidos, junto a los que rechaza:

Los dominios internacionalizados funcionan solo en forma codificada: "Such handles must be stored and transmitted in encoded ASCII form."

¿Qué TLD nunca pueden ser un handle de Bluesky?

Ocho dominios de nivel superior están vetados de plano. De la especificación: "the initial list of disallowed TLDs includes: .alt, .arpa, .example, .internal, .invalid, .local, .localhost, .onion."

Su modo de fallo es deliberado y raro. Los TLD reservados "should not fail syntax validation... but they must immediately fail any attempt at registration, resolution, etc." Así que laptop.local y blah.arpa pasan una comprobación con regex y fallan para siempre en la resolución. Un validador que solo ejecute la regex da el handle por bueno hasta que la red lo rechaza.

Tres elementos llevan condiciones extra:

• .onion está bloqueado por un motivo declarado y no de forma permanente: "Resolution of handles via Tor would require ecosystem-wide support, so they are currently disallowed." La sección de cambios futuros añade que ".onion handles would be allowed at some point in the future".
• .invalid está reservado para un único valor centinela, handle.invalid, que la API devuelve "to indicate that there is no bi-directionally valid handle for the given DID."
• .test no está en la lista de vetados y tampoco se puede usar. "may be used in atproto development, but should fail in real-world environments."

Fíjate en la palabra "initial". La lista no se plantea como definitiva, y la especificación enlaza la sección de dominios reservados de Wikipedia en lugar de mantener su propio registro. Ocho nombres son a lo que el protocolo se compromete por escrito, y la frontera más allá de ellos se traza en una página que nadie del proyecto AT Protocol controla.

¿Cómo resuelves un handle hasta su DID?

Pruébalo contra una cuenta real y las dos mitades de la comprobación ocurren delante de ti. Todos los valores de abajo se resolvieron el 10 de septiembre de 2026.

Empieza por el registro DNS de bsky.app, el handle propio de Bluesky:

dig +short TXT _atproto.bsky.app

"did=did:plc:z72i7hdynmk6r22z27h6tvur"

Quita el prefijo did= y tienes el DID. El endpoint del propio protocolo, al que llaman los clientes en lugar de hacer DNS por su cuenta, devuelve la misma respuesta:

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

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

Ahora pide el documento DID, que es la otra mitad de la comprobación:

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"
    }
  ]
}

El campo que lo decide todo es alsoKnownAs, que contiene at://bsky.app. El handle apuntaba al DID, y el documento DID apunta de vuelta. La especificación exige las dos direcciones: "The link between handle and DID must be confirmed bidirectionally, otherwise anybody could create handle aliases for third-party accounts." Publicar un registro TXT que nombre el DID de otra persona no te sirve de nada, porque su documento DID no nombra tu dominio.

Cuando un handle no resuelve, el endpoint responde con una sola cadena:

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

Llega con HTTP 400, y es el mismo mensaje para un registro que falta, un handle válido en un TLD reservado y un dominio que no existe. Diagnostica con dig y curl en lugar de leer la respuesta de la API.

Cuatro handles resueltos ese día, todos confirmados de forma bidireccional contra plc.directory:

Ese reparto es el diseño de la especificación funcionando tal como está escrito. Las organizaciones con un panel DNS usan el registro TXT. El handle que responde por HTTPS es un subdominio de bsky.social, el caso de los "large-scale web services which may not have the infrastructure to automate the registration of thousands or millions of DNS TXT records" para el que se construyó el método.

Pedir https://mozilla.org/.well-known/atproto-did devuelve una página HTML 404, y theverge.com hace lo mismo. Los dos handles resuelven bien. Solo un método tiene que responder, y un 404 en la ruta que no usaste no te cuesta nada.

¿Dónde se rompen los handles de dominio personalizado?

Las redirecciones merecen una nota, porque otras especificaciones well-known las prohíben y esta no: "HTTP redirects (eg, 301, 302) are allowed, up to a reasonable number of redirect hops." Una redirección del ápice a www está bien. Una redirección que aterriza en un 404 no lo está, que es lo que pasa cuando el ápice reenvía a www y el archivo nunca se desplegó ahí.

¿Qué pasa con tus publicaciones programadas cuando cambia el handle?

Nada, y el motivo es estructural. Tu cuenta es el DID, que el protocolo llama persistente, mientras que el handle es una etiqueta mutable que se resuelve de nuevo cada vez que un cliente la necesita. Pasar de you.bsky.social a yourbrand.com deja el DID intacto, así que una cola creada en un programador de publicaciones para Bluesky sobrevive al cambio, y también las cifras de una herramienta de analíticas de Bluesky. Eso es comportamiento del protocolo, no algo que una herramienta de publicación conceda o retire.

Dos cosas sí cambian. Las publicaciones que ya publicaste ahora se muestran bajo el handle nuevo, porque los clientes renderizan el handle que resuelven y no uno congelado en el momento de publicar. Y cualquier texto que nombre tu handle antiguo ahora está mal, algo que muerde más fuerte cuando publicas el mismo post en varias redes a la vez y el handle de Bluesky va en un pie compartido con X, LinkedIn y Threads. Busca la cadena antigua en tus borradores en cola antes del cambio. Cinco minutos en un calendario de contenido, frente a un mes de publicaciones que corregir después.

Preguntas frecuentes

¿Necesito el registro DNS y el archivo well-known a la vez?

No. Con uno basta, y la especificación llama al método DNS TXT "the recommended and preferred resolution method for individual handle configuration." Si publicas los dos y nombran DID distintos, los resolutores prefieren la respuesta DNS. Borra el obsoleto en vez de dejar el conflicto ahí.

¿Por qué mi registro TXT necesita did= y el archivo HTTPS no?

Los dos métodos se parsean de forma distinta. DNS sigue el RFC-1464 para guardar atributos en registros TXT, así que el valor es una clave y un valor, y los resolutores ignoran "TXT records with values not starting with did=." El método HTTPS devuelve "the DID as the HTTP body with no prefix or wrapper formatting", así que ese mismo prefijo hace el cuerpo imparseable.

¿Puedo usar un dominio .local o .internal para pruebas?

No. Los dos están en la lista de vetados, y los TLD reservados "must immediately fail any attempt at registration, resolution, etc." aunque pasen la validación de sintaxis. El TLD .test es el pensado para desarrollo, y la especificación sigue esperando que "fail in real-world environments".

¿Cuánto puede medir un handle de Bluesky?

253 caracteres ASCII según las reglas de sintaxis, 244 en la práctica. El prefijo _atproto. que se usa para la verificación DNS "adds 9 characters, and that overall name needs to be valid." Por encima de 244, solo resuelve el método HTTPS.

¿Qué es handle.invalid y por qué lo estoy viendo?

Es el valor que devuelve la API cuando un DID no tiene handle que funcione, usado "to indicate that there is no bi-directionally valid handle for the given DID." Aparece después de que un handle que antes resolvía deje de hacerlo. Volver a publicar el registro correcto lo limpia.

¿Cambiar mi handle rompe los enlaces que ya compartió la gente?

No. El tutorial de Bluesky afirma que "Any tags or mentions with your old handle will still point to your account", porque las menciones guardan el DID y no el texto del handle. Desde diciembre de 2024 tu nombre de usuario .bsky.social anterior también queda reservado para ti en vez de liberarse.

¿Por qué no funciona publicar el DID de otra persona en mi registro TXT?

El protocolo comprueba el enlace en ambas direcciones. Tu registro puede nombrar cualquier DID, pero el documento DID también tiene que enlazar de vuelta a tu dominio en el campo alsoKnownAs, con una URI at://. El documento DID de bsky.app incluye at://bsky.app precisamente por eso, y sin ese enlace inverso cualquiera podría crear alias de handle para cuentas ajenas, así que un registro TXT que nombre el DID de otra persona no lleva a ningún sitio.

¿Puedo empezar a publicar con mi handle de dominio propio justo después de publicar el registro?

No siempre de inmediato. Los servicios almacenan en caché los resultados de resolución de handles durante un tiempo, así que una respuesta antigua puede seguir apareciendo incluso con el registro ya correcto. El TTL del registro de ejemplo de arriba es de 300 segundos, y poner un TTL corto antes del cambio y volver a resolver después acorta esa espera.

¿Qué pasa con mi antiguo nombre de usuario .bsky.social al cambiar a un dominio propio?

Se queda reservado para ti. Desde diciembre de 2024, Bluesky guarda tu handle anterior de .bsky.social en lugar de liberarlo cuando cambias a un dominio propio, así que nadie más puede quedárselo.

¿Una redirección de mi dominio raíz a www rompe la verificación del handle?

No por sí sola. La especificación permite redirecciones HTTP hasta un número razonable de saltos, así que redirigir del dominio raíz a www para la ruta well-known está bien por sí mismo. El problema aparece solo si la redirección termina donde el archivo nunca se publicó, porque una redirección que acaba en un 404 no resuelve.