Zusammenfassung

  • Ein gültiges _for-sale-RRset belegt eine von der Zone veröffentlichte Absicht im Format von RFC 10023, nicht Identität, Vollmacht, bindenden Preis oder Transferfähigkeit des Anbieters.
  • DNS-Beobachtung, Aktualität, DNSSEC-Validierung, Gegenpartei, Vertretungsmacht, Einigung und Transfer brauchen getrennte Zustände und einen gemeinsamen, prüfbaren Belegpfad.

Der Mechanismus ist bewusst schmal. Ein TXT-Record unter _for-sale beginnt mit der exakten, groß- und kleinschreibungssensitiven Zeichenfolge v=FORSALE1;. Danach kann genau ein optionales Tag folgen: Code, Text, URI oder Wert. Mehrere eindeutige Records dürfen im RRset stehen. Interessenten können Verfügbarkeit damit entdecken, ohne von der Startseite der Domain oder einem bestimmten Marktplatz abhängig zu sein.

Gerade diese Einfachheit verführt zur Bedeutungsverdichtung. „Im DNS beobachtet“ ist eine technische Aussage. „Der Eigentümer verkauft“ ordnet einer Person Identität und Befugnis zu. „Zu diesem Preis kaufbar“ setzt aktuelle Bedingungen und Erfüllung voraus. Fasst eine Oberfläche alle drei Aussagen in einem Gütesiegel zusammen, erzeugt sie Autorität, die im Protokoll nicht enthalten ist.

Die Versionskennung prüft Form, nicht Vollmacht

Schon eine gültige Versionskennung ohne weiteres Tag erlaubt dem Verarbeiter, nach seiner lokalen Policy von einem Angebot auszugehen. Fehlt ein gültiges, erkanntes Tag, wird der Eintrag ignoriert. Jeder Record trägt höchstens ein optionales Tag. Das sind Auslegungsregeln, kein Eigentumsregister.

„For sale“ ist zudem weit gefasst und kann Verkauf, Vermietung oder Nutzungsrecht meinen. Der Inhaber wird durch die Veröffentlichung nicht zum Abschluss verpflichtet; der Eintrag kann irrtümlich gesetzt oder bereits zurückgezogen worden sein. Selbst fval ist unverbindlich. „Beobachteter Richtwert“ ist daher korrekt, „garantierter Kaufpreis“ nicht.

Frische und Signatur bleiben DNS-Nachweise

Eine Erfassung sollte Abfragenamen, rohes RRset, Zeitpunkt, Resolver, verbleibende TTL, Delegationspfad und Validierungsergebnis fixieren. RFC 10023 empfiehlt höchstens 3.600 Sekunden TTL. Das verkürzt die Lebensdauer veralteter Angebote, synchronisiert aber weder alle Caches noch entfernt es automatisch eine Anzeige im Marktverzeichnis.

DNSSEC stärkt Herkunft und Integrität. Erfolgreiche Validierung liefert kryptografische Gründe, die Antwort der erwarteten Signaturkette zuzuordnen. Sie macht einen Zonenschlüssel nicht zur Verkaufsvollmacht. Zonenbetreiber, registrierter Inhaber, wirtschaftlich Berechtigter, Makler und transferberechtigte Person können auseinanderfallen. Technische Publikationsbefugnis und rechtliche Verfügungsbefugnis sind deshalb eigenständige Kontrollflächen.

Ein bestätigter Link ist keine bestätigte Gegenpartei

furi kann zu einer Verkaufsseite führen. Die RFC warnt vor automatischer Weiterleitung ohne ausdrückliche Nutzerbestätigung sowie vor schädlichen URIs und verlangt Bereinigung. Die Bestätigung schützt das Öffnen des Links; sie authentifiziert nicht dessen Betreiber.

Der Markt muss weiterhin Kontobeherrschung, Identität, Beziehung zum Inhaber, Umfang und Laufzeit der Vollmacht, akzeptierte Vertragsfassung und Transferweg prüfen. Für Subdomains fehlt womöglich ein öffentliches Register der Nutzungsrechte. Im Namensraum .arpa ist der Mechanismus zu ignorieren. Dieselbe Syntax trägt in unterschiedlichen institutionellen Räumen nicht dieselbe Schlussfolgerung.

Neun Zustände statt einer grünen Plakette

Ein belastbarer Ablauf trennt mindestens: Name entdeckt; RRset frisch; Syntax gültig; DNSSEC gültig, ungültig oder nicht verfügbar; Verfügbarkeitsabsicht; Gegenpartei identifiziert; Vollmacht geprüft; Bedingungen angenommen; Transfer abgeschlossen. Jeder Zustand erhält Quelle, Zeitpunkt und Entscheider.

Diese Trennung weist Fehlern die richtige Abhilfe zu. Eine abgelaufene TTL verlangt eine neue Abfrage. Eine ungültige Signatur stoppt die Herkunftsaussage. Eine zweifelhafte Vollmacht stoppt den Vertrag, selbst wenn das DNS intakt ist. Ein fehlgeschlagener Transfercode gehört in den Prozess des Registrars. Die letzten beiden Probleme löst keine erneute TXT-Abfrage.

Ein Beleg von der Anzeige bis zum Transfer

Der vorgeschlagene Beleg speichert zunächst Abfrage, Antwort, Zeit, TTL, Validierung und interpretiertes Tag. Danach hält er die vom Nutzer bestätigte URI und das erreichte Ziel fest. Es folgen Identität, Kontobeherrschung und Vollmachtsnachweis. Schließlich verbindet er Vertragsversion, Wert, Zustimmungen, Zahlung oder Treuhand und das Ergebnis beim Registrar.

Damit wird DNS nicht zum Vertrag. Sichtbar wird vielmehr, wo sein Beitrag endet. Im Streitfall lässt sich präzise fragen: War die Anzeige frisch? War der Vermittler bevollmächtigt? War der Wert nur indikativ? Hatte sich die URI geändert? Welche Bedingungen wurden angenommen? Wer vollzog oder blockierte den Transfer?

Entfernen ist ebenfalls eine Kontrollhandlung

Ein Index muss nach Maßgabe der TTL erneut abfragen und „kürzlich gesehen“ von „derzeit aktiv“ unterscheiden. Verschwindet das RRset, muss auch die aktuelle Verkaufsbehauptung enden. Historische Nachweise dürfen datiert für Prüfungen fortbestehen, aber nicht als gegenwärtiges Angebot. Änderungen an furi oder fval sind neue Zustände; ein stilles Überschreiben vernichtet die Ereignisfolge.

Das Prinzip reicht über Domainhandel hinaus. Sobald ein Infrastruktursignal zur Marktbehauptung wird, verteilt die Oberfläche Macht. Nur wenn erkennbar bleibt, was Zone, Validator, Plattform, Vertreter und Registrar jeweils belegt haben, ist diese Verteilung prüfbar.

Quellen