From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc9476.txt | 336 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 336 insertions(+) create mode 100644 doc/rfc/rfc9476.txt (limited to 'doc/rfc/rfc9476.txt') diff --git a/doc/rfc/rfc9476.txt b/doc/rfc/rfc9476.txt new file mode 100644 index 0000000..12279b7 --- /dev/null +++ b/doc/rfc/rfc9476.txt @@ -0,0 +1,336 @@ + + + + +Internet Engineering Task Force (IETF) W. Kumari +Request for Comments: 9476 Google +Category: Standards Track P. Hoffman +ISSN: 2070-1721 ICANN + September 2023 + + + The .alt Special-Use Top-Level Domain + +Abstract + + This document reserves a Top-Level Domain (TLD) label "alt" to be + used in non-DNS contexts. It also provides advice and guidance to + developers creating alternative namespaces. + +Status of This Memo + + This is an Internet Standards Track document. + + 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). Further information on + Internet Standards is available in 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 + https://www.rfc-editor.org/info/rfc9476. + +Copyright Notice + + Copyright (c) 2023 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) 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 + 1.1. Terminology + 1.2. Requirements Terminology + 2. The .alt Namespace + 3. IANA Considerations + 3.1. Special-Use Domain Name Registry + 3.2. Domain Name Reservation Considerations + 4. Privacy Considerations + 5. Security Considerations + 6. References + 6.1. Normative References + 6.2. Informative References + Acknowledgements + Authors' Addresses + +1. Introduction + + Many Internet protocols need to name entities. Names that look like + DNS names (a series of labels separated with dots) have become + common, even in systems that are not part of the global DNS + administered by IANA. This document reserves the top-level label + "alt" (short for "alternative") as a special-use domain name + [RFC6761]. This top-level label can be used as the final (rightmost) + label to signify that the name is not rooted in the global DNS and + that it should not be resolved using the DNS protocol. + + Throughout the rest of this document, the top-level "alt" label is + shown as ".alt" to match the common presentation form of DNS names. + + As detailed in Section 3.1, IANA has added the .alt name to the + "Special-Use Domain Name" registry. IANA sets aside names in that + registry, as described in . + + The techniques in this document are primarily intended to address + some of the issues discussed in [RFC8244], which contains additional + background on the issues with special-use domain names. + + In this document, ".alt" was chosen for the special-use domain name + instead of something like "alt.arpa" so that systems that use the + name do not have to worry that a parent of their name would be + resolved if the name leaked to the Internet. Historically, some + systems that want to use non-DNS names wanted the entire name to be + not in the DNS, and reserving ".alt" fulfills that use case. + +1.1. Terminology + + This document assumes familiarity with DNS terms; please see + [RFC8499]. Terminology that is specific to this document is: + + DNS name: Domain names that are intended to be used with DNS + resolution, either in the global DNS or in some other context. + + DNS context: The namespace anchored at the globally unique DNS root + and administered by IANA. This is the namespace or context that + "normal" DNS uses. + + non-DNS context: Any other (alternative) namespace. + + pseudo-TLD: A label that appears in a fully qualified domain name in + the position of a TLD, which is not part of the global DNS. This + term is not intended to be pejorative. + + TLD: See the definition in Section 2 of [RFC8499]. + +1.2. Requirements 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. The .alt Namespace + + This document reserves the .alt label for use as an unmanaged pseudo- + TLD namespace. The .alt label can be used in any domain name as a + pseudo-TLD to signify that this is an alternative (non-DNS) namespace + and should not be looked up in a DNS context. + + This document uses ".alt" for the pseudo-TLD in the presentation + format for the DNS, corresponding to a 0x03616c7400 suffix in DNS + wire format. The on-the-wire formats for non-DNS protocols might be + different. + + Because names beneath .alt are in an alternative namespace, they have + no significance in the regular DNS context. DNS stub and recursive + resolvers do not need to look them up in the DNS context. + + DNS resolvers that serve the DNS protocol and non-DNS protocols at + the same time might consider .alt like a DNS entry in the "Transport- + Independent Locally-Served DNS Zone Registry" that is part of IANA's + "Locally-Served DNS Zones" registry, except that .alt is always used + to denote names that are to be resolved by non-DNS protocols. Note + that this document does not request adding .alt to these registries + because .alt, by this specification, is not a DNS name. + + Note that using .alt as a pseudo-TLD does not mandate how the non-DNS + protocol will handle the name. To maximize compatibility with + existing applications, it is suggested, but not required, that non- + DNS protocols using names that end in .alt follow DNS name syntax. + If the non-DNS protocol has a wire format like the DNS wire format, + it might append the null label at the end of the name, but it also + might not. This document does not make any suggestion for how non- + DNS protocols deal with the wire format of their names. + + Groups wishing to create new alternative namespaces may create their + alternative namespace under a label that names their namespace under + the .alt pseudo-TLD. This document defines neither a registry nor a + governance model for the .alt namespace, as it is not managed by the + IETF or IANA. There is no guarantee of unambiguous mappings from + names to name resolution mechanisms. Mitigation or resolution of + collisions that occur under .alt are outside the scope of this + document and outside the IETF's remit. Users are advised to consider + the associated risks when using names under .alt. + + Regardless of the expectations above, names in the .alt pseudo-TLD + will leak outside the context in which they are valid. Decades of + experience show that such names will appear at recursive resolvers + and will thus also appear at the root servers for the global DNS. + + Sending traffic to the root servers that is known to always elicit an + NXDOMAIN response, such as queries for names ending in .alt, wastes + resources on both the resolver and the root server. Caching + resolvers performing aggressive use of DNSSEC-validated caches + (described in [RFC8198]) may mitigate this by synthesizing negative + answers from cached NSEC records for names under .alt. Similarly, + caching resolvers using QNAME minimization (described in [RFC9156]) + will cause less of this traffic to the root servers because the + negative responses will cover all names under .alt. + + Currently deployed projects and protocols that are using pseudo-TLDs + are recommended to move under the .alt pseudo-TLD, but this is not a + requirement. Rather, the .alt pseudo-TLD is being reserved so that + current and future projects of a similar nature have a designated + place to create alternative resolution namespaces that will not + conflict with the regular DNS context. + +3. IANA Considerations + +3.1. Special-Use Domain Name Registry + + The IANA has added the .alt name to the "Special-Use Domain Name" + registry [RFC6761] with a reference to this RFC. + +3.2. Domain Name Reservation Considerations + + This section exists to meet the requirements of [RFC6761]. The + questions posed in [RFC6761] were largely written assuming a DNS + resolution system, and so some of the questions are not especially + relevant or well suited. + + 1. Users might or might not recognize that names in the .alt pseudo- + TLD as special. + + 2. Application software that uses alternative namespaces in the .alt + pseudo-TLD are expected to have their own processing rules for + their own names, probably in specialized resolver APIs, + libraries, and/or application software. Application software + that is not specifically designed to use names in the .alt + pseudo-TLD are not expected to make their software recognize + these names as special. + + 3. Developers of name resolution APIs and libraries that are + specifically designed to implement resolution of an alternative + name resolution system are expected to recognize names in the + .alt pseudo-TLD as special and thus perform resolution of those + names. The exact mechanism used by the name resolution APIs and + libraries will obviously depend on the particular alternative + resolution system. Regular DNS resolution APIs and libraries are + not expected to recognize or treat names in the .alt pseudo-TLD + differently. + + 4. Caching DNS servers SHOULD NOT recognize names in the .alt + pseudo-TLD as special and SHOULD NOT perform any special handling + with them. + + 5. Authoritative DNS servers SHOULD NOT recognize names in the .alt + pseudo-TLD as special and SHOULD NOT perform any special handling + with them. + + 6. DNS server operators will treat names in the .alt pseudo-TLD as + they would names in any other TLD not in the global DNS. DNS + server operators may be aware that queries for names ending in + .alt are not DNS names and that queries for those names were + leaked into the DNS context. This information can be useful for + support or debugging purposes. + + 7. It is not possible for DNS registries/registrars to register DNS + names in the .alt pseudo-TLD as the .alt will not exist in the + global DNS root. + +4. Privacy Considerations + + This document reserves .alt to be used to indicate that a name is not + a DNS name. Unfortunately, these queries will undoubtedly leak into + the global DNS. This is a general problem with alternative + namespaces and not confined to names ending in .alt. + + For example, a value such as "example.alt" could easily cause a + privacy issue for any names in that namespace that are leaked to the + Internet. In addition, if a name ending in .alt is sufficiently + unique, long-lasting, and frequently leaks into the global DNS, then + regardless of how the name is constructed, it can act similar to a + web cookie with all the associated downsides of identification or re- + identification. + +5. Security Considerations + + Because names in the .alt pseudo-TLD are explicitly outside of the + DNS context, it is impossible to rely on any DNS-related security + considerations. Care must be taken when mapping the pseudo-TLD into + its corresponding non-DNS name resolution system in order to get + whatever security is offered by that system. + +6. References + +6.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", + RFC 6761, DOI 10.17487/RFC6761, February 2013, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8244] Lemon, T., Droms, R., and W. Kumari, "Special-Use Domain + Names Problem Statement", RFC 8244, DOI 10.17487/RFC8244, + October 2017, . + +6.2. Informative References + + [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of + DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, + July 2017, . + + [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS + Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, + January 2019, . + + [RFC9156] Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query + Name Minimisation to Improve Privacy", RFC 9156, + DOI 10.17487/RFC9156, November 2021, + . + +Acknowledgements + + We would like to thank Joe Abley, Mark Andrews, Erik Auerswald, Roy + Arends, Ray Bellis, Vittorio Bertola, Marc Blanchet, John Bond, + Stéphane Bortzmeyer, David Cake, Vint Cerf, David Conrad, Steve + Crocker, Vladimir Cunat, Brian Dickson, Ralph Droms, Robert Edmonds, + Patrik Fältström, Bernd Fix, Christian Grothoff, Olafur Gudmundsson, + Ted Hardie, Bob Harold, Wes Hardaker, Geoff Huston, Joel Jaeggli, + John C Klensin, Eliot Lear, Barry Leiba, Ted Lemon, Edward Lewis, + John Levine, George Michaelson, Ed Pascoe, Libor Peltan, Jim Reid, + Martin Schanzenbach, Ben Schwartz, Arturo Servin, Peter Thomassen, + Paul Vixie, Duane Wessels, Paul Wouters, and Suzanne Woolf for + feedback. + + This document was many years in the making, and we would like to + sincerely apologize for anyone whom we forgot to credit. + + We would also like to thank Rob Wilton for serving as Responsible AD + for this document. + + In addition, Andrew Sullivan was an author from adoption (2015) + through version 14 (2021). + +Authors' Addresses + + Warren Kumari + Google + 1600 Amphitheatre Parkway + Mountain View, CA 94043 + United States of America + Email: warren@kumari.net + + + Paul Hoffman + ICANN + Email: paul.hoffman@icann.org -- cgit v1.2.3