Zusammenfassung

  • RFC 10023 definiert unter _for-sale.<Domain> ein TXT-Signal. Ein gültiger Datensatz beginnt exakt und groß-/kleinschreibungsabhängig mit v=FORSALE1; und kann einen Hinweis vom Typ fcod, ftxt, furi oder fval tragen.
  • Das Signal erklärt die Domain im weiten Sinn für verhandelbar. Ein Preis bleibt unverbindlich, eine URI bleibt unvertrauenswürdig, und DNSSEC authentisiert DNS-Daten statt der rechtlichen Befugnis, die Domain zu veräußern.
  • Für einen belastbaren Erwerb müssen Zonenbeobachtung, Änderungsrecht, Registrantenidentität, Vertretungsmacht, Vertragsstand, Zahlung, Registrar-Transfer und Dienstkontinuität getrennt nachgewiesen werden.

Ein authentischer Datensatz kann eine unbefugte Aussage enthalten

Das Monitoring eines Konzerns meldet unter seiner wichtigsten Domain plötzlich einen Preis. Ein zweiter TXT verweist auf eine HTTPS-Seite. Die DNSSEC-Prüfung ist erfolgreich. Der Marktplatz nennt das Angebot „verifiziert“, obwohl die Domain weiterhin E-Mail, Kundenanmeldung und Zertifikate trägt.

Technisch kann diese Darstellung sauber sein und institutionell dennoch falsch liegen.

Vielleicht durfte der DNS-Dienstleister die Zone ändern, aber nicht das Vermögen des Registranten verkaufen. Vielleicht wurde ein API-Token missbraucht. Vielleicht ist die verlinkte Vermittlung echt, ihr Auftrag jedoch beendet. Vielleicht bezeichnet „for sale“ nur eine Miete oder ein Nutzungsrecht. Selbst ein erfolgreicher Registrarwechsel kann Nameserver, DNSSEC, Mail und Identitätsdienste beschädigen.

RFC 10023 wurde im Juli 2026 als Informational RFC veröffentlicht. Die Betriebsvereinbarung erlaubt einem Inhaber, den reservierten Leaf-Namen _for-sale in die Zone einzufügen und damit die Verfügbarkeit der übergeordneten Domain anzuzeigen. „For sale“ umfasst ausdrücklich auch Miete oder die Überlassung vertraglicher Nutzungsrechte. Das Signal lässt sich bei laufendem Betrieb setzen und benötigt keine Protokolländerung.

Registrierungsdaten beantworten, ob ein Name registriert ist. Sie beantworten nicht automatisch, ob er erhältlich ist. RFC 10023 schließt diese Entdeckungslücke. Die Verhandlung bleibt außerhalb seines Geltungsbereichs.

Der Versionsstring trägt die Kernbehauptung

Der Datensatz muss mit v=FORSALE1; beginnen — exakt, ohne Leerzeichen und mit passender Großschreibung. Danach ist höchstens ein Tag-Wert-Paar zulässig:

  • fcod= enthält einen undurchsichtigen Code, dessen Bedeutung kooperierende Verarbeiter vereinbaren;
  • ftxt= enthält knappen, menschenlesbaren Text;
  • furi= enthält genau eine URI oder IRI für Kontakt oder weitere Information;
  • fval= enthält Großbuchstaben für die Währung und einen Zahlenbetrag.

Ein RRset darf mehrere TXT-Datensätze enthalten. Derselbe Tag darf mit verschiedenen Werten wiederkehren, solange jedes vollständige Paar eindeutig ist. Der Verarbeiter darf einen oder mehrere Datensätze auswählen.

Auswahl ist Interpretation. Ein Marktplatz erkennt nur seinen fcod, ein Preisindex liest fval, eine Bedienoberfläche zeigt Text und Telefon. Keine Ansicht ist mit dem vollständigen RRset identisch. Wer eine Entscheidung belegen will, speichert die gesamte Antwort und die Auswahlregel.

Auch leerer oder ungültiger Zusatzinhalt hebt die Anzeige nicht zwingend auf. Bei gültiger Version sollen Verarbeiter normalerweise von Verfügbarkeit ausgehen, sofern lokale Regeln nichts anderes bestimmen, und können über herkömmliche Registrierungsdaten Kontakt suchen. Fehlt dagegen in allen TXT die gültige Version, ist der Knoten für diese Konvention zu ignorieren — auch wenn ein freier Text verkaufsähnlich klingt.

Der Versionsstring erklärt eine Aussage für RFC-10023-erkennbar. Er erklärt niemanden zum zeichnungsberechtigten Verkäufer.

fcod verlagert Bedeutung in eine private Tabelle

Die Semantik von fcod entsteht durch Vereinbarung. Ein Registry- oder Registrar-Verbund kann ein Präfix erkennen und daraus eine Verkaufsseite ableiten. Das Backend darf sein Ziel zentral ändern, ohne den DNS-Wert neu zu veröffentlichen. Das erleichtert Pflege und verhindert beliebige Weiterleitungen.

Gleichzeitig verschwindet die entscheidende Zuordnung aus dem öffentlichen Beleg. Ein Außenstehender kann den Code nicht selbst deuten. Ändert sich die Tabelle, führt derselbe TXT an einen anderen Ort. Ohne versionierte Historie kann nur der Betreiber sagen, was ein Käufer zu einem bestimmten Zeitpunkt sah. Die Syntax bleibt portabel, ihre praktische Bedeutung nicht.

ftxt ist flexibel und deshalb als unbereinigte Eingabe zu behandeln. Steuerzeichen, Unicode-Täuschung und gefährliches Markup sind möglich. Die Zeichenfolge ;ftxt= kann innerhalb eines gültigen fcod-Werts vorkommen, ohne einen zweiten Tag zu bilden. Ein Parser, der nur an Satzzeichen trennt, erfindet Felder.

furi kapselt genau eine maschinenlesbare Adresse. Empfohlen werden HTTP, HTTPS, mailto und tel; HTTPS ist, wo passend, vorzuziehen. Formale Gültigkeit ist keine Reputationsprüfung. RFC 10023 warnt vor Phishing, Malware und Skriptangriffen und untersagt automatische Weiterleitung ohne ausdrückliche Bestätigung.

fval strukturiert den Richtpreis. Standard-Fiatwährungen sollen als drei Großbuchstaben erscheinen; auch geläufige Kryptoabkürzungen passen in die Grammatik. Der Wert ist ausdrücklich indikativ und unverbindlich. Automatisierte Systeme sollen allein daraus keine Kaufzusage erzeugen.

Die Tags liefern Anknüpfungspunkte. Sie definieren weder den veräußerten Rechtsumfang noch Identität, Gewährleistung, Steuer, Annahme, Treuhand oder Transfer.

255 Oktette sind kein Datenraum

Jedes TXT-RDATA besteht aus genau einer character-string und höchstens 255 Oktetten. Weitere Hinweise stehen in weiteren Datensätzen. RFC 1035 bildet die Grundlage für TXT und TTL, RFC 10023 fügt die Anwendungssyntax hinzu.

Verarbeiter müssen rohes RDATA auswerten, nicht das maskierte Darstellungsformat eines Abfragewerkzeugs. Für Nicht-ASCII gelten Empfehlungen zu UTF-8 und Network Unicode. Unerwartete Steuerzeichen sind bei der Anzeige zu entschärfen, während der Originalwert für die Beweiskette erhalten bleibt.

Das kurze Format hält die gemeinsame Schicht klein. DNS eignet sich für ein kompaktes Auffindbarkeitssignal, nicht für eine Vertragsakte. Private Zusatzsemantik muss als private Abhängigkeit dokumentiert werden.

Die Leaf-Position bestimmt den Gegenstand

_for-sale.example bezieht sich auf example. xyz._for-sale.example ist nicht konform, weil _for-sale kein Leaf mehr ist. Mit _for-sale.*.example lässt sich nicht eine ganze Zone pauschal anbieten. RFC 4592 beschreibt DNS-Wildcards; RFC 10023 schließt diese Konstruktion aus.

Vorhandene Wildcards können dennoch Antworten synthetisieren, insbesondere zusammen mit CNAME oder DNAME. Ein Sammler braucht Abfragenamen, Answer Owner, Alias-Kette, autoritative Antwort und Synthesehinweise. Der letzte TXT allein kann die falsche Domain bezeichnen.

Die Anzeige kann auf mehreren DNS-Ebenen stehen. Unter einer Subdomain ohne öffentliches Rechteregister ist gegebenenfalls eine besondere Vereinbarung nötig. Datensätze unter .arpa müssen ignoriert werden, weil sie wie Angebote von Adressraum oder E.164-Nummern wirken könnten. Special-Use-Domains liegen außerhalb des Geltungsbereichs.

RFC 8552 erläutert, wie global unterscorte Namen Bedeutungsüberschneidungen verhindern. Im IANA-Register für DNS-Parameter steht nun TXT / _for-sale / RFC 10023. Diese Registrierung belegt die Namenszuweisung, nicht Einführung, Wahrheitsgehalt oder Verfügungsbefugnis.

Das Errata-Register zu RFC 10023 enthält den technischen Eintrag 9090 mit Status Reported. Er beanstandet „Root zone“ in der ersten Tabellenzeile von Abschnitt 2.6 und schlägt TLD- oder Zone-Apex-Sprache vor. Reported ist nicht Verified; der Hinweis ist Prüfstoff, keine bestätigte normative Änderung.

TTL lässt Cache veralten, nicht Marktdaten verschwinden

Ist die Domain nicht mehr verfügbar, soll der Inhaber das Signal entfernen. RFC 10023 empfiehlt höchstens 3.600 Sekunden TTL, weil lange Zwischenspeicherung eine zurückgezogene Verfügbarkeit oder einen alten Preis weiterzeigen kann.

Crawler, Screenshots und Broker-Datenbanken unterliegen diesem TTL nicht. Eine Stunde ist außerdem keine rechtliche Bindungsfrist. Jede Beobachtung benötigt Uhrzeit, TTL, Resolver, vollständige Antwort und Validierungsstatus; an Kontakt, Angebot, Annahme, Freigabe und Transfer muss erneut autoritativ geprüft werden.

Auch Abwesenheit ist kein Beweis. Redemption, pendingDelete oder ein DNSSEC-bogus-Zustand können die Auflösung verhindern. Ein fehlender Datensatz kann Betriebszustand statt Verkaufsunwillen bedeuten.

DNSSEC prüft keine Handlungsvollmacht

RFC 4033 beschreibt Ursprungsauthentisierung und Integritätsschutz für DNS-Daten innerhalb der Vertrauenskette; Vertraulichkeit liefert DNSSEC nicht. Ein validierter RRset ist starke Evidenz dafür, dass diese DNS-Daten unter den relevanten Schlüsseln authentisiert wurden.

Warum sie veröffentlicht wurden, bleibt offen.

Ein DNS-Provider kann Schreibrechte ohne Registrar-Kontrolle besitzen. Ein kompromittierter Zugang kann Daten einspielen, die der Zonensigner korrekt signiert. Frühere Automatisierung kann weiterlaufen. Der DNS-Ursprung und die gesellschaftsrechtliche Vertretungsmacht sind verschiedene Tatsachen.

RFC 9083 definiert RDAP-JSON-Antworten für Entities, Status und Nameserver. Angaben können redigiert oder rollenbezogen sein. Sie belegen nicht allein wirtschaftliches Eigentum, interne Zustimmung, Maklervollmacht oder Streitfreiheit.

Widersprüche dürfen nicht zu einem Mittelwert verschwimmen. Validiertes DNS, ungeklärte Identität und ein gesperrtes Registrar-Konto ergeben keinen mittleren Vertrauenswert, sondern einen Stopppunkt.

Die Beweiskette beginnt nach der Entdeckung

Die Entdeckung speichert Query, RRset, TTL, DNSSEC, Answer Owner und Alias-Kette. Die Zonenprüfung identifiziert Konto, Provider, Credential, Delegation und Change-Protokoll.

Die Identitätsprüfung gleicht Registrar oder RDAP mit einer verifizierten Rechtsperson ab und bestimmt das angebotene Recht: Registrierungskontrolle, Miete, Lizenz, Subdomain oder Asset-Paket. Die Vertretungsprüfung belegt Umfang, Schwelle, Laufzeit und Widerruf des Verhandlers.

Ein versioniertes Angebot ersetzt den DNS-Richtwert und erfasst Preis, Währung, Bestandteile, Steuern, Zusicherungen und Annahme. Zahlung und Escrow liefern eigene Nachweise. Der Registrar dokumentiert Unlock, Codes, Account Push, Transferstatus und Endzustand.

Kontinuität prüft Nameserver, DNSSEC-Schlüssel und DS, E-Mail, Zertifikate, Identität, APIs und Renewal. Vertragsschluss, Registerwechsel und störungsfreier Betrieb sind eigenständige Erfolge.

Running-Code Primacy ordnet diese Handlungen: DNS-Server erzeugt Beobachtung, Validator Sicherheitszustand, Identitäts- und Vertragssysteme Befugnis, Registrar Kontrolle, Anwendungen Kontinuität. Kein Badge kann die anderen Systeme durch Erklärung ersetzen.

Minimum Initial Specification erklärt den Wert einer engen gemeinsamen Grammatik. Sie macht Entdeckung interoperabel, ohne Marktplatz, Makler, Escrow oder Rechtsordnung festzulegen. Lokale Entscheidungen bleiben exportierbar und ersetzbar.

Reality Layers trennt symbolischen TXT, operativen Zonenakt, institutionelles Recht, kommerzielle Einigung und erlebte Kontinuität. „Verifizierter Verkauf“ komprimiert die Ebenen und verschiebt Macht zur Oberfläche.

Data Sovereignty fragt nach Rekonstruktion. Wer RRset, Zonenverlauf, fcod-Mapping, Identitäten, Verhandlung, Zahlung, Transfer und Kontinuität exportieren kann, kontrolliert den Streit. Eine Ergebnis-Kachel genügt nicht.

Quellen