Internet-Draft forsalereg November 2025
Davids Expires 18 May 2026 [Page]
Workgroup:
Independent Submission Editor (ISE)
Internet-Draft:
draft-davids-forsalereg-15
Published:
Intended Status:
Informational
Expires:
Author:
M. Davids
SIDN Labs

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

Abstract

This document defines an operational convention that uses the reserved underscored DNS leaf node name "_for-sale" to indicate 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.

This document is not an IETF consensus document: it is published for informational purposes.

About This Document

This note is to be removed before publishing as an RFC.

This document contains a "Note to the RFC Editor" requesting removal of Section 9 prior to publication. Please also review the Status of This Memo section and other relevant parts before publication, particularly Section 10.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 18 May 2026.

▲

Table of Contents

1. Introduction

Well-established services [RFC3912][RFC9083] exist to determine whether a domain name is registered. However, the fact that a domain name exists does not necessarily mean it is unavailable; it may still be for sale.

Some registrars and other parties offer brokerage services between domain name holders and interested buyers. Such services are of limited value when the domain name is not available for purchase, but they may be beneficial for domain names that are clearly being offered for sale.

This specification defines a lightweight method to ascertain whether a domain name, although registered, is available for purchase. It enables a domain name holder to add a reserved underscored leaf node name [RFC8552] in the zone, indicating that the domain name is for sale.

The TXT RR type [RFC1035] created for this purpose MUST follow the formal definition of Section 3. Its content MAY contain a pointer, such as a Uniform Resource Identifier (URI) [RFC3986], or another string, allowing interested parties to obtain information or contact the domain name holder for further negotiations.

With due caution, such information can also be incorporated into automated availability services. When checking a domain name for availability, the service may indicate whether it is for sale and provide a pointer to the seller's information.

Note: In this document, the term "for sale" is used in a broad sense and 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.

1.1. Terminology

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.

2. Rationale

There are undoubtedly more ways to address this problem space. The reasons for the approach defined in this document are primarily accessibility and simplicity. The indicator can be easily turned on and off at will and, moreover, it is immediately deployable and does not require significant changes in existing services, allowing for a smooth introduction of the concept.

The method described in this memo does not alter existing IETF standards.

Furthermore, the chosen approach aligns with ethical considerations by promoting a more equitable domain aftermarket and minimizing potential for unintended commercial entanglements by registries, as detailed in Section 8.

3. Conventions

3.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], is as follows:

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
                  ; http, https, mailto and tel URI schemes
                  ; exactly one URI

URI             = <as defined in RFC3986, Appendix A>

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

See Section 3.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 (e.g., two "fcod=" content tags, each with a different content value).

See Section 3.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. 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 such cases, processors SHOULD determine how to proceed. An approach might be to signal that the domain is for sale and to rely on traditional mechanisms such as WHOIS or RDAP to retrieve and present contact information.

TXT records in the same RRset, but without a version tag, MUST NOT be interpreted or processed as a valid "_for-sale" indicator. However, they may still offer some additional information for humans when 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 leaf node contain a valid version tag, processors MUST consider the node name invalid and discard it.

See Section 3.3 for additional content limitations.

3.2. Content Tag Type Definitions

A new IANA sub-registry for known content tags is created in Section 10.2, with this document registering the initial set. Implementations SHOULD process only registered tags they support, and MAY ignore any others.

The following content tags are defined as the initial valid content tags.

3.2.1. fcod

This content tag is intended to contain a code that is meaningful only to processors that understand its semantics. The content value MUST consist of at least one octet.

The manner in which the "fcod=" content tag is used is determined by agreement between cooperating parties.

For example, a domain name registry may allow registrars to enter a "for sale" URL into their system. From that URL, a unique code is generated. This code is inserted as the value of the "fcod=" content tag of the "_for-sale" TXT record of a domain name, as shown in the example below.

When a user checks the availability of the domain name using a registry-provided tool (e.g., a web interface), the domain name registry may use the code to redirect the user to the appropriate "for sale" URL, which may include a query component containing the domain name, for example:

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

The rationale for this approach is that controlling parties retain authority over redirection URLs and any other information derived from the content tag, thereby preventing users from being sent to unintended or malicious destinations or from being presented with unintended content.

The following example shows a string encoded using Base64 [RFC4648] preceded by the prefix "ACME-" as the value of the content tag:

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

See the Additional Examples section for other possible uses of this content tag.

Note: As an implementation consideration, when multiple parties are involved in the domain sale process and use the same mechanism, it may be difficult to identify the relevant content in an RRset. Adding a recognizable prefix to the content (e.g., "ACME-") is one possible approach. However, this is left to the implementor, as it is not enforced in this document. In this case, ACME would recognize its content tag and interpret it as intended. This example uses Base64 encoding to avoid escaping and ensure printable characters, though this is also OPTIONAL and not required.

3.2.2. ftxt

This content tag is intended to contain human-readable text that conveys information to interested parties. For example:

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

While a single octet is the minimum, it is RECOMMENDED to provide more context.

While a URI in this field is not syntactically prohibited, its interpretation as a URI is not guaranteed. Use of URIs in this field SHOULD be avoided in favor of the "furi=" content tag.

See Section 3.2.4 for a way to explicitly indicate an asking price for easier machine parsing.

See Section 5.2 for considerations regarding the representation of non-ASCII data in the content value.

3.2.3. furi

This content tag is intended to contain a human-readable and machine-parseable URI that conveys information to interested parties.

While the syntax allows any URI scheme, only the following schemes are RECOMMENDED for use: http and https [RFC9110], mailto [RFC6068], and tel [RFC3966].

The content value MUST contain exactly one URI. For example:

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

URIs MUST conform to the syntax and encoding requirements specified in Section 2.1 of [RFC3986], including the percent-encoding of characters not allowed unencoded (e.g., spaces MUST be encoded as %20 in a URI).

See the Security Considerations section for possible risks.

3.2.4. fval

This content tag is intended to contain human-readable and machine-parseable text that explicitly indicates an asking price in a certain currency, as opposed to the price being loosely incorporated in an "ftxt=" content tag. For example:

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

See Section 5.3 for additional operational guidelines.

3.3. Content Limitations

The "_for-sale" TXT record [RFC8553] (Section 2.1) MUST contain content deemed valid under this specification.

Any text suggesting that a domain is not for sale is invalid content. If a domain name is not or no longer for sale, a "_for-sale" indicator SHOULD NOT exist. The presence of a valid "_for-sale" TXT record SHOULD therefore be regarded as an indication that the domain name is for sale.

The existence of a "_for-sale" leaf node does not obligate the holder to sell the domain name; it may have been published in error, or withdrawn later for other reasons.

This specification does not dictate the exact use of any content values in the "_for-sale" TXT record. Parties MAY use it in their tools, perhaps even by defining specific requirements that the content value must meet. Content values can also be represented in a human-readable format for individuals to interpret. See the