Summary
- RFC 10023 lets a holder publish a TXT record at
_for-sale.<domain>while the domain remains active. A conforming record begins with the exactv=FORSALE1;string and may add onefcod,ftxt,furiorfvalvalue. - The record is a discovery signal. An indicative price is not binding, a URI is not safe merely because it parses, and even DNSSEC validates DNS origin and integrity rather than the publisher’s legal capacity to sell.
- A defensible acquisition keeps discovery, zone control, registrant identity, representative authority, terms, settlement, registrar transfer and service continuity as separate evidence states. The DNS can invite a conversation; it cannot close the deal.
A price appears beside a running system
A buyer’s monitoring service finds a new record beneath a domain that still handles a company’s mail, customer logins and production traffic:
_for-sale.example. IN TXT "v=FORSALE1;fval=USD75000"
The response validates under DNSSEC. A second record provides an HTTPS address. The marketplace turns the evidence into a green badge: “verified for sale.” The price enters an acquisition queue, and an automated workflow prepares to contact the seller.
Almost everything in that sequence can be technically correct while the commercial conclusion remains unproved.
The records may be authentic DNS data and still have been published by an administrator who controls the zone but cannot sell the registrant’s rights. The price may be yesterday’s indication, not today’s offer. The URI may lead to a broker whose mandate has expired. The domain may be available only for lease, or only without the website, trademark or customer data the buyer assumed were included. The registrar account may be locked, disputed or controlled by another party. A completed account push may still break DNSSEC, mail or identity services.
The error is not believing the DNS response. The error is asking the response to prove a transaction.
RFC 10023, published in July 2026 as an Informational RFC, defines a deliberately modest operational convention. A domain holder can place a reserved _for-sale leaf in the zone to say that the parent name is available for purchase. “For sale” is broad enough to include a lease or an offer of contractual use rights. The indicator can coexist with ordinary operations and be switched on or off without a protocol change.
That is valuable. Registration answers whether a name is already registered. It does not answer whether the registered name is obtainable. RFC 10023 narrows that discovery gap without pretending to govern negotiation.
One exact prefix carries the signal
A conforming record begins with the case-sensitive string v=FORSALE1;, with no space. It may stop there. It may instead add one and only one tag-value pair. The four initial tags are also case-sensitive:
fcod=holds an opaque code interpreted by cooperating parties;ftxt=holds concise text for people;furi=holds exactly one URI or IRI for information or contact;fval=holds uppercase currency letters followed by a numeric amount.
Several TXT records may form the RRset. The complete tag-value pairs must be unique, but the same tag can recur with different values. A holder might publish two broker codes, a contact URI, a textual qualification and an asking price as separate records. A processor may select one or more of them.
That last permission is easy to overlook. The RRset is the shared evidence; the screen is a local interpretation. One marketplace may recognize its own fcod and ignore the rest. A human-facing tool may prefer ftxt. A price index may extract only fval. Each can conform while presenting a different account. A defensible system therefore retains the complete RRset and the selection rule rather than treating the displayed card as the source.
Validity does not depend on useful contact content. If the exact version tag is present but the content is absent or invalid, processors should normally assume the parent is for sale unless local policy says otherwise. They can then seek contact through conventional registration-data mechanisms. But text without a valid version is not an indicator. If no TXT record at the node begins correctly, the processor must ignore the node under this convention.
The version prefix is thus stronger than the optional hint and weaker than the transaction. It says, in effect, “treat this as an availability signal.” It does not say, “the following actor and terms have been verified.”
Four hints, four different limits
fcod is the most revealing design choice. Its meaning is established by agreement among cooperating processors. A registry or registrar ecosystem can recognize a code prefix and map it to a sales page. The mapping may change centrally while the DNS value remains unchanged. This can prevent arbitrary values from sending users to unintended destinations and can simplify operations.
It also moves decisive context outside DNS. An outsider cannot infer the code’s meaning. An auditor looking only at the RRset cannot know which destination a processor supplied at a particular time. The operator of the mapping becomes a practical interpreter of the public signal. If that service controls the only mapping history, portability ends at the syntax.
ftxt is deliberately human-readable and deliberately loose. It can explain eligibility, preferred contact or another qualification. It can also contain control characters, deceptive Unicode, markup or a substring that merely looks like a second tag. The grammar permits an fcod value containing ;ftxt= even though no ftxt field exists. A parser that splits on familiar punctuation can invent claims the publisher never made.
furi separates a machine-parsable contact path from free text. HTTP, HTTPS, mailto and tel are recommended schemes, with HTTPS preferable where appropriate. Syntax is not reputation. The RFC warns of phishing, malware, scripted attacks and improper content, and it requires explicit confirmation before a processor redirects a user. DNS is not a safe-browsing verdict.
fval makes the price easier to parse. EUR999, USD750 or a recognized cryptocurrency abbreviation can fit its grammar. The standard is unusually direct about the boundary: the value is indicative and non-binding. Current, reliable information requires direct engagement. Interfaces should warn users, and automated systems should not make purchase commitments from the advertised number alone.
The four tags therefore belong to a discovery vocabulary, not a contract schema. They can tell a buyer where to begin. They do not define the asset bundle, seller, representations, taxes, escrow terms, acceptance method or transfer conditions.
The wire format refuses to become a prospectus
Each record’s TXT RDATA must be one character-string, no longer than 255 octets. Multiple commercial hints go into multiple records, not a long concatenated document. RFC 1035 supplies the TXT and TTL foundations, while RFC 10023 adds the application grammar.
Implementers must parse raw RDATA, not confuse it with a command-line tool’s escaped presentation. Non-ASCII material should follow the RFC’s UTF-8 and Network Unicode guidance. Unexpected control characters can be sanitized for display. These are not cosmetic details. A price or URI observed after the wrong decoding step is not the value that the authoritative server necessarily published.
The restricted format expresses sound institutional modesty. DNS can carry a compact signal efficiently. It is a poor place for a complete legal and operational dossier. Attempts to squeeze more authority into free text, encoded codes or private display rules do not expand the standard. They expand the unreviewed layer around it.
The leaf must point to the right parent
The placement determines which name is being described. _for-sale.example concerns example. xyz._for-sale.example is non-conformant because _for-sale is not the leaf. _for-sale.*.example does not create one wildcard offer for every name beneath a zone. RFC 4592 explains wildcard behavior; RFC 10023 explicitly rules that construction out.
Wildcards can still cause trouble nearby. A wildcard-generated answer, perhaps combined with CNAME or DNAME processing, may look like a valid listing or may refer to a third-party name. A serious collector preserves the query name, answer owner, alias chain, authoritative evidence and synthesis context instead of recording only the final TXT string.
The convention can be used at multiple DNS levels. Below a subdomain, however, there may be no public registry capable of recording the rights in the label. Parties then need a separate agreement to define what can be transferred. Records under .arpa must be ignored because they could be mistaken for offers involving address space or E.164 identifiers. Application to special-use names is outside the RFC’s scope.
The IANA DNS Parameters registry now lists the TXT / _for-sale / RFC 10023 combination. RFC 8552 explains why globally scoped underscored names are registered: the unique combination prevents unrelated applications from colliding. Registration allocates meaning to a name and RR type. It does not certify any record’s truth or any implementation’s adoption.
The official RFC 10023 errata registry contains one Technical item, erratum 9090, with status Reported. It questions Table 1’s description of the first placement as “Root zone” and proposes TLD or zone-apex wording. Reported is not Verified. It is an implementation-review note, not permission to rewrite the standard as if the correction were settled.
A one-hour TTL is not a one-hour offer
A holder should remove the indicator when the domain is no longer available. RFC 10023 recommends a TTL of 3,600 seconds or less because long caching can leave a withdrawn listing or old price visible to buyers.
Short caching limits stale DNS; it does not synchronize the commercial world. A crawler may keep the listing indefinitely. A screenshot may circulate without provenance. A broker can cache a mapping outside DNS. The counterparty can revoke a mandate while the record remains. A buyer can see a fresh RRset and still contact the seller after circumstances have changed.
Every serious observation therefore needs a timestamp, TTL, resolver, complete response and validation state. Recheck through an authoritative path at decision points. Do not translate TTL into offer expiry, and do not translate absence into unwillingness. A domain in redemption, pending delete or a DNSSEC bogus state may fail to resolve even if someone would otherwise sell it.
DNSSEC authenticates data, not a board resolution
RFC 4033 describes DNSSEC’s core contribution: origin authentication and integrity protection for DNS data under a chain of trust. It does not provide confidentiality. A successfully validated _for-sale RRset gives the buyer stronger evidence that the data is the RRset authenticated under the relevant DNS keys and was not silently altered on the path.
It does not show why the data entered the zone.
A DNS hosting administrator may have write access but no commercial mandate. A compromised API token may produce properly signed data because the signer faithfully signs the compromised zone contents. A former employee’s automation may still run. A reseller may control DNS while the registrant controls transfer. DNSSEC can prove the origin of the statement within DNS without proving the statement maker’s authority outside DNS.
RFC 9083 describes RDAP response objects that can help a processor inspect registration data, entities, statuses and nameservers. That is another evidence surface, not a magic ownership certificate. Data may be redacted or role-mediated. A listed entity does not automatically show beneficial ownership, internal approval, an agent’s power or the absence of a dispute.
Conflicts must remain conflicts. A DNSSEC-valid indication, a mismatched broker identity and a locked registrar account should not be blended into a medium confidence score. They describe different layers, and one of them can veto action.
The transaction needs an evidence chain of its own
Discovery begins with the raw query: name, type, time, RRset, TTL, DNSSEC state, answer owner, aliases and processor selection. Zone-control evidence then identifies who could publish the record and under which account, credential, ticket or delegation.
Identity work reconciles registrar or RDAP data with a verified legal counterparty. The buyer must define the right being offered. Is it registrant control, a lease, a licence to use the name, a subdomain, or a larger asset package? “For sale” intentionally does not decide.
Representation evidence establishes whether the employee, broker or service may bind the holder, for what amount, until when and under what approvals. Negotiation then produces formal terms that supersede the DNS hint. The accepted price, currency, included assets, warranties, liabilities, transfer method and dispute forum belong to a versioned agreement.
Settlement proves funds and release conditions. Registrar and registry evidence proves the control transition. Continuity evidence proves something else again: that nameservers, DNSSEC, mail, certificates, identity dependencies and production services survived. Finally, post-transfer checks confirm that _for-sale was removed or deliberately replaced.
This is Running-Code Primacy applied to the transaction. The authoritative DNS server creates an observable signal. The validator creates a security result. Identity and contract systems establish people and powers. Registrar systems change control. Applications determine whether the acquired name still works. No document, registry or badge can execute all those transitions by declaration.
Minimum Initial Specification explains why the common layer should stay narrow. A shared discovery grammar can be precise without imposing one broker, marketplace, escrow service or legal model. Future interpretation can remain local and voluntary, provided local systems expose their rules and do not inflate their claims.
Reality Layers supplies the diagnostic. The TXT string is symbolic. Zone publication and resolution are operational. Registrant rights and agency are institutional. Price acceptance and settlement are commercial. Service survival is experiential. A “verified sale” badge that fuses them gives its operator authority through compression.
Data Sovereignty identifies the practical owner of the dispute: the party that can reconstruct the raw RRset, zone history, code mapping, identities, negotiation, payment, registry state and continuity. Exporting only the marketplace’s conclusion leaves the customer with data but without control over its meaning.
Sources
- RFC 10023 — The
_for-saleUnderscored and Globally Scoped DNS Node Name - RFC 8552 — Scoped Interpretation through Underscored Naming
- RFC 1035 — Domain Names: Implementation and Specification
- RFC 4033 — DNS Security Introduction and Requirements
- RFC 4592 — The Role of Wildcards in DNS
- RFC 9083 — JSON Responses for RDAP
- IANA — DNS Parameters
- RFC Editor — RFC 10023 errata
- Heng Lu — Running-Code Primacy
- Heng Lu — Minimum Initial Specification
- Heng Lu — Reality Layers
- Heng Lu — Data Sovereignty
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
