Internet-Draft forsalereg November 2025
Davids Expires 17 May 2026 [Page]
Workgroup:
Independent Submission Editor (ISE)
Internet-Draft:
draft-davids-forsalereg-14
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 for using the reserved underscored DNS leaf node name "_for-sale" to indicate that the parent domain name is available for purchase. This approach enables easy deployment without affecting ongoing operations, allowing the method to be applied to a domain name that is still in full 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 several "Notes to the RFC Editor", including this section. These should be reviewed and resolved prior to publication.

Please also review the Status of This Memo section and other relevant parts before publication.

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 17 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. This allows for a smooth introduction of the concept.

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 9.

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 registry for known content tags is created in Section 6, 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 MUST 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 Additional Examples section for clarification.

See Section 5 for additional guidelines.

3.4. RRset Limitations

This specification does not define restrictions on the number of TXT records in the RRset.

When multiple content TXT records are present, the processor MAY select one or more of them.

For example, a domain name registry might extract content from an RRset that includes a recognizable "fcod=" content tag and use it to direct visitors to a sales page as part of its services. An individual, on the other hand, might extract a phone number (if present) from a "furi=" tag in the same RRset and use it to contact a potential seller.

An example of such a combined record is provided in Section 4.5.

The RDATA [RFC9499] of each TXT record MUST consist of a single character-string [RFC1035] with a maximum length of 255 octets, to avoid the need to concatenate multiple character-strings during processing.

The following example illustrates an invalid TXT record due to the presence of multiple character-strings:

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

3.5. Wildcard Limitation

Wildcards are only interpreted as leaf names, so "_for-sale.*.example." is not a valid wildcard and is non-conformant. Hence, it is not possible to put all domains under a TLD for sale with just one TXT record.

The example below, however, shows a common use case where a "_for-sale" leaf node exists alongside a wildcard:

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

3.6. Placement of the Leaf Node Name

The "_for-sale" leaf node name can essentially be placed at any level of the DNS except in the in-addr.arpa. infrastructure TLD.

Table 1 illustrates this:

Table 1: Placements of TXT record
Name Situation Verdict
_for-sale.example. root zone For sale
_for-sale.aaa.example. second level For sale
_for-sale.acme.bbb.example. third level with public registry For sale
_for-sale.www.ccc.example. third level without public registry See note 1
_for-sale.51.198.in-addr.arpa. infrastructure TLD See note 2
xyz._for-sale.example. Invalid placement, not a leaf non-conformant

Note 1: When the "_for-sale" leaf node is applied to a label under a subdomain, there may not be a public domain name registry [RFC8499] capable of properly recording the rights associated with that label. Nevertheless, this does not constitute a violation of this document. One possible approach is for the involved parties to establish a mutual agreement to formalize these rights.

Note 2: If a "_for-sale" leaf node were to appear under the .arpa infrastructure top-level domain, it might be interpreted as an offer to sell IP address space. However, such use is explicitly out of scope for this document, and processors MUST ignore any such records.

4. Additional Examples

4.1. Example 1: Code Format

A proprietary format, defined and used by agreement between parties - for example, a domain name registry and its registrars - without a clearly specified meaning for third parties. For example, it may be used to automatically redirect visitors to a web page, as described in Section 3.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 use of the "fcod=" content tag is, in principle, unrestricted, allowing implementers to 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.

4.2. Example 2: Free Text Format

Free format text, with some additional unstructured information, aimed at being 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 this specification (see the Security Considerations):

_for-sale IN TXT "v=FORSALE1;ftxt=<script>...</script>"

4.3. Example 3: URI Format

The holder of "example.com" wishes to signal that the domain is for sale and adds this record to the "example.com" zone:

_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.

4.4. Example 4: Asking Price Format

Consists of an uppercase currency code (e.g., USD, EUR), followed by a numeric amount. See Section 5.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"

4.5. Example 5: Combinations

An example of multiple valid TXT records from which a processor can choose:

_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=ACME-ZGVhZGJlZWYx"
          IN TXT "v=FORSALE1;fcod=XYZ1-MTExLTIyMi0zMzMtNDQ0"

5. Operational Guidelines

5.1. DNS Wildcards

DNS wildcards interact poorly with underscored names [RFC8552] (Section 1.4), but they may still be encountered in practice, especially with operators who are not implementing this mechanism. This is why the version tag is a REQUIRED element: it allows processors to distinguish valid "_for-sale" records from unrelated TXT records.

Nonetheless, any assumptions about the content of "_for-sale" TXT records SHOULD be made with caution, particularly in edge cases where wildcard expansion - possibly combined with DNS aliases (e.g., CNAMEs) or redirections (e.g., DNAMEs [RFC6672]) - might result in misleading listings or unintended references to third-party domains.

5.2. Handling of RDATA

All text exchanged between systems that are not part of a closed ecosystem MUST be encoded in UTF-8 [RFC3629] and conform to the Network Unicode format [RFC5198].

Since this method relies on DNS TXT records, standard content rules apply as defined in [RFC1035] (Section 5.1). For the "ftxt=" content tag, this includes the possibility of representing non-ASCII data in the content value, for instance by using UTF-8 or escape sequences (e.g., \DDD or \X notation).

Processors SHOULD be capable of handling such encodings to ensure that non-ASCII content values are interpreted correctly.

Note: When UTF-8 is used, the ABNF octet limit applies to the encoded byte sequence, not the number of visible characters. Multi-byte characters will reduce the available character count.

For example, this TXT record contains two Japanese Kanji characters encoded in UTF-8 using octal escapes, resulting in a content value of six octets.

_for-sale IN TXT "v=FORSALE1;ftxt=\229\163\178\229\135\186"

5.3. Currency

The ABNF in Section 3.1 allows currency codes consisting of one or more uppercase letters, providing flexibility to accommodate both standard fiat currencies and other widely recognized abbreviations, such as cryptocurrencies.

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, JPY).

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

5.4. TTLs

Long TTLs [RFC1035] (Section 3.2.1) increase the risk of outdated data misleading buyers into thinking the domain is still available.

5.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.

5.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. Alternatively, parties may agree on a more strictly defined proprietary format for the content value to reduce ambiguity.

5.7. Scope of Application

Note that this mechanism relies on the domain name being resolvable in the DNS. This is not guaranteed, for example during a redemption period, in pending delete status [STD69], or when the domain is DNSSEC-signed but fails validation (i.e., has a bogus state).

6. IANA Considerations

IANA has established the "Underscored and Globally Scoped DNS Node Names" registry [RFC8552][IANA]. The underscored leaf node name defined in this specification should be added as follows:

Table 2: Entry for the "Underscored and Globally Scoped DNS Node Names" registry
RR Type _NODE NAME Reference
TXT _for-sale <this memo>

<NOTE TO RFC EDITOR: Adjust the text in the table above before publication with a citation for the (this) document making the addition as per RFC8552.>

A registry group called "The '_for-sale' Underscored and Globally Scoped DNS Node Name" [FORSALEREG] is to be created, along with a registry called "Content Tags" within it. This registry group will be maintained by IANA.

A publicly accessible example of such an IANA registry, including relevant notes (but using 'SIDN Labs' instead of 'IANA'), can be found at:

https://forsalereg.sidnlabs.nl/

<NOTE TO RFC EDITOR: Please validate and improve the example where needed and remove the text about the example registry above, prior to publication.>

The registry entries consist of content tags as defined in Section 3.2.

The initial set of entries in this registry is as follows:

Table 3: Initial set of entries in the "Content Tags" registry
Tag Name Reference Status Description
fcod RFCXXXX active For Sale Proprietary Code
ftxt RFCXXXX active For Sale Free Format Text
furi RFCXXXX active For Sale URI
fval RFCXXXX active For Sale Asking Price

<NOTE TO RFC EDITOR: Adjust the text in the table above before publication with a citation for the (this) document making the addition as per RFC8552.>

Future updates will be managed by the Change Controller.

Entries are assigned only for values that have been documented in a manner consistent with the "RFC Required" registration policy defined in [RFC8126].

Newly defined content tags MUST NOT alter the semantics of existing content tags.

The addition of a new content tag to the registered list does not require the definition of a new version tag. However, any modification to existing content tags does.

The "status" column can have one of the following values:

This registry group is maintained by IANA as per [RFC8726].

7. Privacy Considerations

The use of the "_for-sale" leaf node name publicly indicates the intent to sell a domain name. Domain holders should be aware that this information is accessible to anyone querying the DNS and may have privacy implications.

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

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

8. Security Considerations

One use of the TXT record type defined in this document is to parse the content it contains and to automatically 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.

An even more serious scenario arises when the content of the TXT record is insufficiently validated and sanitized, potentially enabling attacks such as XSS or SQL injection.

Therefore, it is RECOMMENDED that any parsing and publishing is conducted with the utmost care. Possible approaches include maintaining a list of validated URIs or applying other validation methods after parsing and before publishing.

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. Therefore, this method is best suited for use by professionals.

9. Ethical Considerations

Although not specifically designed for this purpose, the mechanisms described in this document may also facilitate domain name transactions by professional speculators, often referred to as domainers, and those commonly referred to as domain drop catchers. Some may view this as controversial.

However, by enabling domain holders to more explicitly signal their intent to sell, the proposed approach aims to introduce greater clarity and predictability into the domain lifecycle. This potentially reduces the advantage currently held by these professionals, and fosters a more equitable environment for all.

Furthermore, this mechanism avoids creating unnecessary dependencies on registries for market transactions, which could otherwise introduce complexities and potential for unintended commercial entanglements.

10. Implementation Status

The concept described in this document has been in use at the .nl ccTLD registry since 2022, when it initially started as a pilot. Since then, several hundred thousand domain names have been marked with the "_for-sale" indicator. See for example:

https://www.sidn.nl/en/whois?q=example.nl

The Dutch domain name registry SIDN offers registrars the option to register a sales landing page via its registrar dashboard following the "fcod=" method. When this option is used, a unique code is generated, which can be included in the "_for-sale" record. If such a domain name is entered on the domain finder page of SIDN, a "for sale" button is displayed accordingly.

A simple demonstration of a validator is present at:

https://forsalereg.sidnlabs.nl/demo

<NOTE TO RFC EDITOR: Please remove this section before publication as per RFC7942.>

11. 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, and Eliot Lear (ISE) for their valuable feedback.

12. References

12.1. Normative References

[RFC1035]
Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, , <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC3629]
Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, , <https://www.rfc-editor.org/info/rfc3629>.
[RFC3986]
Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, , <https://www.rfc-editor.org/info/rfc3986>.
[RFC5234]
Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, , <https://www.rfc-editor.org/info/rfc5234>.
[RFC7405]
Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, , <https://www.rfc-editor.org/info/rfc7405>.
[RFC8126]
Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

12.2. Informative References

[FORSALEREG]
SIDN Labs, "The "_for-sale" Underscored and Globally Scoped DNS Node Name", <https://forsalereg.sidnlabs.nl/forsale-parameters>.
[IANA]
IANA, "Underscored and Globally Scoped DNS Node Names", <https://www.iana.org/assignments/dns-parameters/dns-parameters.xml#underscored-globally-scoped-dns-node-names>.
[ISO4217]
SIX Group, "ISO 4217 Currency Codes", <https://www.iso.org/iso-4217-currency-codes.html>.
[RFC3912]
Daigle, L., "WHOIS Protocol Specification", RFC 3912, DOI 10.17487/RFC3912, , <https://www.rfc-editor.org/info/rfc3912>.
[RFC3966]
Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, , <https://www.rfc-editor.org/info/rfc3966>.
[RFC4648]
Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, , <https://www.rfc-editor.org/info/rfc4648>.
[RFC5198]
Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, , <https://www.rfc-editor.org/info/rfc5198>.
[RFC6068]
Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, DOI 10.17487/RFC6068, , <https://www.rfc-editor.org/info/rfc6068>.
[RFC6672]
Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, DOI 10.17487/RFC6672, , <https://www.rfc-editor.org/info/rfc6672>.
[RFC8499]
Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 8499, DOI 10.17487/RFC8499, , <https://www.rfc-editor.org/info/rfc8499>.
[RFC8552]
Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, , <https://www.rfc-editor.org/info/rfc8552>.
[RFC8553]
Crocker, D., "DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names", BCP 222, RFC 8553, DOI 10.17487/RFC8553, , <https://www.rfc-editor.org/info/rfc8553>.
[RFC8726]
Farrel, A., "How Requests for IANA Action Will Be Handled on the Independent Stream", RFC 8726, DOI 10.17487/RFC8726, , <https://www.rfc-editor.org/info/rfc8726>.
[RFC9083]
Hollenbeck, S. and A. Newton, "JSON Responses for the Registration Data Access Protocol (RDAP)", STD 95, RFC 9083, DOI 10.17487/RFC9083, , <https://www.rfc-editor.org/info/rfc9083>.
[RFC9110]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, , <https://www.rfc-editor.org/info/rfc9110>.
[RFC9499]
Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, , <https://www.rfc-editor.org/info/rfc9499>.
[STD69]
Internet Standard 69, <https://www.rfc-editor.org/info/std69>.
At the time of writing, this STD comprises the following:
Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, , <https://www.rfc-editor.org/info/rfc5730>.
Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/RFC5731, , <https://www.rfc-editor.org/info/rfc5731>.
Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732, , <https://www.rfc-editor.org/info/rfc5732>.
Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, , <https://www.rfc-editor.org/info/rfc5733>.
Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Transport over TCP", STD 69, RFC 5734, DOI 10.17487/RFC5734, , <https://www.rfc-editor.org/info/rfc5734>.

Author's Address

Marco Davids
SIDN Labs
Meander 501
6825 MD Arnhem
Netherlands
Phone: +31 26 352 5500