Summary

  • RFC 10023 defines an Informational DNS convention at _for-sale.<name>. A valid v=FORSALE1; record signals availability for sale, lease or another right of use, but does not oblige the holder to transact.
  • DNS and DNSSEC can establish what a zone published and whether the answer validates. They do not prove the contact's authority, a binding price, clean title or a completed transfer. Automation needs an explicit handoff from listing evidence to counterparty and registrar evidence.

The record was fresh, signed and syntactically perfect. It named a price and pointed to a sales page. A procurement system labelled the domain “verified for sale”. The only unresolved question was the one that mattered: verified by whom, for what claim?

RFC 10023 defines _for-sale as an underscored DNS leaf that indicates the parent domain is available for purchase. It is an operational convention, published as Informational rather than Standards Track. It can coexist with a working website and mail service. “For sale” is intentionally broad enough to include a lease or another offered contractual right to use the name.

That flexibility makes the signal useful. It also makes the boundary essential.

What the record can say

A conforming TXT record begins exactly with the case-sensitive version tag v=FORSALE1;. It may stop there or add one tag-value pair. fcod carries a code meaningful to cooperating processors; ftxt carries human-readable context; furi carries one URI or IRI; and fval carries an indicative amount with a currency label. Several unique records may appear in one RRset.

The version tag is the decisive syntax. If it is valid but the optional content is absent or malformed, processors should still assume the domain is for sale unless local policy says otherwise. If no TXT record has a valid version tag, the node is ignored. The convention therefore separates the availability signal from the reliability of the contact or price data beside it.

It also refuses to turn publication into an obligation. The RFC says the node may have been published in error or withdrawn later and does not require the holder to sell. fval is expressly non-binding. Current information comes from engagement through furi or another channel, not from treating a cached number as an executable offer.

The signal can live at several DNS levels. Beneath a subdomain, there may be no public registry that records rights in that label. The RFC suggests that parties may need their own agreement. Under .arpa, processors must ignore it so a label cannot be mistaken for an offer to sell IP address space, E.164 numbers or similar infrastructure resources.

Fresh DNS is still only DNS evidence

The recommended TTL is 3,600 seconds or less because long caching can preserve an outdated availability statement or price. Equal TTLs inside one RRset help bound cache behaviour; they do not prove that the offer remains live until expiry. A seller can withdraw after publication, and a resolver can continue serving a previously valid answer.

DNSSEC improves a different part of the chain. Under RFC 4033, it supplies origin authentication and data integrity for DNS data. A validating answer can support the claim that the signed zone published these bytes. It does not answer whether the person behind a URI is authorised to sell, whether another party holds contractual rights, whether a lease is being described as a sale, or whether a transfer can pass registrar checks.

That distinction is not a weakness in DNSSEC. It is a scope boundary. Cryptographic provenance for a statement is not the same as legal or operational authority to complete the transaction described by it.

The absence of a valid answer is equally bounded. The mechanism depends on resolvable DNS. A name in redemption, pendingDelete, or a bogus DNSSEC state may fail to expose the record. “No usable listing signal now” does not prove the name is unavailable through every other channel.

A pointer is not a trusted counterparty

furi makes discovery convenient and creates a transition to a more dangerous surface. The RFC prohibits automatic redirection without explicit user confirmation. A record can point to malware, phishing or improper content. Unicode manipulation, homographs, bidirectional text, XSS and injection become concerns when processors publish unsanitised values.

The control should survive every rendering step. Parse raw TXT RDATA rather than a tool's escaped presentation format. Enforce the version and tag grammar. Normalise and display the destination without silently following it. Prefer secure schemes, sanitise output, and apply URI reputation or an allowlist where the service claims curation.

None of those controls authenticates the seller. A clean HTTPS page proves a protected connection to the page's web origin. It does not prove that the page operator controls the registrant account or has a valid agency mandate. An fcod interpreted by a registry or marketplace may provide a stronger controlled handoff, but its semantics depend on the parties' agreement. The record format does not supply that agreement.

Separate the transaction states

An automated service should not collapse the following states:

  1. a _for-sale name was queried;
  2. a syntactically valid version tag was observed;
  3. the answer passed or failed DNSSEC validation;
  4. optional content, price or pointer was parsed safely;
  5. the purported seller or agent was contacted;
  6. authority to negotiate and bind the transaction was verified;
  7. current terms were confirmed;
  8. registrar, escrow and payment controls accepted the transfer;
  9. control of the domain actually changed.

RFC 10023 directly standardises the second state and supporting content format. DNS operations support the first through fourth. The later states belong to commercial, contractual and registrar processes. Reporting “verified listing” without naming the verified state invites every downstream user to assume a stronger one.

Build a listing-to-transfer receipt

A listing-to-transfer receipt can make the handoff explicit. Its DNS section records query time, owner name, raw RDATA hash, version tag, tag type, TTL remaining, resolver, DNSSEC status and the exact parent domain to which the leaf applies. It records whether aliases or wildcard behaviour affected the answer.

Its engagement section records the displayed destination, confirmation the user chose to follow it, the contact channel actually used, the identity claimed by the counterparty and whether that party acts as holder, broker, registrar or another agent. Authority evidence should name its scope and expiry. A mandate to discuss price is not necessarily a mandate to transfer the name.

Its terms section marks fval as indicative, records the current quoted amount and currency, distinguishes sale from lease or licence, and identifies conditions, taxes and expiry. Its completion section records registrar status, transfer lock and eligibility checks, escrow state, payment conditions, authorisation codes and the observed change of control. Sensitive material belongs in protected systems; the public receipt can retain hashes and status references.

This is an editorial governance proposal, not an extra RFC requirement. Its purpose is to stop one convenient DNS fact from impersonating an entire transaction.

Removal is a control action

When the name is no longer available, the indicator is to be removed. That creates a small but real operational obligation. Someone must own publication, TTL choice, price/contact updates and withdrawal. A marketplace cache should not outlive the evidence it cites without showing the observation time.

Useful canaries include a clean record, a valid version with invalid optional content, several records in one RRset, a stale cached price, a malicious URI, a Unicode edge case, a wildcard interaction, a DNSSEC bogus answer and a removed record still present in cache. The expected result must be stated before automation is enabled.

The narrow conclusion is also the safest. IANA registration of _for-sale proves the convention is recorded. A fresh valid TXT answer proves that the zone published an availability indicator. DNSSEC can authenticate that publication. None of those facts alone proves who can bind a sale or that the transaction completed. The next control plane begins where the DNS record ends.

Sources