Glonce

RFC 10023 defines a _for-sale DNS record for domain sales

infrastructureThe Glonce editorsHacker News🔥57Glonce rating57Impact35Novelty70Relevance45Surprise30Players20Credibility82
RFC 10023 defines a _for-sale DNS record for domain sales

specification.website has published an explainer for _for-sale, a reserved DNS leaf node name defined by RFC 10023, an Informational RFC dated July 2026 and registered with IANA. Publishing a TXT record at _for-sale.example.com signals that example.com, although registered and resolving normally, is available for purchase. A minimal record reads _for-sale IN TXT "v=FORSALE1;furi=https://example.com/for-sale", where the version tag v=FORSALE1 is mandatory and case sensitive, followed by at most one optional tag=value pair per record: ftxt for free text, furi for a negotiation link using https, mailto or tel, or fval for an asking price given as an uppercase currency code plus an amount, for example fval=USD12500. The convention is explicitly not domain parking: parking replaces the site with a sales page and costs the owner every visitor the domain still has, while _for-sale sits beside a live site in DNS and is invisible to a browser, so the homepage keeps serving and the mail keeps flowing while the record can be added or removed at will. It is also not the same thing as WHOIS or RDAP registration data, which answer only whether a name is registered, not whether it is for sale; that gap is the reason the convention exists, and brokers and automated availability services, not people, are the intended audience. The specification sets several rules: only one tag-value pair per record, so publishing both a price and a contact URI means publishing two separate records in the same RRset for a processor to pick between, unlike SPF the pairs do not concatenate; each character-string is capped at 255 octets; the TTL should be kept at 3600 seconds or less so a stale record does not advertise a price already withdrawn or a domain already sold; the record must sit at a leaf, so _for-sale.example.com is valid but xyz._for-sale.example.com is not, and records under .arpa must be ignored; and there is no "not for sale" value, so removing the record is the only way to retract the signal. The page recommends signing the zone with DNSSEC, since an unsigned record asserting a price and a contact URI is easy to forge. It also warns that publishing the record for a domain that is not actually available is an abuse the RFC calls out by name, and that ftxt and furi values are attacker controlled: the RFC's own example content for the field is a script tag, so a reader must sanitise before display and never auto-navigate to a furi target without an explicit confirmation step. specification.website notes it does not itself publish a _for-sale record, since the site is not for sale. Verification is done with dig: a lookup should return a string starting with v=FORSALE1, a TTL of 3600 seconds or less, and, on a signed zone, a validating RRSIG; during a redemption or pendingDelete period, or when DNSSEC validation is bogus, the record simply will not resolve and the signal disappears.

Key facts

  • RFC 10023 is an Informational RFC dated July 2026, registered with IANA, that defines the _for-sale DNS leaf node name.
  • A record looks like _for-sale IN TXT "v=FORSALE1;fval=USD12500", with a mandatory version tag and at most one optional tag=value pair per record (ftxt for text, furi for a negotiation link, fval for a currency-coded price).
  • Unlike domain parking, the record does not replace the live site or divert visitors; it is invisible to browsers and can be added or removed at will.
  • Recommended TTL is 3600 seconds or less, each character-string is capped at 255 octets, and there is no 'not for sale' value, only removal of the record.
  • The RFC flags ftxt and furi as attacker-controlled input requiring sanitisation, using a script tag as its own example of the risk, and calls publishing the record for a domain not actually for sale an abuse.

Why it matters

There has never been a channel for a domain owner to signal willingness to sell short of a cold email to a WHOIS contact that privacy redaction has often removed, so welcome enquiries never arrive and the enquiries that do arrive are indistinguishable from spam. Putting the signal in DNS rather than on the rendered page makes it something brokers and availability services, which already resolve the name, can check with one extra lookup at no risk to the live site.

Who it affects

The convention targets domain brokers and automated availability services rather than end users browsing the web; a domain owner willing to sell publishes the record, and a broker or service checking the name reads it. specification.website itself is an example of a site that deliberately does not publish the record, since it states plainly it is not for sale.

How to use it

Publish a single TXT record at the _for-sale leaf of the zone being sold, starting with the mandatory, case-sensitive v=FORSALE1 tag, and only while the offer is genuine. Add at most one further tag=value pair per record: ftxt for free text, furi for a negotiation URI (https, mailto or tel), or fval for an asking price as an uppercase currency code followed by the amount. To publish both a price and a contact URI, publish two separate records in the same RRset, since the format does not concatenate pairs the way SPF does. Keep the TTL at 3600 seconds or less, keep each record to one leaf-level name, and remove the record entirely once the domain is no longer for sale, since there is no dedicated value for 'not for sale'.

How solid is it

The convention rests on a single Informational RFC, 10023, published in July 2026 and registered with IANA; specification.website gives no author for the RFC or for the explainer page, names no registrar, DNS provider or broker as currently reading the record, and cites no adoption or usage data beyond stating that specification.website itself does not carry one. Verification is mechanical: a dig lookup should return a string starting with v=FORSALE1 with a TTL of 3600 seconds or less, and a signed zone should return a validating RRSIG on a DNSSEC query.

Risks and caveats

An unsigned record asserting a domain's availability, price and contact URI is easy to forge, which is why the page recommends signing the zone with DNSSEC. The RFC treats an advertised price as indicative only, never a binding purchase commitment, and expects processors to show a disclaimer. It explicitly calls publishing the record for a domain that is not actually available an abuse. Because ftxt and furi are attacker-controlled input, the RFC's own example content for the field is a script tag, so any reader displaying the record must sanitise it and must never auto-navigate to a furi target without an explicit confirmation step. The record can also silently vanish during a redemption or pendingDelete period, or when DNSSEC validation is bogus.

“The convention has no "not for sale" value; absence is the only way to say no.”

— specification.website, on RFC 10023