Eingaben
Beispiel
_for-sale.example.nl TXT -> v=FORSALE1;fval=EUR... als ein exakter Character-String, mit Tag, Wert, TTL und RFC-10023-Befunden.
llms.txt-Validator
Fragt 20 unterstützte Record-Typen mit rohen und lesbaren Antworten, Alias-Ketten, TTLs und Resolver-Herkunft ab und prüft oder erzeugt RFC-10023-_for-sale-Records.
Nutze es, wenn du die exakte DNS-Antwort, ihren Status und ihre Quelle brauchst, bevor du Records änderst oder einem Resolver die Schuld gibst.
Eine DNS-Antwort so lesen, wie der Resolver sie geschickt hat
Die meisten DNS-Missverständnisse beginnen mit einer zusammengefassten Antwort: Ein Tool zeigt einen Wert, aber nicht, ob der Name existiert, ob der Wert über einen Alias kam, wie lange ein Cache ihn halten darf oder welcher Resolver ihn geliefert hat. Dieser Lookup dekodiert die rohe DNS-Nachricht — RFC-1035-Wire-Format über DNS-over-HTTPS — und zeigt Response-Code, Header-Flags, Alias-Kette, TTLs und jeden Record in lesbarer und Zonenfile-Form, damit NODATA, NXDOMAIN, SERVFAIL und ein Timeout nie gleich aussehen.
Dieselbe Seite enthält die _for-sale-Konvention aus RFC 10023: Domaininhaber können TXT-Records unter _for-sale.<domain> veröffentlichen, um zu signalisieren, dass ein registrierter Name zu kaufen ist. Der eigene Abschnitt fragt genau diesen Owner-Namen ab, prüft jeden Record gegen den RFC — Versions-Tag, einzelner Character-String, Content-Tags, Wertgrenzen, URI- und Preis-Syntax — und entwirft konforme Records, wenn du einen veröffentlichen willst.
Vom einzelnen Record zum Gesamtbild
Beginne mit dem Record-Typ, den du untersuchst, oder starte die Übersicht für A, AAAA, CNAME, MX, NS, TXT, SOA, CAA und HTTPS nebeneinander. Lies zuerst den Zustand: eine Antwort, NODATA (der Name existiert ohne diesen Typ), NXDOMAIN (der Name existiert nicht) oder ein Auflösungsfehler. Folge dann der Alias-Kette — Records gehören zum letzten Owner-Namen, nicht zum eingegebenen — und lies die TTLs, die zeigen, wie lange Caches die aktuellen Daten halten dürfen.
Bei TXT-Records lohnt sich die Tabelle der Character-Strings: Lange Werte werden in Strings von höchstens 255 Oktetten geteilt, und diese Grenzen zählen für SPF, DKIM und RFC 10023 gleichermassen. Für eine Verkaufsprüfung öffne den _for-sale-Abschnitt; eingefügte Records werden lokal geprüft, und erzeugte Records kommen fertig maskiert für ein Zonenfile, mit einer TTL von höchstens der empfohlenen Stunde.
Was eine rekursive Antwort beweisen kann und was nicht
Die Antworten stammen von einem rekursiven Resolver — Cloudflare DNS-over-HTTPS aus deinem Browser oder derselbe Resolver über den Same-Origin-Helfer, wenn der Browserweg scheitert — und zeigen daher dessen Cache-Sicht zum Abfragezeitpunkt mit herunterzählenden TTLs. Das AD-Flag bedeutet, dass der Resolver eine DNSSEC-Validierung meldet; dieses Werkzeug prüft Signaturen nicht selbst und fragt keine autoritativen Server ab, dafür gibt es die Delegationsprüfung. furi-Links aus _for-sale-Records werden als Text gezeigt und nie abgerufen, und angegebene Preise sind nur unverbindlich.
Häufige Fragen
Warum zeigt mein Record NODATA statt NXDOMAIN?
NODATA heisst, der Name existiert — er besitzt andere Records oder hat Namen darunter —, aber nicht mit dem gefragten Typ. NXDOMAIN heisst, der Name existiert gar nicht. Beides sind gültige Antworten; SERVFAIL oder ein Timeout sind keine Antwort und beweisen nichts über den Record.
Warum sind die TTLs niedriger als in meinem Zonenfile?
Ein rekursiver Resolver gibt seine gecachte Kopie heraus und zählt die TTL ab dem Abrufzeitpunkt herunter. Die konfigurierte TTL erscheint nur direkt nach einem Cache-Miss; die Delegationsprüfung zeigt autoritative Antworten direkt.
Bedeutet das AD-Flag, dass die Antwort sicher ist?
Es bedeutet, dass der Resolver angibt, die DNSSEC-Kette validiert zu haben. Du vertraust damit diesem Resolver und der verschlüsselten DNS-over-HTTPS-Verbindung zu ihm; dieses Werkzeug wiederholt die kryptografische Prüfung nicht.
Warum werden manche TXT-Werte als mehrere Strings gezeigt?
Ein TXT-Character-String fasst höchstens 255 Oktette, längere Werte werden geteilt. Die Teilung gehört zum Record: Manche Protokolle fügen die Strings zusammen, RFC 10023 verlangt dagegen genau einen String pro _for-sale-Record.
Was macht einen _for-sale-Record gültig?
Er muss aus einem Character-String bestehen, der mit dem case-sensitiven Versions-Tag v=FORSALE1; beginnt, optional gefolgt von genau einem Tag-Wert-Paar wie fval=EUR500, furi=https://..., fcod= oder ftxt=. Records ohne Versions-Tag gelten nie als Indikator.
Ist ein veröffentlichter Preis verbindlich?
Nein. RFC 10023 nennt fval unverbindlich; das Werkzeug zeigt den Preis mit diesem Hinweis und öffnet den Link des Verkäufers nie für dich. Bestätige jedes Angebot direkt beim Verkäufer.