Die zwei Records hinter einem Bluesky-Handle mit eigener Domain

Was ist ein Bluesky-Handle mit eigener Domain?

Eine Domain, die dir gehört, wird zum Bluesky-Handle mit eigener Domain, sobald du einen einzigen Record veröffentlichst, der deine Kontrolle darüber belegt: entweder einen DNS-TXT-Record auf der Subdomain _atproto oder eine Klartextdatei unter /.well-known/atproto-did. Bluesky läuft auf dem AT Protocol, und dessen Handle-Spezifikation entscheidet, ob dein Record funktioniert. Hilfeartikel beschreiben die Buttons in der App. Die Spezifikation beschreibt, was das Netzwerk danach prüft.

Lies das, bevor du DNS anfasst: „Handles are mutable and human-friendly account usernames, in the form of a DNS hostname." Dein Handle ist ein Hostname, und deshalb funktioniert mozilla.org, während mozilla allein scheitert: „'bare' top-level domains are not allowed as handles, even if valid 'hostnames' and 'DNS names.'"

Hinter jedem Handle steckt eine DID, in den Worten der Spezifikation eine der „long-term persistent identifiers for accounts in atproto". Du trägst deine DID in den Record ein, für den du dich entscheidest, und genau dieser Teil ist hier relevant. Alles Weitere zu DIDs gehört auf eine eigene Seite.

Welchen Record veröffentlichst du, und was steht darin?

Veröffentliche einen dieser beiden, mit deiner eigenen DID anstelle des Beispiels.

Das Präfix ist der häufigste Copy-Paste-Fehler, und keine der beiden Methoden warnt dich. DNS-Resolver ignorieren „TXT records with values not starting with did=." Über HTTPS zerstört genau dieses Präfix den Body, den die Spezifikation als „the DID... with no prefix or wrapper formatting" verlangt.

Der DNS-Record für ein Handle auf der Apex-Domain example.com:

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

Für ein Subdomain-Handle wie alice.example.com lautet der Name _atproto.alice. Die meisten DNS-Panels hängen die Zone selbst an, sodass die Eingabe des vollständigen _atproto.alice.example.com zu _atproto.alice.example.com.example.com führt und still fehlschlägt.

Es darf nur ein Record existieren: „If multiple valid records with different DIDs are present, resolution should fail." Ein alter Record aus einem früheren Konto zerstört den neuen.

Die HTTPS-Antwort, die die Spezifikation verlangt, exakt wiedergegeben:

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

did:plc:ewvi7nxzyoun6zhxrhs64oiz

Einen Absatz später, im selben Abschnitt, lockert die Spezifikation ihre eigene Anforderung: „The response Content-Type header does not need to be strictly verified." Liefere trotzdem text/plain aus, denn du weißt nicht, welcher Resolver welche Zeile liest.

Deine DID bekommst du in der App. Blueskys Anleitung nennt als Pfad „Settings", dann „Account", dann „Handle", und zeigt als Record-Host _atproto mit dem Wert "did=did:plc:[your value here]".

Wie lauten die Syntaxregeln für Handles?

Sieben Regeln, und ein Handle muss sie alle erfüllen:

1. Das gesamte Handle besteht nur aus ASCII und ist höchstens 253 Zeichen lang.
2. Segmente werden durch ASCII-Punkte getrennt, und es müssen mindestens zwei davon vorhanden sein.
3. Keine Punkte am Anfang oder Ende, und keine DNS-Syntax mit abschließendem Punkt.
4. Jedes Segment ist 1 bis 63 Zeichen lang und besteht aus den ASCII-Buchstaben a-z, den Ziffern 0-9 und Bindestrichen -.
5. Ein Segment darf nicht mit einem Bindestrich beginnen oder enden.
6. Das letzte Segment, die Top-Level-Domain, darf nicht mit einer Ziffer beginnen.
7. Handles unterscheiden nicht zwischen Groß- und Kleinschreibung und werden zu Kleinbuchstaben normalisiert.

Zur letzten Regel: „the handle input string BlueskyWeb.xyz should be normalized, stored, and displayed as blueskyweb.xyz." Wenn deine Marke großgeschrieben wird, das Handle wird es nicht.

Der Referenz-Regex aus der Spezifikation:

/^([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 ist die plakative Zahl und nicht die, nach der du planen solltest. In den Implementierungshinweisen versteckt sich eine kleinere: „handles should be limited to at most 244 characters... because DNS verification works with the prefix _atproto., which adds 9 characters." Alles zwischen 245 und 253 Zeichen ist nach dem Syntaxabschnitt zulässig und per DNS nicht auflösbar, und der Notausgang steht in einem anderen Abschnitt: „The HTTPS method will work for such handles."

Beispiele, die die Spezifikation als gültig markiert, neben denen, die sie ablehnt:

Internationalisierte Domains funktionieren nur in kodierter Form: „Such handles must be stored and transmitted in encoded ASCII form."

Welche TLDs können niemals ein Bluesky-Handle sein?

Acht Top-Level-Domains sind rundweg ausgeschlossen. Aus der Spezifikation: „the initial list of disallowed TLDs includes: .alt, .arpa, .example, .internal, .invalid, .local, .localhost, .onion."

Ihr Fehlerverhalten ist gewollt und merkwürdig. Reservierte TLDs „should not fail syntax validation... but they must immediately fail any attempt at registration, resolution, etc." Also bestehen laptop.local und blah.arpa eine Regex-Prüfung und scheitern für immer bei der Auflösung. Ein Validator, der nur den Regex ausführt, hält das Handle für in Ordnung, bis das Netzwerk es zurückweist.

Drei Einträge tragen zusätzliche Bedingungen:

• .onion ist aus einem genannten Grund gesperrt und nicht dauerhaft: „Resolution of handles via Tor would require ecosystem-wide support, so they are currently disallowed." Der Abschnitt zu künftigen Änderungen ergänzt, dass „.onion handles would be allowed at some point in the future".
• .invalid ist für einen einzigen Signalwert reserviert, handle.invalid, den die API zurückgibt, „to indicate that there is no bi-directionally valid handle for the given DID."
• .test steht nicht auf der Sperrliste und ist trotzdem nicht nutzbar. Die TLD „may be used in atproto development, but should fail in real-world environments."

Beachte das Wort „initial". Die Liste ist nicht als endgültig formuliert, und die Spezifikation verlinkt den Wikipedia-Abschnitt zu reservierten Domains, statt ein eigenes Verzeichnis zu führen. Acht Namen sind das, worauf sich das Protokoll schriftlich festlegt, und die Grenze dahinter wird auf einer Seite gezogen, die niemand im AT-Protocol-Projekt kontrolliert.

Wie löst du ein Handle zu seiner DID auf?

Führe es gegen ein echtes Konto aus, und beide Hälften der Prüfung laufen vor deinen Augen ab. Jeder Wert unten wurde am 10. September 2026 aufgelöst.

Beginne mit dem DNS-Record für bsky.app, Blueskys eigenem Handle:

dig +short TXT _atproto.bsky.app

"did=did:plc:z72i7hdynmk6r22z27h6tvur"

Entferne das Präfix did=, und du hast die DID. Der Endpunkt des Protokolls, den Clients aufrufen, statt selbst DNS abzufragen, liefert dieselbe Antwort:

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

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

Hole jetzt das DID-Dokument ab, die andere Hälfte der Prüfung:

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

Das Feld, das alles entscheidet, ist alsoKnownAs mit dem Inhalt at://bsky.app. Das Handle zeigte auf die DID, und das DID-Dokument zeigt zurück. Die Spezifikation verlangt beide Richtungen: „The link between handle and DID must be confirmed bidirectionally, otherwise anybody could create handle aliases for third-party accounts." Einen TXT-Record zu veröffentlichen, der die DID einer anderen Person nennt, bringt dir nichts, denn deren DID-Dokument nennt deine Domain nicht.

Wenn ein Handle sich nicht auflösen lässt, antwortet der Endpunkt mit einem einzigen String:

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

Das kommt mit HTTP 400, und es ist dieselbe Meldung für einen fehlenden Record, ein gültiges Handle auf einer reservierten TLD und eine Domain, die es nicht gibt. Diagnostiziere mit dig und curl, statt die API-Antwort zu lesen.

Vier Handles, die an diesem Tag aufgelöst wurden, alle bidirektional gegen plc.directory bestätigt:

Diese Aufteilung ist das Design der Spezifikation, so wie es geschrieben steht. Organisationen mit einem DNS-Panel nutzen den TXT-Record. Das Handle, das über HTTPS antwortet, ist eine bsky.social-Subdomain, also der Fall der „large-scale web services which may not have the infrastructure to automate the registration of thousands or millions of DNS TXT records", für den die Methode gebaut wurde.

Der Aufruf von https://mozilla.org/.well-known/atproto-did liefert eine 404-HTML-Seite, und theverge.com macht dasselbe. Beide Handles lösen sich problemlos auf. Nur eine Methode muss antworten, und ein 404 auf dem Pfad, den du nicht nutzt, kostet dich nichts.

Wo gehen Handles mit eigener Domain kaputt?

Weiterleitungen verdienen eine Anmerkung, weil andere well-known-Spezifikationen sie verbieten und diese nicht: „HTTP redirects (eg, 301, 302) are allowed, up to a reasonable number of redirect hops." Eine Weiterleitung vom Apex auf www ist in Ordnung. Eine Weiterleitung, die auf einem 404 landet, nicht, und genau das passiert, wenn der Apex auf www weiterleitet und die Datei dort nie ausgeliefert wurde.

Was passiert mit deinen geplanten Beiträgen, wenn sich das Handle ändert?

Nichts, und der Grund ist struktureller Natur. Dein Konto ist die DID, die das Protokoll als dauerhaft bezeichnet, während das Handle ein veränderliches Label ist, das jedes Mal neu aufgelöst wird, wenn ein Client es braucht. Der Wechsel von you.bsky.social zu yourbrand.com lässt die DID unberührt, sodass eine Warteschlange in einem Bluesky-Post-Scheduler den Umstieg übersteht, und die Zahlen in einem Bluesky-Analytics-Tool ebenso. Das ist Protokollverhalten, nichts, was ein Publishing-Tool gewährt oder verweigert.

Zwei Dinge ändern sich doch. Bereits veröffentlichte Beiträge erscheinen jetzt unter dem neuen Handle, weil Clients das Handle rendern, das sie auflösen, und nicht eines, das zum Zeitpunkt der Veröffentlichung eingefroren wurde. Und jeder Text, der dein altes Handle nennt, ist jetzt falsch, was am stärksten dann weh tut, wenn du denselben Beitrag gleichzeitig in mehreren Netzwerken veröffentlichst und das Bluesky-Handle in einer Bildunterschrift steht, die du mit X, LinkedIn und Threads teilst. Durchsuche deine Entwürfe in der Warteschlange nach dem alten String, bevor du wechselst. Fünf Minuten in einem Content-Kalender, gegen einen Monat veröffentlichter Beiträge, die du danach korrigieren musst.

Häufig gestellte Fragen

Brauche ich sowohl den DNS-Record als auch die well-known-Datei?

Nein. Einer davon reicht, und die Spezifikation nennt die DNS-TXT-Methode „the recommended and preferred resolution method for individual handle configuration." Wenn du beide veröffentlichst und sie unterschiedliche DIDs nennen, bevorzugen Resolver die DNS-Antwort. Lösche den veralteten Eintrag, statt den Konflikt bestehen zu lassen.

Warum braucht mein TXT-Record did=, die HTTPS-Datei aber nicht?

Die beiden Methoden parsen unterschiedlich. DNS folgt RFC-1464 für das Speichern von Attributen in TXT-Records, der Wert besteht also aus Schlüssel und Wert, und Resolver ignorieren „TXT records with values not starting with did=." Die HTTPS-Methode liefert „the DID as the HTTP body with no prefix or wrapper formatting", weshalb dasselbe Präfix den Body unlesbar macht.

Kann ich zum Testen eine .local- oder .internal-Domain nutzen?

Nein. Beide stehen auf der Sperrliste, und reservierte TLDs „must immediately fail any attempt at registration, resolution, etc.", obwohl sie die Syntaxprüfung bestehen. Die TLD .test ist die für Entwicklung gedachte, und die Spezifikation erwartet trotzdem, dass sie „fail in real-world environments".

Wie lang darf ein Bluesky-Handle sein?

253 ASCII-Zeichen nach den Syntaxregeln, 244 in der Praxis. Das Präfix _atproto., das für die DNS-Verifizierung genutzt wird, „adds 9 characters, and that overall name needs to be valid." Oberhalb von 244 löst nur die HTTPS-Methode auf.

Was ist handle.invalid, und warum sehe ich das?

Es ist der Wert, den die API zurückgibt, wenn eine DID kein funktionierendes Handle hat, verwendet „to indicate that there is no bi-directionally valid handle for the given DID." Er taucht auf, nachdem ein einmal auflösbares Handle nicht mehr auflöst. Den korrekten Record erneut zu veröffentlichen, räumt ihn weg.

Bricht eine Handle-Änderung Links, die andere schon geteilt haben?

Nein. Blueskys Anleitung stellt fest: „Any tags or mentions with your old handle will still point to your account", weil Erwähnungen die DID speichern und nicht den Handle-Text. Seit Dezember 2024 bleibt dein früherer .bsky.social-Benutzername außerdem für dich reserviert, statt freigegeben zu werden.

Warum funktioniert es nicht, die DID einer anderen Person in meinem TXT-Record einzutragen?

Das Protokoll prüft die Verknüpfung in beide Richtungen. Dein Record kann auf jede beliebige DID zeigen, aber das DID-Dokument muss im Feld alsoKnownAs mit einer at://-URI auch auf deine Domain zurückzeigen. Das DID-Dokument von bsky.app listet genau deshalb at://bsky.app auf, und ohne diese Rückverknüpfung könnte sonst jeder Handle-Aliasse für fremde Konten anlegen, weshalb ein TXT-Record mit der DID einer anderen Person zu nichts führt.

Kann ich sofort nach dem Veröffentlichen des Records unter meinem Custom-Domain-Handle posten?

Nicht unbedingt sofort. Dienste cachen Ergebnisse der Handle-Auflösung eine Weile intern, sodass eine veraltete Antwort auch nach einem korrekten Record noch bestehen bleiben kann. Die TTL im Beispiel-Record oben liegt bei 300 Sekunden, und eine kurze TTL vor der Änderung mit anschließendem erneuten Auflösen verkürzt genau diese Wartezeit.

Was passiert mit meinem alten .bsky.social-Benutzernamen nach dem Wechsel zu einer eigenen Domain?

Er bleibt für dich reserviert. Seit Dezember 2024 hält Bluesky dein bisheriges .bsky.social-Handle zurück, statt es freizugeben, sobald du zu einer eigenen Domain wechselst, sodass niemand sonst es beanspruchen kann.

Bricht eine Weiterleitung von meiner Apex-Domain auf www die Handle-Verifizierung?

Nicht von sich aus. Die Spezifikation erlaubt HTTP-Weiterleitungen bis zu einer angemessenen Anzahl an Hops, eine Weiterleitung von der Apex-Domain auf www für den well-known-Pfad ist also für sich genommen kein Problem. Problematisch wird es nur, wenn die Weiterleitung an einer Stelle landet, an der die Datei nie bereitgestellt wurde, denn eine Weiterleitung, die in einer 404 endet, löst sich nicht auf.