doc: Add RFC documents

1 files changed, 336 insertions, 0 deletions

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 <https://www.iana.org/domains/reserved>.
+
+   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,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
+              RFC 6761, DOI 10.17487/RFC6761, February 2013,
+              <https://www.rfc-editor.org/info/rfc6761>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8244]  Lemon, T., Droms, R., and W. Kumari, "Special-Use Domain
+              Names Problem Statement", RFC 8244, DOI 10.17487/RFC8244,
+              October 2017, <https://www.rfc-editor.org/info/rfc8244>.
+
+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, <https://www.rfc-editor.org/info/rfc8198>.
+
+   [RFC8499]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
+              Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
+              January 2019, <https://www.rfc-editor.org/info/rfc8499>.
+
+   [RFC9156]  Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query
+              Name Minimisation to Improve Privacy", RFC 9156,
+              DOI 10.17487/RFC9156, November 2021,
+              <https://www.rfc-editor.org/info/rfc9156>.
+
+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