Internet Engineering Task Force (IETF) M. Davids Internet-Draft SIDN Labs Intended status: Best Current Practice 28 May 2025 Expires: 29 November 2025 The '_for-sale' Underscored and Globally Scoped DNS Node Name draft-davids-forsalereg-07 Abstract This document defines an operational convention for using the reserved DNS leaf node name '_for-sale' to indicate that the parent domain name is available for purchase. This approach offers the advantage of easy deployment without affecting ongoing operations. As such, the method can be applied to a domain name that is still in full use. Note to the RFC Editor This document contains several "Notes to the RFC Editor", including this section. These should be reviewed and resolved prior to 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 29 November 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Davids Expires 29 November 2025 [Page 1] Internet-Draft forsalereg May 2025 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) 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 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. General Record Format . . . . . . . . . . . . . . . . . . 4 3.2. Content Tag Type Definitions . . . . . . . . . . . . . . 5 3.2.1. fcod . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2.2. ftxt . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2.3. furi . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Content Limitations . . . . . . . . . . . . . . . . . . . 7 3.4. RRset Limitations . . . . . . . . . . . . . . . . . . . . 8 3.5. RR type Limitations . . . . . . . . . . . . . . . . . . . 8 3.6. Wildcard Limitation . . . . . . . . . . . . . . . . . . . 8 3.7. Placement of the Leaf Node Name . . . . . . . . . . . . . 8 4. Additional Examples . . . . . . . . . . . . . . . . . . . . . 9 4.1. Example 1: Code Format . . . . . . . . . . . . . . . . . 10 4.2. Example 2: Free Text Format . . . . . . . . . . . . . . . 10 4.3. Example 3: URI Format . . . . . . . . . . . . . . . . . . 10 4.4. Example 4: Combinations . . . . . . . . . . . . . . . . . 11 5. Operational Guidelines . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 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. Davids Expires 29 November 2025 [Page 2] Internet-Draft forsalereg May 2025 Some registrars and other entities offer mediation services between domain name holders and interested parties. For domain names that are not for sale, such services may be of limited value, whereas 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. 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. 3. Conventions Davids Expires 29 November 2025 [Page 3] Internet-Draft forsalereg May 2025 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 ; 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 ; 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=" ; case sensitive lowercase fcod-value = 1*239OCTET ; must be at least 1 OCTET ftxt-value = 1*239ftxt-char ftxt-char = %x20-21 / %x23-5B / %x5D-7E ; excluding " and \ to avoid escape issues furi-value = URI ; Only http, https, mailto and tel schemes ; exactly one URI URI = See Section 3.2 for more detailed format definitions per content tag type. Davids Expires 29 November 2025 [Page 4] Internet-Draft forsalereg May 2025 Each '_for-sale' TXT record MUST NOT contain more than one tag-value pair. See Section 3.4 for additional RRset limitations. The content value provides information to interested parties as explained in Section 1. In the absence of a tag-value pair, processors MAY assume that the domain is for sale. In such cases, processors SHOULD determine how to proceed. One possible approach is to indicate that the domain is for sale and to use traditional methods, such as WHOIS or RDAP, to obtain contact information: _for-sale.example.com. IN TXT "v=FORSALE1;" If a tag-value pair is present but invalid, this constitutes a syntax error and SHOULD be treated as if it were absent. In such cases, if the version tag itself is valid, processors MAY assume that the domain is for sale. For example: _for-sale.example.com. IN TXT "v=FORSALE1;lorumipsum" _for-sale.example.com. IN TXT "v=FORSALE1;fcod=" _for-sale.example.com. IN TXT "v=FORSALE1;foo=bar" 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 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. Davids Expires 29 November 2025 [Page 5] Internet-Draft forsalereg May 2025 3.2.1. fcod This content tag is intended to contain a code that is meaningful only to processors that understand its semantics. For example, a 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 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 the redirection URLs, thereby preventing users from being sent to unintended or malicious destinations. The following example shows a base64-encoded [RFC4648] string preceded by the prefix "ACME-" as the value of the content tag: _for-sale IN TXT "v=FORSALE1;fcod=ACME-S2lscm95IHdhcyBoZXJl" 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 not required. 3.2.2. ftxt This content tag may contain human-readable text that conveys information to interested parties. For example: _for-sale IN TXT "v=FORSALE1;ftxt=price:$500,info[at]example.com" While a single visible character is the minimum, it is RECOMMENDED to provide more context. Davids Expires 29 November 2025 [Page 6] Internet-Draft forsalereg May 2025 3.2.3. furi This content tag may 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 (for example, spaces MUST be encoded as %20 in a URL). See the Security Considerations section for possible risks. 3.3. Content Limitations The '_for-sale' TXT record [RFC8553] (Section 2.1) MUST contain content deemed valid under this specification. Any text that suggests that the domain is not for sale is invalid content. If a domain name is not for sale, a '_for-sale' indicator is pointless and any existence of a valid '_for-sale' TXT record MAY therefore be regarded as an indication that the domain name is for sale. This specification does not dictate the exact use of any content values in the '_for-sale' TXT record. Parties - such as registries and registrars - 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. Since the content value in the TXT record has no strictly defined meaning, it is up to the processor of the content to decide how to handle it. See Section 5 for operational guidelines. See Section 5 for additional guidelines. Davids Expires 29 November 2025 [Page 7] Internet-Draft forsalereg May 2025 3.4. RRset Limitations This specification does not define restrictions on the number of TXT records in the RRset, but limiting it to one per content tag is RECOMMENDED. If this is not the case, the processor SHOULD determine which content to use. The RDATA [RFC9499] of each TXT record MUST consist of a single character-string [RFC1035] with a maximum length of 255 octets, in order 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" When multiple content TXT records present, the processor MAY select one or more of them. For example, a 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.4. 3.5. RR type Limitations Adding any resource record (RR) types under the '_for-sale' leaf, other than TXT (such as AAAA or HINFO), is unnecessary for the purposes of this document and therefore discouraged. 3.6. Wildcard Limitation Wildcards are only interpreted as leaf names, so _for-sale.*.example is not a valid wildcard and is non-conformant. 3.7. Placement of the Leaf Node Name The '_for-sale' leaf node name is primarily intended to indicate that a domain name is available for purchase. Davids Expires 29 November 2025 [Page 8] Internet-Draft forsalereg May 2025 For that, the leaf node name is to be placed on the top-level domain, or any domain directly below. It can also be placed at a lower level, when that level is mentioned in the Public Suffix List [PSL]. When the '_for-sale' leaf node name is placed elsewhere, the intent is ambiguous. Table 1 illustrates this: +================================+================+================+ | Name | Situation | Verdict | +================================+================+================+ | _for-sale.example. | root zone | For sale | +--------------------------------+----------------+----------------+ | _for-sale.aaa.example. | second level | For sale | +--------------------------------+----------------+----------------+ | _for-sale.acme.bbb.example. | bbb.example in | For sale | | | PSL | | +--------------------------------+----------------+----------------+ | _for-sale.www.ccc.example. | ccc.example | See note 1 | | | not in PSL | | +--------------------------------+----------------+----------------+ | _for-sale.51.198.in-addr.arpa. | infrastructure | See note 2 | | | TLD | | +--------------------------------+----------------+----------------+ | xyz._for-sale.example. | Invalid | non-conformant | | | placement | | +--------------------------------+----------------+----------------+ Table 1: Placements of TXT record Note 1: When the '_for-sale' leaf node name is placed in front of a label of a domain that is not in the PSL, it suggests that this label (and everything underneath) is for sale, and not the domain name as a whole. There may be use cases for this, but this situation is considered unusual in the context of this document. Processors MAY ignore such records. 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 Davids Expires 29 November 2025 [Page 9] Internet-Draft forsalereg May 2025 4.1. Example 1: Code Format A proprietary format, defined by a registry or registrar, without a clearly defined meaning to 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" 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=price:EU500, call for info" 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=" 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:owner@example.com" 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. Davids Expires 29 November 2025 [Page 10] Internet-Draft forsalereg May 2025 4.4. Example 4: 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=starting price:EU500" IN TXT "v=FORSALE1;fcod=ACME-ZGVhZGJlZWYx" IN TXT "v=FORSALE1;fcod=XYZ1-MTExLTIyMi0zMzMtNDQ0" 5. Operational Guidelines DNS wildcards interact poorly with underscored names. Therefore, the use of wildcards is NOT RECOMMENDED when deploying this mechanism. However, wildcards 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 helps 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, for example in cases where the use of wildcards inadvertently causes third-party property to be listed for sale. It is also RECOMMENDED that the content value be limited to visible ASCII characters, excluding the double quote (") and backslash (\). In ABNF syntax, this would be: forsale-content = 0*244recommended-char recommended-char = %x20-21 / %x23-5B / %x5D-7E Long TTLs [RFC1035] (Section 3.2.1) are discouraged as they increase the risk of outdated data misleading buyers into thinking the domain is still available. 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 mutually agree on a more strictly defined proprietary format for the content value to mitigate ambiguity. 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: Davids Expires 29 November 2025 [Page 11] Internet-Draft forsalereg May 2025 +=========+============+=============+ | RR Type | _NODE NAME | Reference | +=========+============+=============+ | TXT | _for-sale | | +---------+------------+-------------+ Table 2: Entry for the "Underscored and Globally Scoped DNS Node Names" registry 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 independently of IANA. The registry is publicly accessible at: https://forsalereg.sidnlabs.nl/ The registry entries consist of content tags as defined in Section 3.2. The initial set of entries in this registry is as follows: +==========+===========+========+===========================+ | 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 | +----------+-----------+--------+---------------------------+ Table 3: Initial set of entries in the "Content Tags" registry Future updates will be managed by the Designated Expert. Davids Expires 29 November 2025 [Page 12] Internet-Draft forsalereg May 2025 Entries are assigned only for values that have been documented in a manner consistent with the "Specification Required" registration policy defined in [RFC8126]. Newly defined content tags MUST NOT alter the semantics of existing content tags. The "status" column can have one of the following values: * active - the tag is in use in current implementations. * historic - the tag is deprecated and not expected to be used in current implementations. This registry group is not 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 owners 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. 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 for 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. 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. Davids Expires 29 November 2025 [Page 13] Internet-Draft forsalereg May 2025 9. Implementation Status The concept described in this document is in use with the .nl ccTLD registry. See for example: https://www.sidn.nl/en/whois?q=example.nl The Dutch 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. 10. Acknowledgements The author would like to thank Thijs van den Hout, Caspar Schutijser, Melvin Elderman, Paul Bakker, Ben van Hartingsveldt, Jesse Davids, Juan Stelling and the ISE Editor for their valuable feedback. 11. References 11.1. Normative References [FORSALEREG] SIDN Labs, "The '_for-sale' Underscored and Globally Scoped DNS Node Name", . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . Davids Expires 29 November 2025 [Page 14] Internet-Draft forsalereg May 2025 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, . [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, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, . [RFC8726] Farrel, A., "How Requests for IANA Action Will Be Handled on the Independent Stream", RFC 8726, DOI 10.17487/RFC8726, November 2020, . 11.2. Informative References [IANA] IANA, "Underscored and Globally Scoped DNS Node Names", . [PSL] Mozilla Foundation, "Public Suffix List", . [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, DOI 10.17487/RFC3912, September 2004, . [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, December 2004, . Davids Expires 29 November 2025 [Page 15] Internet-Draft forsalereg May 2025 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, . [RFC8553] Crocker, D., "DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names", BCP 222, RFC 8553, DOI 10.17487/RFC8553, March 2019, . [RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the Registration Data Access Protocol (RDAP)", STD 95, RFC 9083, DOI 10.17487/RFC9083, June 2021, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, March 2024, . Author's Address Marco Davids SIDN Labs Meander 501 6825 MD Arnhem Netherlands Phone: +31 26 352 5500 Email: marco.davids@sidn.nl Davids Expires 29 November 2025 [Page 16]