필사 모드: How a Domain Says It Is For Sale — When DNS Became a Channel for Claims

• The healthy-looking domain that is actually for sale
• DNS has done more than name resolution for a long time
• What the underscore name does
• The record RFC 10023 defines
• Four tags and the constraints
• Why this approach is cheap
• And why this approach cannot confer trust
• If you attach it to your own domain
• Summary and sources

The healthy-looking domain that is actually for sale

The domain you wanted is already registered. You open it and the site comes up fine. This is usually where people give up. Yet a good number of those domains are in fact for sale.

The problem is that a machine has no way to find that out. A human could hunt down the contact address printed on the site and send an email, but a domain search tool or a registrar cannot do that for millions of domains. Registration data does not record an intent to sell either. "Registered" and "willing to sell" are two different layers of information, and there was no place to put the second one.

DNS has done more than name resolution for a long time

An answer to this problem recently arrived as an RFC, and the place the answer was put is more interesting than the answer itself. It is DNS.

We are taught that DNS is the system that turns names into addresses. Yet in real operations a good share of what we put into DNS is not an address. We write down which servers may send mail for this domain name, we publish the public key used to verify signatures, we state which authorities may issue certificates, and we briefly post proof that we control this domain in order to obtain one.

What these have in common is that they are all claims about this domain. And that the claims are posted in a place only the domain owner can write to. What DNS really provides is less name resolution than a worldwide public noticeboard that only the domain owner can write on and anyone can read.

What the underscore name does

The reason this noticeboard runs without collisions is the underscore.

A TXT record can hold anything at all, so when several kinds of TXT pile up on one domain, the reader has to open each one to pick out its own. RFC 8552, from 2019, tidied this up. That document establishes the rule that each use gets a child node beginning with an underscore, and only records beneath that node are interpreted for that use. It also created an IANA registry of underscored node names so that they are managed without overlapping.

The reason an underscore was chosen is the key part. Hostname rules do not permit underscores. So a name beginning with an underscore can never collide with any real host. Already widespread names such as _dmarc, _domainkey, and _acme-challenge came under this rule.

The record RFC 10023 defines

The new addition is RFC 10023. It is an informational document written by Marco Davids of SIDN Labs, published in July 2026. The name is _for-sale.

It works like this. If you are willing to sell example.com, you put a single TXT record at _for-sale.example.com. The original domain keeps working exactly as before. The site still comes up and mail still flows. The signal is simply attached alongside.

The content of the record is a single 255-octet character-string, and it must begin with a version tag. After that, at most one tag-value pair may be appended.

_for-sale IN TXT "v=FORSALE1;"
_for-sale IN TXT "v=FORSALE1;ftxt=Call for info."
_for-sale IN TXT "v=FORSALE1;furi=https://example.com/foo%20bar"
_for-sale IN TXT "v=FORSALE1;fval=EUR999"
_for-sale IN TXT "v=FORSALE1;fval=BTC0.000010"

As in the first line, a record with only the version and no tag is valid too. It announces the willingness to sell and says nothing more.

Four tags and the constraints

Four tags are defined.

The constraints are written plainly in the specification too. A record cannot carry more than one tag-value pair. Wildcard forms do not conform to the specification. A cache lifetime of 3600 seconds or less is recommended. And writing content to the effect that the domain is not for sale is considered an invalid use.

It is also worth noting that the price is written with a currency code rather than a currency symbol. Symbols overlap between countries and cause character-set problems; codes do not. It looks like a small decision, but on the automated-processing side it is a large difference.

Why this approach is cheap

What makes this design attractive is that it touches nothing.

No new record type was created. Had one been created, resolvers, authoritative servers, and management tooling would all have had to catch up. Instead it simply uses TXT, which already works everywhere. The protocol is not changed either. And the operation of the original domain is unaffected. It attaches quietly beside a live site, and if you stop wanting to sell, you delete it and that is that.

This is also why the underscore channel keeps getting used. The cheapest way to ship a new feature is to lay it on top of what everyone has already shipped. Mail authentication and certificate issuance validation spread along the same path.

And why this approach cannot confer trust

Cheap comes for a reason. Everything carried on this channel is an unverified self-assertion. It guarantees nothing beyond control of the domain.

RFC 10023 is remarkably candid about this. You can see it just from the risks named in the security section. Rendering a value straight to the screen can become script injection or query injection; homograph characters or bidirectional text can be used to deceive a human reading the value; the destination furi points to may be a malicious site; and an absurdly low price can be written in to lure buyers. So the document recommends that processors must sanitize values and check the reputation of the URI, and that they display alongside the record guidance to the effect that the price is indicative and should be confirmed with the seller.

There is also a clearer prohibition. Even when the content of furi is encountered, the user must not be redirected automatically without explicit confirmation. The moment you simply send users to an address written in a DNS record, whoever briefly gains control of the domain gets to choose where that link lands.

The document also states the privacy risk directly. Publicizing an intent to sell is itself a disclosure of information, and any contact address written down will be harvested and become a spam target.

If you attach it to your own domain

Summarized, the checklist looks like this.

1. Attach it only when you really intend to sell. The specification says so.
2. Set a short cache lifetime. 3600 seconds or less is recommended. You need it to avoid the situation where you change your mind and stay advertised as for sale all day.
3. Create a new contact channel. Do not write down an existing work address. Addresses written into public records get harvested.
4. Decide carefully whether to publish a price. An informational RFC fixes the format and does not settle your negotiating strategy for you. The number you write down becomes a ceiling.
5. If you build the reading side, forbid automatic trust. Do not render values as-is, do not add automatic redirection, and show on screen that this information is only the assertion of a seller.
6. Delete it when you no longer intend to sell. That deleting the record is all it takes to make the signal disappear is the greatest advantage of this approach.

Summary and sources

Read this RFC only as a document about domain trading and it looks small. The more valuable part is the pattern. Laying a single underscored name on top of already deployed infrastructure to carry new meaning: one document shows both how cheap that is and, as the price of it, how little trust it comes with. When you feel the same temptation in an internal system, please look at both faces of it together.

• RFC 10023 — The _for-sale Underscored and Globally Scoped DNS Node Name — Marco Davids, SIDN Labs, informational, July 2026. The record syntax, the four tags and their length limits, the examples, the cache lifetime recommendation, the prohibition on automatic redirection, and the security and privacy considerations were all confirmed in this document.
• RFC 8552 — Scoped Interpretation of DNS Resource Records through Underscored Naming of Attribute Leaves — March 2019, BCP 222. The registry of underscored names and the reason an underscore is used were confirmed here.
• The checklist at the end of the post is a working-practice rendering of the rules and recommendations in the two documents above, and is not itself a list carried in the specification.