337 lines
15 KiB
Plaintext
337 lines
15 KiB
Plaintext
|
|
|
|
|
|
|
|
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
|