RFC 10023

The "_for-sale" Underscored and Globally Scoped DNS Node Name

📅 published July 2026, from ietf

RFC 10023: The "_for-sale" Underscored and Globally Scoped DNS Node Name 🦋

Okay bestie, the title block first 📋 This one comes from the IETF (Internet Engineering Task Force) and it's RFC 10023 💅. It was written by M. Davids from SIDN Labs, it's in the Informational category, it's dated July 2026, and its ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates, so there's no drama there 🙌.

Abstract

This doc defines an operational convention 💅 that uses the reserved underscored DNS leaf node name _for-sale to show that the parent domain name is available for purchase 🛍️.

The convention can be deployed without disrupting existing operations, and it may be applied even when the domain name is still actively in use 🌸.

Status of This Memo

Bestie, this one is not an Internet Standards Track specification 🙈. It's published just for informational purposes ✨.

Even so, it's a product of the IETF, which means it represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the IESG (Internet Engineering Steering Group). Not every document the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 for the details 🧐.

For the current status, any errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc10023 📬.

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved 🎀.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the date of publication. Please review these documents carefully, because they describe your rights and restrictions with respect to this document 📜.

Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Revised BSD License. 💜

Table of Contents

1.  Introduction
  1.1.  Terminology
2.  Conventions
  2.1.  General Record Format
  2.2.  Content Tag Type Definitions
    2.2.1.  fcod
    2.2.2.  ftxt
    2.2.3.  furi
    2.2.4.  fval
    2.2.5.  Future Tags
  2.3.  Content Limitations
  2.4.  RRset Limitations
  2.5.  Wildcard Limitation
  2.6.  Placement of the Leaf Node Name
3.  Operational Considerations
  3.1.  DNS Wildcards
  3.2.  Handling of RDATA
  3.3.  Currency
  3.4.  TTLs
  3.5.  Ambiguous Constructs
  3.6.  Robustness
  3.7.  Scope of Application
4.  Security Considerations
5.  Privacy Considerations
6.  IANA Considerations
7.  References
  7.1.  Normative References
  7.2.  Informative References
Appendix A.  Additional Examples
  A.1.  Example 1: Code Format
  A.2.  Example 2: Free Text Format
  A.3.  Example 3: URI Format
  A.4.  Example 4: Asking Price Format
  A.5.  Example 5: Combinations
Acknowledgements
Author's Address

1. Introduction ✨

Okay so there are some well-established services [RFC3912] [RFC9083] for checking whether a DNS domain name is registered 🔍. But here's the tea: a domain name existing doesn't automatically mean it can't be obtained. It might still be available for sale 💰.

Some registrars and other parties offer brokerage services between domain name holders and interested buyers 🤝. Those services are of limited value when the domain name isn't available for purchase, but they may be beneficial for domain names that are explicitly marked as for sale 💅.

This doc defines a simple way to explicitly signal that a domain name, even though it's registered, is available for purchase 🏷️. The domain name holder adds a reserved underscored leaf node name [RFC8552] to the zone to say the name is for sale. The indicator can be turned on and off at will 🔁. It's immediately deployable and doesn't require significant changes in existing services, so the concept can roll out smoothly 🦋.

The TXT RR type [RFC1035] created for this purpose must follow the formal definition of Section 2 📝. Its content may contain a pointer, such as a Uniform Resource Identifier (URI) [RFC3986], an Internationalized Resource Identifier (IRI) [RFC3987], or another string. That way, interested parties can get info or contact the domain name holder for further negotiations 💬. Details about whether and how those negotiations happen are out of scope 🙅.

With due caution, that info can also be built into automated availability services 🤖. When a service checks a domain name for purchasability, it may say whether the name is for sale and point to the seller's info.

The TXT content defined here is mainly meant for humans to read on screen 👀, not for algorithmic string comparison or automated processing.

This operational convention doesn't need any protocol change 🙌.

Examples are in Appendix A 💖.

1.1. Terminology

Here come the caps words, which are the important ones 💅: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Even though this document defines an operational convention rather than a protocol extension, it still uses normative language. The goal is consistent, unambiguous behaviour among entities that adopt the convention 🎀.

The term "processor" refers to an entity (person, system, or service) that reads, interprets, and takes appropriate actions based on _for-sale DNS labels, whether manually or automatically 🧚.

The term "for sale" is used in a broad sense. It may also refer to cases where the domain name is available for lease, or where the contractual right to use the domain name is offered to another party 🌈.

DNS terminology in this document follows [RFC9499] 📚.

2. Conventions 💜

2.1. General Record Format

Each _for-sale TXT record MUST begin with a version tag 🏁, optionally followed by a string containing content that follows a simple tag=value syntax.

The formal definition of the record format, using ABNF [RFC5234] [RFC7405], looks like this 🧠:

forsale-record  = forsale-version [forsale-content]
                  ; referred to as 'content' or RDATA
                  ; in a single character-string

forsale-version = %s"v=FORSALE1;"
                  ; %x76.3D.46.4F.52.53.41.4C.45.31.3B
                  ; version tag, case-sensitive, no spaces

forsale-content = fcod-pair / ftxt-pair / furi-pair / fval-pair
                  ; referred to as 'tag-value pairs'
                  ; only one tag-value pair per record

fcod-pair       = fcod-tag fcod-value
ftxt-pair       = ftxt-tag ftxt-value
furi-pair       = furi-tag furi-value
fval-pair       = fval-tag fval-value
                  ; the tags are referred to as 'content tags'
                  ; the values are referred to as 'content values'

fcod-tag        = %s"fcod="
ftxt-tag        = %s"ftxt="
furi-tag        = %s"furi="
fval-tag        = %s"fval="
                  ; all content tags case-sensitive lowercase

fcod-value      = 1*239OCTET

ftxt-value      = 1*239OCTET

furi-value      = URI / IRI
                  ; 'http', 'https', 'mailto', and 'tel' URI schemes
                  ; exactly one URI or IRI

URI             = <as defined in RFC3986, Appendix A>
IRI             = <as defined in RFC3987, Section 2.2>

fval-value      = fval-currency fval-amount
                  ; total length: 2 to 239 characters
fval-currency   = 1*%x41-5A
                  ; one or more uppercase letters (A-Z)
                  ; indicating (crypto)currency
                  ; e.g., USD, EUR, BTC, ETH
                  ; standard three-letter fiat currencies recommended
fval-amount     = int-part [ %x2E frac-part ]
                  ; integer part with optional fractional part
                  ; e.g., 0.00010
int-part        = 1*DIGIT
frac-part       = 1*DIGIT

A few quick vibes from that grammar 💅:

  • The version tag is case-sensitive and has no spaces ✨.
  • The content is referred to as 'content' or RDATA, and it sits in a single character-string 🧵.
  • Each record gets only one tag-value pair, and all the content tags are lowercase and case-sensitive 🔤.
  • The furi= value can be one URI or IRI, using the http, https, mailto, or tel URI schemes 🔗.
  • The fval= value is a currency part and an amount part, and its total length is 2 to 239 characters 💰.

See Section 2.2 for more detailed format definitions per content tag type.

Each _for-sale TXT record MUST NOT contain more than one tag-value pair, but multiple TXT records MAY be present in a single RRset 🎀.

Every tag-value pair in the RRset MUST be unique, but multiple instances of the same content tag MAY occur within a single RRset. For example, you can have two fcod= content tags, each with a different content value 👯.

See Section 2.4 for additional RRset limitations.

The OPTIONAL forsale-content provides information to interested parties, as explained in Section 1 🫶.

If the forsale-content is absent or invalid, but a valid version tag is present, processors SHOULD assume that the domain is for sale unless a local policy indicates otherwise. 🌈 For example:

_for-sale.example.com. IN TXT "v=FORSALE1;"
_for-sale.example.com. IN TXT "v=FORSALE1;fcod="
_for-sale.example.com. IN TXT "v=FORSALE1;foo=bar"

In those cases, processors figure out how to proceed. One approach is to signal that the domain is for sale and rely on conventional mechanisms (e.g., WHOIS or Registration Data Access Protocol (RDAP)) to retrieve and present contact information 🕵️‍♀️.

TXT records in the same RRset that lack a version tag MUST NOT be interpreted as a valid _for-sale indicator. Still, they may offer some additional information for humans when they're considered alongside a valid record 💅. For example:

_for-sale.example.com. IN TXT "I am for sale"
_for-sale.example.com. IN TXT "v=FORSALE1;fcod=XX-NGYyYjEyZWY"

If no TXT records at a _for-sale leaf node name contain a valid version tag, processors MUST consider the node name invalid and MUST ignore it 🙈.

See Section 2.3 for additional content limitations.

2.2. Content Tag Type Definitions 🎀

The following content tags are defined as valid content tags 🏷️.

Content tags are optional. Providing at least one to give interested parties a pointer for engagement is RECOMMENDED. 💖

2.2.1. fcod 🍓

Okay bestie, fcod= is basically a secret handshake code 🤫. Only processors that actually understand what it means can read it. The content value MUST consist of at least one octet.

How fcod= gets used is up to the parties working together. They agree on the rules, and that agreement is the whole rulebook 📜.

Picture a domain name registry that lets registrars plug a "for sale" URL into their back-end system. A unique code gets cooked up from that URL 🍳. That code becomes the value of the fcod= content tag in the _for-sale TXT record of a domain name. You'll see the exact record in a sec 👀.

When someone checks whether a domain name is available with a registry-provided tool, like a web interface, the registry may use that code to redirect them to the right "for sale" URL. That URL can include a query component with the domain name in it, like this:

https://forsale-url.example.com/exco?d=example.org

Why do it this way? Because the controlling parties keep the authority over redirection URLs and anything else derived from the content tag. That stops users from getting sent to unintended or malicious places, or being shown content nobody meant for them to see 🛡️. It's also super handy because the registry can tweak how fcod= values get interpreted in its back-end systems (like deciding which "for sale" URL to send people to) without touching a single _for-sale TXT record 💅.

Here's a string encoded with Base64 [RFC4648], with the prefix "EXCO-", used as the value of the content tag:

_for-sale IN TXT "v=FORSALE1;fcod=EXCO-S2lscm95IHdhcyBoZXJl"

Want more ways to use this tag? Check out Appendix A 🧚.

Note: As an implementation consideration, when several parties are involved in the domain sale process and they all use the same mechanism, it can be hard to figure out which content is yours in an RRset 😭. Slapping a recognisable prefix on the content (like "EXCO-") is one possible approach. This is left to the implementor though, because this document doesn't enforce it. In this case, Example Corporation (ExCo) recognises its own content tag and interprets it the way it was meant to be read. This example uses Base64 encoding to avoid escaping and keep the characters printable. That step is OPTIONAL and not required, btw 🌸.

2.2.2. ftxt 🌷

The ftxt= tag is for concise, human-readable text that tells interested parties extra info. For example:

_for-sale IN TXT "v=FORSALE1;ftxt=Call for info."

A single octet is the bare minimum, but it is RECOMMENDED to give more context 💭.

A URI in this field isn't syntactically banned, but there's no guarantee it'll be interpreted as a URI. So using URIs in this field SHOULD be avoided, and you should use the furi= content tag instead 🙅‍♀️.

If you want a way to clearly flag an asking price for easier machine parsing, see Section 2.2.4 🤑.

For the deal on how to represent non-ASCII data in the content value, see Section 3.2 🌍.

2.2.3. furi 🔗

The furi= tag holds a URI that's both human-readable and machine-parsable, so interested parties can grab more info from it 🦋.

The syntax technically allows any URI scheme, but only these ones are RECOMMENDED for use:

The content value MUST contain exactly one URI, like this:

_for-sale IN TXT "v=FORSALE1;furi=https://example.com/foo%20bar"

URIs MUST conform to the syntax and encoding requirements in Section 2.1 of [RFC3986]. That includes percent-encoding any characters that aren't allowed unencoded. For instance, spaces must be encoded as %20 in a URI 🫶.

Section 3.2 has more guidelines on character encoding 📖.

Check the Security Considerations section for possible risks ⚠️.

Note: References to a URI in this document also cover IRIs [RFC3987] 💜.

2.2.4. fval 💸

The fval= tag holds human-readable and machine-parsable text that clearly states an asking price in a certain currency 🤑.

Domain sellers publish price info all the time, so fval= gives that a structured format. That means reliable machine parsing and way less ambiguity than sticking prices into free-form ftxt= tags 💅. For example:

_for-sale IN TXT "v=FORSALE1;fval=EUR999"

The info in fval= isn't binding. It's just for indicative purposes 🙃. If you want current, reliable info, go straight to the seller via furi= or whatever other communication channels are available.

See Section 3.3 for more operational guidelines, and check the Security Considerations section for possible risks 🔐.

2.2.5. Future Tags 🔮

New tags might get defined later to cover operational needs. Future content tags MUST NOT change the semantics of existing content tags. That's a hard no 🙅‍♀️.

A tag name length of 4 characters is RECOMMENDED. That keeps things consistent with the initial tag set and the record formats nice and compact 🎀.

2.3. Content Limitations 🚧

The _for-sale TXT record [RFC8553] (Section 2.1) MUST contain content that's considered valid under the operational convention defined in this document. No exceptions, bestie 👑.

The _for-sale indicator is only for domain names that are actually available for purchase. Any text suggesting a domain isn't for sale is invalid content 🚫. When a domain stops being for sale, the _for-sale indicator needs to be removed 🧹.

Having a _for-sale leaf node name doesn't obligate the holder to sell the domain. It might've been published by mistake, or pulled back later for other reasons 🤷‍♀️.

This document doesn't dictate exactly how any content values in the _for-sale TXT record get used. Parties can use them in their tools, maybe even by defining specific requirements that the content value has to meet 🛠️. Content values can also be shown in a human-readable format so individuals can interpret them. Check Appendix A for clarification 📚.

See Section 3 for additional guidelines 🌈.

2.4. RRset Limitations 📦

This document doesn't put a limit on the number of TXT records in the RRset of _for-sale TXT records. Go wild 🎉.

When there are multiple _for-sale TXT records in an RRset, the processor MAY select one or more of them ✨.

Here's a fun example: a domain name registry might pull content from an RRset that has a recognisable fcod= content tag, then use it to send visitors to a sales page as part of its services 🛒. An individual, on the other hand, might grab a phone number (if there is one) from a furi= tag in that same RRset and use it to contact a potential seller 📞.

You can find an example of a combined record in Appendix A.5 🧚.

The RDATA [RFC9499] of each _for-sale TXT record MUST consist of a single character-string [RFC1035] with a maximum length of 255 octets. This avoids having to concatenate multiple character-strings during processing 🧩.

This invalid _for-sale TXT record shows what happens when you have multiple character-strings 🙈:

_for-sale IN TXT "v=FORSALE1;" "ftxt=foo" "bar" "invalid"

2.5. Wildcard Limitation 🃏

Wildcards only get interpreted as leaf names. So _for-sale.*.example. is not a valid wildcard [RFC4592] and it's non-conformant 💀. That means you can't put every domain under a Top-Level Domain (TLD) for sale with just one _for-sale TXT record.

The example below does show a common use case, though: a _for-sale leaf node name sitting right next to a wildcard 👀:

*         IN A    198.51.100.80
          IN AAAA 2001:db8::80
_for-sale IN TXT  "v=FORSALE1;ftxt=Only $99 at ExCo"

2.6. Placement of the Leaf Node Name 📍

The _for-sale leaf node name can go at any level of the DNS, except in the .arpa infrastructure TLD 🗺️.

Table 1 breaks it down 👇:

+================================+================+================+
| Name                           | Situation      | Verdict        |
+================================+================+================+
| _for-sale.example.             | Root zone      | For sale       |
+--------------------------------+----------------+----------------+
| _for-sale.aaa.example.         | Second level   | For sale       |
+--------------------------------+----------------+----------------+
| _for-sale.exco.bbb.example.    | Third level    | For sale       |
|                                | with public    |                |
|                                | registry       |                |
+--------------------------------+----------------+----------------+
| _for-sale.www.ccc.example.     | Third level    | See "Note 1"   |
|                                | without public | below          |
|                                | registry       |                |
+--------------------------------+----------------+----------------+
| _for-sale.51.198.in-addr.arpa. | Infrastructure | See "Note 2"   |
|                                | TLD            | below          |
+--------------------------------+----------------+----------------+
| xyz._for-sale.example.         | Invalid        | Non-conformant |
|                                | placement, not |                |
|                                | a leaf         |                |
+--------------------------------+----------------+----------------+

                 Table 1: Placements of TXT Record
Note 1: When the _for-sale leaf node name is applied to a label under a subdomain, there might not be a public domain name registry [RFC9499] that can properly record the rights tied to that label 🤔. Even so, that doesn't count as a violation of this document. One possible approach is for the involved parties to agree on something mutual to formalise those rights.
Note 2: If a _for-sale leaf node name showed up under the .arpa infrastructure TLD, it might get read as an offer to sell IP address space, E.164 numbers, or stuff like that 😬. But that use is explicitly out of scope for this document, and processors MUST ignore any such records 🚫.

The operational convention in this document is designed for the global DNS 🌐. Using it with Special-Use Domain Names [RFC6761] (like .onion or .alt) is out of scope 🙅‍♀️.

3. Operational Considerations 🛠️

3.1. DNS Wildcards 🌪️

DNS wildcards interact poorly with underscored names [RFC8552] (Section 1.4), but you can still run into them in practice 😤. That's especially true with operators who aren't implementing this mechanism. This is why the version tag is a mandatory element: it lets processors tell valid _for-sale records apart from unrelated TXT records 🎯.

Still, any assumptions about the content of _for-sale TXT records should be made with caution 🧐. That's extra true in edge cases where wildcard expansion (possibly combined with DNS aliases like CNAMEs, or redirections like DNAMEs [RFC6672]) could lead to misleading listings or unintended references to third-party domains 💅.

3.2. Handling of RDATA 🎀

okay bestie, this whole method runs on DNS TXT records, so the standard content rules from [RFC1035] (Section 3.3.14) apply here 📜 and yes, that includes the possibility of non-ASCII data in the content value 🌏✨

but ngl, non-ASCII data can get a little ambiguous 🙈 so it is RECOMMENDED that text in content values be encoded in UTF-8 [RFC3629], conform to the Network Unicode format [RFC5198], and use a subset of Unicode code points consistent with [RFC9839] (Section 4.3), with the exception of %x09, %x0A, and %x0D, which are best avoided 💅

Processors are RECOMMENDED to handle such encodings to ensure that non-ASCII content values are correctly interpreted and represented 🫶

Internationalized Domain Names (IDN) (e.g., in the "furi=" content tag) MAY appear as A-labels as well as U-labels [RFC5890], with U-labels encoded as described above 🌐

Implementation note: some DNS query tools return DNS records in presentation format, rather than the underlying RDATA content. Parsers of the ABNF in this document MUST ensure they operate on the raw TXT RDATA content, not its escaped presentation format [RFC1035] (Section 5.1). If the TXT RDATA consists of multiple character-strings, they SHOULD be concatenated into a single contiguous string prior to being interpreted as a UTF-8 encoded value matching the ABNF. this is the part where the copy-paste tools get messy, so pay attention 🧵

See Section 3.6 for additional guidelines and the Security Considerations section for possible risks 🚩

3.3. Currency 💸

The ABNF in Section 2.1 allows currency codes consisting of one or more uppercase letters, providing flexibility to accommodate both standard fiat currencies and other widely recognised abbreviations, such as cryptocurrencies. so you can use the classic money stuff or the crypto stuff, no judgement 🪙

The use of standard fiat currencies is RECOMMENDED. When used, they MUST be represented by three-letter uppercase currency codes as specified in [ISO4217] (e.g., USD, EUR, GBP, and JPY).

The amount component consists of an integer part, optionally followed by a fractional part separated by a decimal point (%x2E, "."). 🔢

3.4. TTLs ⏰

Long TTLs [RFC1035] (Section 3.2.1) increase the risk of outdated data misleading buyers into thinking the domain is still available or that advertised prices remain current. nobody wants a buyer chasing a listing that's been dead for weeks 💀

A TTL of 3600 seconds (1 hour) or less is RECOMMENDED, and the TTL values of all records in an RRset have to be the same [RFC2181] (Section 5.2). ⏳

3.5. Ambiguous Constructs 🧩

Ambiguous constructs in content values SHOULD be avoided, as illustrated by the following example:

_for-sale IN TXT "v=FORSALE1;fcod=TRIP-confusing;ftxt=dont_do_this"

The above example is a valid "fcod=" content tag that includes the string ";ftxt=" in the content value, which may be confusing, as it does not actually represent an "ftxt=" content tag. it's giving "I'm a fcod but I'm also pretending to be an ftxt" and honestly? Not the vibe 🙃

3.6. Robustness 🛡️

Because the format of the content part is not strictly defined in this document, processors MAY apply the robustness principle of being liberal in what they accept. This also applies to space characters (%x20) immediately following the version tag. the liberal-accept energy is very generous of them 🫶

Alternatively, parties may agree on a more strictly defined proprietary format for the content value to reduce ambiguity. However, it is out of scope to discuss which mechanisms are put in place for such agreements. 🤝

When encountering unexpected or prohibited control characters in "ftxt=" content (e.g., %x09, %x0A, %x0B, %x0D; see Section 3.2), processors MAY sanitise them by replacing them with spaces (%x20) to ensure correct representation or replacing them with the Unicode REPLACEMENT CHARACTER U+FFFD (%xEF.BF.BD) to signal the presence of problematic content. cleaning up the weird characters is giving spa day, and the little ❓ symbol is basically a neon sign saying "something's sus here" 🧹✨

3.7. Scope of Application 🔭

The _for-sale mechanism relies upon the domain name being resolvable in the DNS. This is not guaranteed, for example, during a redemption period, in pendingDelete status [STD69], or when the domain is DNSSEC signed but fails validation (i.e., has a bogus state). so if the domain is having a rough time, the listing might be too 😭

4. Security Considerations 🚨

One use of the TXT record type defined in this document is to parse the content it contains and to publish certain information from it on a website or elsewhere. However, there is a risk if the domain name holder publishes a malicious URI or one that points to improper content. This may result in reputational damage to the party parsing the record. publishing sketchy links is a whole reputational disaster, bestie 💀

An even more serious scenario arises when the content of the TXT record is not properly validated and sanitised, potentially enabling attacks such as cross-site scripting (XSS) or SQL injection, as well as spoofing techniques based on Unicode manipulation, including bidirectional text attacks and homograph attacks. this part is genuinely serious, so please take it seriously 🔥

Therefore, parsing and publishing this information requires careful validation to ensure that only valid characters and formats are processed. Possible mitigation strategies include output sanitisation, maintaining a curated and validated list of URIs, or applying other validation methods, such as URI reputation checks before display. 🧼

Automatically following URIs from "_for-sale" records without user consent creates security risks, including exposure to malware, phishing pages, and scripted attacks. Processors MUST NOT automatically redirect users when encountering "furi=" content tags without requiring explicit confirmation before navigation. This allows users to inspect the destination before proceeding. never auto-open a link someone else wrote, periodt 🙅‍♀️

Some URI schemes recommended in Section 2.2.3 do not mandate transport security (e.g., 'http', 'mailto'); therefore, more secure schemes such as 'https' are preferred. 🔐

There is also a risk that this method will be abused as a marketing tool or to lure individuals into visiting certain sites or making contact by other means, without there being any intention to actually sell the domain name. so, bait-and-switch energy, not the vibe 🎣

Domain name holders may advertise artificially low prices, and processors that present "fval=" data to users SHOULD display appropriate disclaimers (e.g., "Price indicative only - verify with seller"). Automated systems SHOULD NOT make purchase commitments based solely on advertised prices without human verification. 🏷️ a price that looks too good to be true is giving clickbait, so double-check it, babe 👀

5. Privacy Considerations 🫣

The use of the "_for-sale" leaf node name publicly indicates the intent to sell a domain name. Domain name holders should be aware that this information is accessible to anyone querying the DNS and may have privacy implications. basically, the whole internet can see that you're selling, so plan accordingly 👁️

There is a risk of data scraping, such as the scraping of email addresses and phone numbers. 🤖

Publishing contact information may expose domain name holders to spam or unwanted contact. 📵

6. IANA Considerations 🏷️

IANA has added the following entry to the "Underscored and Globally Scoped DNS Node Names" registry [RFC8552]:

                   +=========+============+===========+
                   | RR Type | _NODE NAME | Reference |
                   +=========+============+===========+
                   | TXT     | _for-sale  | RFC 10023 |
                   +---------+------------+-----------+

                          Table 2: Entry for the
                     Underscored and Globally Scoped
                         DNS Node Names Registry

7. References 📚

7.1. Normative References 🔗

7.2. Informative References 📚

Here's the background reading that gets cited along the way, bestie 🧚

Appendix A. Additional Examples ✨

A.1. Example 1: Code Format 🧩

Okay so this one is a proprietary format that parties agree on between themselves (think a domain name registry and its registrars 🏢), and there's no clearly specified meaning for third parties 🙈. For example, it may be used to automatically redirect visitors to a web page, as described in Section 2.2.1:

_for-sale IN TXT "v=FORSALE1;fcod=XX-aHR0cHM...wbGUuY29t"

Note: The content value in the above example is truncated for readability.

The fcod= content tag is, in principle, totally unrestricted 🌈, which means implementors can define additional uses as needed. For example, it may convey arbitrary formatting or conditional display instructions, such as adding an extra banner (e.g., "eligibility criteria apply") or specifying a style, including color, font, emojis, or logos. It's giving customization queen 💅

A.2. Example 2: Free Text Format 📝

The following example shows a free text format with additional unstructured information intended to be human-readable:

_for-sale IN TXT "v=FORSALE1;ftxt=Eligibility criteria apply."

The content in the following example could be malicious, but it is not in violation of the convention in this document (see the Security Considerations section):

_for-sale IN TXT "v=FORSALE1;ftxt=<script>...</script>"
Could be malicious, so keep your guard up 🚨 Check the Security Considerations section before you trust any of this text.

A.3. Example 3: URI Format 🔗

The following example shows the TXT record that the holder of "example.com" adds to the zone to signal that the domain is for sale:

_for-sale IN TXT "v=FORSALE1;furi=https://example.com/fs?d=eHl6"

An interested party notices this signal and can visit the URI mentioned for further information. The TXT record may also be processed by automated tools, but see the Security Considerations section for possible risks. 👀

As an alternative, a 'mailto' URI could also be used:

_for-sale IN TXT "v=FORSALE1;furi=mailto:hq@example.com?subject=foo"

Or a telephone URI:

_for-sale IN TXT "v=FORSALE1;furi=tel:+1-201-555-0123"

There can be a use case for these URIs, especially since WHOIS (or RDAP) often has privacy restrictions, but see the Privacy Considerations section for possible downsides. 🦋

A.4. Example 4: Asking Price Format 💸

The following examples illustrate the asking price format, which consists of an uppercase currency code (e.g., USD or EUR) followed by a numeric amount. See Section 3.3 for additional guidelines.

In Bitcoins:

_for-sale IN TXT "v=FORSALE1;fval=BTC0.000010"

In US dollars:

_for-sale IN TXT "v=FORSALE1;fval=USD750"

A.5. Example 5: Combinations 🌸

The following example shows multiple valid TXT records from which a processor can choose. Pick your fave, it's literally a buffet 🍓

_for-sale IN TXT "v=FORSALE1;furi=https://fs.example.com/"
          IN TXT "v=FORSALE1;ftxt=This domain name is for sale"
          IN TXT "v=FORSALE1;fval=EUR500"
          IN TXT "v=FORSALE1;fcod=EXCO-ZGVhZGJlZWYx"
          IN TXT "v=FORSALE1;fcod=XYZ1-MTExLTIyMi0zMzMtNDQ0"

Acknowledgements 🫶

The author would like to thank Thijs van den Hout, Caspar Schutijser, Melvin Elderman, Ben van Hartingsveldt, Jesse Davids, Juan Stelling, John R. Levine, Dave Lawrence, Andrew Sullivan, Paul Hoffman, Eliot Lear (ISE), Viktor Dukhovni, James Gannon, Watson Ladd, Tim Wicinski, Russ Housley, Takahiro Nemoto, Chongfeng Xie, Joe Abley, and Mohamed 'Med' Boucadair for their valuable feedback 💖

Author's Address 💌

Here's how to reach the author:

Marco Davids
SIDN Labs
Meander 501
6825 MD Arnhem
Netherlands
Phone: +31 26 352 5500
Email: marco.davids@sidn.nl
📦 where this page comes from