DNS SecurityDNS recordsRFC 10023_for-sale

llms.txt Validator

Look up 20 supported record types with raw and readable answers, alias chains, TTLs and resolver provenance, and check or generate RFC 10023 _for-sale records.

Use it when you need the exact DNS answer, its status and its source before changing records or blaming a resolver.

Inputs

DNS Lookup is one of 27 directly executable, read-only WebMCP diagnostics registered on the root page. It returns a structured result using the same canonical description in document.modelContext, tool pages, tools.json, well-known manifests, OpenAPI, and JSON-LD.

Example

_for-sale.example.nl TXT -> v=FORSALE1;fval=EUR... as one exact character-string, with tag, value, TTL and RFC 10023 findings.

Reading a DNS answer the way the resolver sent it

Most DNS confusion starts with a summarized answer: a tool shows a value, but not whether the name exists, whether the value arrived through an alias, how long a cache may keep it, or which resolver said so. This lookup decodes the raw DNS message — RFC 1035 wire format delivered over DNS-over-HTTPS — and shows the response code, header flags, alias chain, TTLs and every record in readable and zone-file form, so NODATA, NXDOMAIN, SERVFAIL and a timeout never look alike.

The same page carries the RFC 10023 _for-sale convention: a domain holder can publish TXT records at _for-sale.<domain> to signal that a registered name is available for purchase. The dedicated section queries exactly that owner name, validates every record against the RFC — version tag, single character-string, content tags, value limits, URI and price syntax — and drafts compliant records when you want to publish one.

From one record to the whole picture

Start with the record type you are debugging, or run the overview to see A, AAAA, CNAME, MX, NS, TXT, SOA, CAA and HTTPS side by side. Read the state first: an answer, NODATA (the name exists without that type), NXDOMAIN (the name does not exist), or a resolution failure. Then follow the alias chain — records belong to the final owner name, not to the name you typed — and read the TTLs, which show how long caches may hold the current data.

For TXT records, look at the character-string table: long values are split into strings of up to 255 octets, and those boundaries matter for SPF, DKIM and RFC 10023 alike. For a sale check, open the _for-sale section; pasted records are validated locally, and generated records come out escaped for a zone file, with the TTL at or below the recommended hour.

What a recursive answer can and cannot prove

Answers come from one recursive resolver — Cloudflare DNS-over-HTTPS from your browser, or the same resolver through the same-origin helper when the browser path fails — so they show that resolver's cached view at lookup time, with TTLs counting down. The AD flag means the resolver reports DNSSEC validation; this tool does not verify signatures itself and does not query authoritative servers, which is what the delegation check is for. furi links from _for-sale records are shown as text and never fetched, and advertised prices are indicative only.

Frequently asked questions

Why does my record show NODATA instead of NXDOMAIN?

NODATA means the name exists — it owns other records or has names below it — but not the type you asked for. NXDOMAIN means the name does not exist at all. Both are valid answers; a SERVFAIL or a timeout is not an answer and proves nothing about the record.

Why are the TTLs lower than in my zone file?

A recursive resolver hands out its cached copy and counts the TTL down from the moment it fetched the record. The configured TTL only appears right after a cache miss; the delegation check shows authoritative answers directly.

Does the AD flag mean the answer is secure?

It means the resolver says it validated the DNSSEC chain. You are trusting that resolver and the encrypted DNS-over-HTTPS connection to it; this tool does not repeat the cryptographic validation.

Why are some TXT values shown as several strings?

A single TXT character-string holds at most 255 octets, so longer values are split. The split is part of the record: some protocols concatenate the strings, while RFC 10023 requires exactly one string per _for-sale record.

What makes a _for-sale record valid?

It must be one character-string that starts with the case-sensitive version tag v=FORSALE1;, optionally followed by exactly one tag-value pair such as fval=EUR500, furi=https://..., fcod= or ftxt=. Records without the version tag are never treated as an indicator.

Is a published price binding?

No. RFC 10023 calls fval indicative; the tool shows it with that disclaimer and never opens the seller's link for you. Confirm any offer directly with the seller.