SIDN Labs

Meander 501 Arnhem 6825 MD Netherlands +31 26 352 5500 marco.davids@sidn.nl

OPS domain name system domain sale domain brokerage domain aftermarket TXT record attrleaf This document defines an operational convention that uses the reserved underscored DNS leaf node name "_for-sale" to indicate 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 This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice 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 () in effect on the date of publication of this document. Please review these documents carefully, as 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 are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction
  • .  Terminology
• .  Conventions
  • .  General Record Format
  • .  Content Tag Type Definitions
    • .  fcod
    • .  ftxt
    • .  furi
    • .  fval
    • .  Future Tags
  • .  Content Limitations
  • .  RRset Limitations
  • .  Wildcard Limitation
  • .  Placement of the Leaf Node Name
• .  Operational Considerations
  • .  DNS Wildcards
  • .  Handling of RDATA
  • .  Currency
  • .  TTLs
  • .  Ambiguous Constructs
  • .  Robustness
  • .  Scope of Application
• .  Security Considerations
• .  Privacy Considerations
• .  IANA Considerations
• .  References
  • .  Normative References
  • .  Informative References
• .  Additional Examples
  • .  Example 1: Code Format
  • .  Example 2: Free Text Format
  • .  Example 3: URI Format
  • .  Example 4: Asking Price Format
  • .  Example 5: Combinations
• Acknowledgements
• Author's Address

Introduction Well-established services exist for determining whether a DNS domain name is registered. However, the existence of a domain name does not necessarily imply that it cannot be obtained; it may still be available 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 explicitly marked as for sale. This document defines a simple method to explicitly signal that a domain name, although registered, is available for purchase. It enables a domain name holder to add a reserved underscored leaf node name in the zone, indicating that the domain name is for sale. The indicator can be 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 TXT RR type created for this purpose must follow the formal definition of . Its content may contain a pointer, such as a Uniform Resource Identifier (URI) , an Internationalized Resource Identifier (IRI) , or another string, allowing interested parties to obtain information or contact the domain name holder for further negotiations. Details about whether and how such negotiations occur are out of scope. With due caution, such information can also be incorporated into automated availability services. When checking a domain name for purchasability, the service may indicate whether it is for sale and provide a pointer to the seller's information. The TXT content defined by this document is intended primarily for human-readable informational display, rather than for algorithmic string comparison or automated processing. The operational convention described in this document does not require any protocol change. Examples are provided in .

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 when, and only when, they appear in all capitals, as shown here. Although this document defines an operational convention rather than a protocol extension, normative language is used to promote consistent and unambiguous behaviours 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 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. DNS terminology in this document follows .

Conventions

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 , 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 / 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 See 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 for additional RRset limitations. The OPTIONAL forsale-content provides information to interested parties as explained in . 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 such cases, processors determine how to proceed. An approach might be to signal that the domain is for sale and to 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. 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 "_for-sale" leaf node name contain a valid version tag, processors MUST consider the node name invalid and MUST ignore it. See for additional content limitations.

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.

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 back-end 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/exco?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. This approach also allows the interpretation of "fcod=" content values to be adjusted centrally in back-end systems, such as determining which "for sale" URL to redirect to, without modifying the "_for-sale" TXT records. The following example shows a string encoded using Base64 preceded by the prefix "EXCO-" as the value of the content tag: _for-sale IN TXT "v=FORSALE1;fcod=EXCO-S2lscm95IHdhcyBoZXJl" See 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 recognisable prefix to the content (e.g., "EXCO-") is one possible approach. However, this is left to the implementor, as it is not enforced in this document. In this case, Example Corporation (ExCo) would recognise its content tag and interpret it as intended. This example uses Base64 encoding to avoid escaping and ensure printable characters, though this is OPTIONAL and not required.

ftxt This content tag is intended to contain concise, human-readable text that conveys additional 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 favour of the "furi=" content tag. See for a way to explicitly indicate an asking price for easier machine parsing. See for considerations regarding the representation of non-ASCII data in the content value.

furi This content tag is intended to contain a human-readable and machine-parsable URI that can be used by interested parties to retrieve further information. While the syntax allows any URI scheme, only the following schemes are RECOMMENDED for use:

• 'http' and 'https' (see ),
• 'mailto' (see and ), and
• 'tel' (see ).

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 , including the percent-encoding of characters not allowed unencoded (e.g., spaces must be encoded as %20 in a URI). provides additional guidelines on character encoding. See the section for possible risks. Note: References to a URI in this document also encompass IRIs .

fval This content tag is intended to contain human-readable and machine-parsable text that explicitly indicates an asking price in a certain currency. Price information is commonly published by domain sellers. The "fval=" content tag provides a structured format for this purpose, enabling reliable machine parsing and reducing ambiguity compared to embedding prices in free-form "ftxt=" content tags. For example: _for-sale IN TXT "v=FORSALE1;fval=EUR999" The information provided in "fval=" is not binding and is intended for indicative purposes only. Current and reliable information can be obtained by engaging directly via "furi=" or other available communication mechanisms. See for additional operational guidelines and the section for possible risks.

Future Tags Future tags may be defined to accommodate operational needs. Future content tags MUST NOT alter the semantics of existing content tags. A tag name length of 4 characters is RECOMMENDED for consistency with the initial tag set and to maintain compact record formats.

Content Limitations The "_for-sale" TXT record MUST contain content deemed valid under the operational convention defined in this document. The "_for-sale" indicator is only to be used for domain names that are available for purchase. Any text suggesting that a domain is not for sale is invalid content. When a domain name is no longer for sale, the "_for-sale" indicator is to be removed. The existence of a "_for-sale" leaf node name does not obligate the holder to sell the domain name; it may have been published in error or withdrawn later for other reasons. This document 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 for clarification. See for additional guidelines.

RRset Limitations This document does not impose a limit on the number of TXT records in the RRset of "_for-sale" TXT records. When multiple "_for-sale" TXT records are present in an RRset, the processor MAY select one or more of them. For example, a domain name registry might extract content from an RRset that includes a recognisable "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 . The RDATA of each "_for-sale" TXT record MUST consist of a single character-string with a maximum length of 255 octets, to avoid the need to concatenate multiple character-strings during processing. The following example illustrates an invalid "_for-sale" TXT record due to the presence of multiple character-strings: _for-sale IN TXT "v=FORSALE1;" "ftxt=foo" "bar" "invalid"

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 Top-Level Domain (TLD) for sale with just one "_for-sale" TXT record. The example below, however, shows a common use case where a "_for-sale" leaf node name 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 ExCo"

Placement of the Leaf Node Name The "_for-sale" leaf node name can be placed at any level of the DNS, except in the .arpa infrastructure TLD. illustrates this: Placements of TXT Record

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 with public registry	For sale
_for-sale.www.ccc.example.	Third level without public registry	See "Note 1" below
_for-sale.51.198.in-addr.arpa.	Infrastructure TLD	See "Note 2" below
xyz._for-sale.example.	Invalid placement, not a leaf	Non-conformant

Note 1:

When the "_for-sale" leaf node name is applied to a label under a subdomain, there may not be a public domain name registry 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 formalise these rights.

Note 2:

If a "_for-sale" leaf node name were to appear under the .arpa infrastructure TLD, it might be interpreted as an offer to sell IP address space, E.164 numbers, or the like. However, such 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. An application to Special-Use Domain Names (e.g., .onion, .alt) is out of scope.

Operational Considerations

DNS Wildcards DNS wildcards interact poorly with underscored names , 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 mandatory 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 ) -- might result in misleading listings or unintended references to third-party domains.

Handling of RDATA Since this method relies on DNS TXT records, standard content rules apply as defined in . This includes the possibility of including non-ASCII data in the content value. When non-ASCII data is used, interpretation may become ambiguous. For this reason, it is RECOMMENDED that text in content values be encoded in UTF-8 , conform to the Network Unicode format , and use a subset of Unicode code points consistent with , 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 , 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 . 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. See for additional guidelines and the section for possible risks.

Currency The ABNF in 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. The use of standard fiat currencies is RECOMMENDED. When used, they MUST be represented by three-letter uppercase currency codes as specified in (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, ".").

TTLs Long TTLs increase the risk of outdated data misleading buyers into thinking the domain is still available or that advertised prices remain current. 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 .

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.

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

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 , or when the domain is DNSSEC signed but fails validation (i.e., has a bogus state).

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. 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. 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. Some URI schemes recommended in 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. 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.

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

IANA Considerations IANA has added the following entry to the "Underscored and Globally Scoped DNS Node Names" registry : Entry for the Underscored and Globally Scoped DNS Node Names Registry

RR Type	_NODE NAME	Reference
TXT	_for-sale	RFC 10023

References Normative References ISO This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. [STANDARDS-TRACK] ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as a complement of the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). A mapping from IRIs to URIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to identify resources. The approach of defining a new protocol element was chosen instead of extending or changing the definition of URIs. This was done in order to allow a clear distinction and to avoid incompatibilities with existing software. Guidelines are provided for the use and deployment of IRIs in various protocols, formats, and software components that currently deal with URIs. The Internet today is in need of a standardized form for the transmission of internationalized "text" information, paralleling the specifications for the use of ASCII that date from the early days of the ARPANET. This document specifies that format, using UTF-8 with normalization and specific line-ending sequences. [STANDARDS-TRACK] Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK] This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document discusses subsets of the Unicode character repertoire for use in protocols and data formats and specifies three subsets recommended for use in IETF specifications. Informative References This document updates the specification of the WHOIS protocol, thereby obsoleting RFC 954. The update is intended to remove the material from RFC 954 that does not have to do with the on-the-wire protocol, and is no longer applicable in today's Internet. This document does not attempt to change or update the protocol per se, or document other uses of the protocol that have come into existence since the publication of RFC 954. [STANDARDS-TRACK] This document specifies the URI (Uniform Resource Identifier) scheme "tel". The "tel" URI describes resources identified by telephone numbers. This document obsoletes RFC 2806. [STANDARDS-TRACK] This is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition is removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034. [STANDARDS-TRACK] This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] This document defines the format of Uniform Resource Identifiers (URIs) to identify resources that are reached using Internet mail. It adds better internationalization and compatibility with Internationalized Resource Identifiers (IRIs; RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368). [STANDARDS-TRACK] Full use of electronic mail throughout the world requires that (subject to other constraints) people be able to use close variations on their own names (written correctly in their own languages and scripts) as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This document is a replacement for RFC 4952; it reflects additional issues identified since that document was published. [STANDARDS-TRACK] The DNAME record provides redirection for a subtree of the domain name tree in the DNS. That is, all names that end with a particular suffix are redirected to another part of the DNS. This document obsoletes the original specification in RFC 2672 as well as updates the document on representing IPv6 addresses in DNS (RFC 3363). [STANDARDS-TRACK] This document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names. Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. Using an underscore for a prefix creates a space for constrained interoperation of resource records. Original uses of an underscore character as a domain node name prefix were specified without the benefit of an IANA registry. This produced an entirely uncoordinated set of name-creation activities, all drawing from the same namespace. A registry for these names has now been defined by RFC 8552. However, the existing specifications that use underscored naming need to be modified in order to be in line with the new registry. This document specifies those changes. The changes preserve existing software and operational practice, while adapting the specifications for those practices to the newer underscore registry model. This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. This document obsoletes RFC 7483. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 4930. [STANDARDS-TRACK] This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. This document obsoletes RFC 4931. [STANDARDS-TRACK] This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. This document obsoletes RFC 4932. [STANDARDS-TRACK] This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. This document obsoletes RFC 4933. [STANDARDS-TRACK] This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. This document obsoletes RFC 4934. [STANDARDS-TRACK]

Additional Examples

Example 1: Code Format The following example illustrates 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 : _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 implementors 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.

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 section): _for-sale IN TXT "v=FORSALE1;ftxt=<script>...</script>"

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 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 section for possible downsides.

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 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"

Example 5: Combinations The following example shows 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=EXCO-ZGVhZGJlZWYx" IN TXT "v=FORSALE1;fcod=XYZ1-MTExLTIyMi0zMzMtNDQ0"

Acknowledgements The author would like to thank , , , , , , , , , , (ISE), , , , , , , , , and for their valuable feedback.

Author's Address SIDN Labs

Meander 501 Arnhem 6825 MD Netherlands +31 26 352 5500 marco.davids@sidn.nl