1 Internet Engineering Task Force (IETF) W. Kumari
2 Request for Comments: 9476 Google
3 Category: Standards Track P. Hoffman
4 ISSN: 2070-1721 ICANN
5 September 2023
6
7
8 The .alt Special-Use Top-Level Domain
9
10 Abstract
11
12 This document reserves a Top-Level Domain (TLD) label "alt" to be
13 used in non-DNS contexts. It also provides advice and guidance to
14 developers creating alternative namespaces.
15
16 Status of This Memo
17
18 This is an Internet Standards Track document.
19
20 This document is a product of the Internet Engineering Task Force
21 (IETF). It represents the consensus of the IETF community. It has
22 received public review and has been approved for publication by the
23 Internet Engineering Steering Group (IESG). Further information on
24 Internet Standards is available in Section 2 of RFC 7841.
25
26 Information about the current status of this document, any errata,
27 and how to provide feedback on it may be obtained at
28 https://www.rfc-editor.org/info/rfc9476.
29
30 Copyright Notice
31
32 Copyright (c) 2023 IETF Trust and the persons identified as the
33 document authors. All rights reserved.
34
35 This document is subject to BCP 78 and the IETF Trust's Legal
36 Provisions Relating to IETF Documents
37 (https://trustee.ietf.org/license-info) in effect on the date of
38 publication of this document. Please review these documents
39 carefully, as they describe your rights and restrictions with respect
40 to this document. Code Components extracted from this document must
41 include Revised BSD License text as described in Section 4.e of the
42 Trust Legal Provisions and are provided without warranty as described
43 in the Revised BSD License.
44
45 Table of Contents
46
47 1. Introduction
48 1.1. Terminology
49 1.2. Requirements Terminology
50 2. The .alt Namespace
51 3. IANA Considerations
52 3.1. Special-Use Domain Name Registry
53 3.2. Domain Name Reservation Considerations
54 4. Privacy Considerations
55 5. Security Considerations
56 6. References
57 6.1. Normative References
58 6.2. Informative References
59 Acknowledgements
60 Authors' Addresses
61
62 1. Introduction
63
64 Many Internet protocols need to name entities. Names that look like
65 DNS names (a series of labels separated with dots) have become
66 common, even in systems that are not part of the global DNS
67 administered by IANA. This document reserves the top-level label
68 "alt" (short for "alternative") as a special-use domain name
69 [RFC6761]. This top-level label can be used as the final (rightmost)
70 label to signify that the name is not rooted in the global DNS and
71 that it should not be resolved using the DNS protocol.
72
73 Throughout the rest of this document, the top-level "alt" label is
74 shown as ".alt" to match the common presentation form of DNS names.
75
76 As detailed in Section 3.1, IANA has added the .alt name to the
77 "Special-Use Domain Name" registry. IANA sets aside names in that
78 registry, as described in <https://www.iana.org/domains/reserved>.
79
80 The techniques in this document are primarily intended to address
81 some of the issues discussed in [RFC8244], which contains additional
82 background on the issues with special-use domain names.
83
84 In this document, ".alt" was chosen for the special-use domain name
85 instead of something like "alt.arpa" so that systems that use the
86 name do not have to worry that a parent of their name would be
87 resolved if the name leaked to the Internet. Historically, some
88 systems that want to use non-DNS names wanted the entire name to be
89 not in the DNS, and reserving ".alt" fulfills that use case.
90
91 1.1. Terminology
92
93 This document assumes familiarity with DNS terms; please see
94 [RFC8499]. Terminology that is specific to this document is:
95
96 DNS name: Domain names that are intended to be used with DNS
97 resolution, either in the global DNS or in some other context.
98
99 DNS context: The namespace anchored at the globally unique DNS root
100 and administered by IANA. This is the namespace or context that
101 "normal" DNS uses.
102
103 non-DNS context: Any other (alternative) namespace.
104
105 pseudo-TLD: A label that appears in a fully qualified domain name in
106 the position of a TLD, which is not part of the global DNS. This
107 term is not intended to be pejorative.
108
109 TLD: See the definition in Section 2 of [RFC8499].
110
111 1.2. Requirements Terminology
112
113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
115 "OPTIONAL" in this document are to be interpreted as described in
116 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
117 capitals, as shown here.
118
119 2. The .alt Namespace
120
121 This document reserves the .alt label for use as an unmanaged pseudo-
122 TLD namespace. The .alt label can be used in any domain name as a
123 pseudo-TLD to signify that this is an alternative (non-DNS) namespace
124 and should not be looked up in a DNS context.
125
126 This document uses ".alt" for the pseudo-TLD in the presentation
127 format for the DNS, corresponding to a 0x03616c7400 suffix in DNS
128 wire format. The on-the-wire formats for non-DNS protocols might be
129 different.
130
131 Because names beneath .alt are in an alternative namespace, they have
132 no significance in the regular DNS context. DNS stub and recursive
133 resolvers do not need to look them up in the DNS context.
134
135 DNS resolvers that serve the DNS protocol and non-DNS protocols at
136 the same time might consider .alt like a DNS entry in the "Transport-
137 Independent Locally-Served DNS Zone Registry" that is part of IANA's
138 "Locally-Served DNS Zones" registry, except that .alt is always used
139 to denote names that are to be resolved by non-DNS protocols. Note
140 that this document does not request adding .alt to these registries
141 because .alt, by this specification, is not a DNS name.
142
143 Note that using .alt as a pseudo-TLD does not mandate how the non-DNS
144 protocol will handle the name. To maximize compatibility with
145 existing applications, it is suggested, but not required, that non-
146 DNS protocols using names that end in .alt follow DNS name syntax.
147 If the non-DNS protocol has a wire format like the DNS wire format,
148 it might append the null label at the end of the name, but it also
149 might not. This document does not make any suggestion for how non-
150 DNS protocols deal with the wire format of their names.
151
152 Groups wishing to create new alternative namespaces may create their
153 alternative namespace under a label that names their namespace under
154 the .alt pseudo-TLD. This document defines neither a registry nor a
155 governance model for the .alt namespace, as it is not managed by the
156 IETF or IANA. There is no guarantee of unambiguous mappings from
157 names to name resolution mechanisms. Mitigation or resolution of
158 collisions that occur under .alt are outside the scope of this
159 document and outside the IETF's remit. Users are advised to consider
160 the associated risks when using names under .alt.
161
162 Regardless of the expectations above, names in the .alt pseudo-TLD
163 will leak outside the context in which they are valid. Decades of
164 experience show that such names will appear at recursive resolvers
165 and will thus also appear at the root servers for the global DNS.
166
167 Sending traffic to the root servers that is known to always elicit an
168 NXDOMAIN response, such as queries for names ending in .alt, wastes
169 resources on both the resolver and the root server. Caching
170 resolvers performing aggressive use of DNSSEC-validated caches
171 (described in [RFC8198]) may mitigate this by synthesizing negative
172 answers from cached NSEC records for names under .alt. Similarly,
173 caching resolvers using QNAME minimization (described in [RFC9156])
174 will cause less of this traffic to the root servers because the
175 negative responses will cover all names under .alt.
176
177 Currently deployed projects and protocols that are using pseudo-TLDs
178 are recommended to move under the .alt pseudo-TLD, but this is not a
179 requirement. Rather, the .alt pseudo-TLD is being reserved so that
180 current and future projects of a similar nature have a designated
181 place to create alternative resolution namespaces that will not
182 conflict with the regular DNS context.
183
184 3. IANA Considerations
185
186 3.1. Special-Use Domain Name Registry
187
188 The IANA has added the .alt name to the "Special-Use Domain Name"
189 registry [RFC6761] with a reference to this RFC.
190
191 3.2. Domain Name Reservation Considerations
192
193 This section exists to meet the requirements of [RFC6761]. The
194 questions posed in [RFC6761] were largely written assuming a DNS
195 resolution system, and so some of the questions are not especially
196 relevant or well suited.
197
198 1. Users might or might not recognize that names in the .alt pseudo-
199 TLD as special.
200
201 2. Application software that uses alternative namespaces in the .alt
202 pseudo-TLD are expected to have their own processing rules for
203 their own names, probably in specialized resolver APIs,
204 libraries, and/or application software. Application software
205 that is not specifically designed to use names in the .alt
206 pseudo-TLD are not expected to make their software recognize
207 these names as special.
208
209 3. Developers of name resolution APIs and libraries that are
210 specifically designed to implement resolution of an alternative
211 name resolution system are expected to recognize names in the
212 .alt pseudo-TLD as special and thus perform resolution of those
213 names. The exact mechanism used by the name resolution APIs and
214 libraries will obviously depend on the particular alternative
215 resolution system. Regular DNS resolution APIs and libraries are
216 not expected to recognize or treat names in the .alt pseudo-TLD
217 differently.
218
219 4. Caching DNS servers SHOULD NOT recognize names in the .alt
220 pseudo-TLD as special and SHOULD NOT perform any special handling
221 with them.
222
223 5. Authoritative DNS servers SHOULD NOT recognize names in the .alt
224 pseudo-TLD as special and SHOULD NOT perform any special handling
225 with them.
226
227 6. DNS server operators will treat names in the .alt pseudo-TLD as
228 they would names in any other TLD not in the global DNS. DNS
229 server operators may be aware that queries for names ending in
230 .alt are not DNS names and that queries for those names were
231 leaked into the DNS context. This information can be useful for
232 support or debugging purposes.
233
234 7. It is not possible for DNS registries/registrars to register DNS
235 names in the .alt pseudo-TLD as the .alt will not exist in the
236 global DNS root.
237
238 4. Privacy Considerations
239
240 This document reserves .alt to be used to indicate that a name is not
241 a DNS name. Unfortunately, these queries will undoubtedly leak into
242 the global DNS. This is a general problem with alternative
243 namespaces and not confined to names ending in .alt.
244
245 For example, a value such as "example.alt" could easily cause a
246 privacy issue for any names in that namespace that are leaked to the
247 Internet. In addition, if a name ending in .alt is sufficiently
248 unique, long-lasting, and frequently leaks into the global DNS, then
249 regardless of how the name is constructed, it can act similar to a
250 web cookie with all the associated downsides of identification or re-
251 identification.
252
253 5. Security Considerations
254
255 Because names in the .alt pseudo-TLD are explicitly outside of the
256 DNS context, it is impossible to rely on any DNS-related security
257 considerations. Care must be taken when mapping the pseudo-TLD into
258 its corresponding non-DNS name resolution system in order to get
259 whatever security is offered by that system.
260
261 6. References
262
263 6.1. Normative References
264
265 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
266 Requirement Levels", BCP 14, RFC 2119,
267 DOI 10.17487/RFC2119, March 1997,
268 <https://www.rfc-editor.org/info/rfc2119>.
269
270 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
271 RFC 6761, DOI 10.17487/RFC6761, February 2013,
272 <https://www.rfc-editor.org/info/rfc6761>.
273
274 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
275 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
276 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
277
278 [RFC8244] Lemon, T., Droms, R., and W. Kumari, "Special-Use Domain
279 Names Problem Statement", RFC 8244, DOI 10.17487/RFC8244,
280 October 2017, <https://www.rfc-editor.org/info/rfc8244>.
281
282 6.2. Informative References
283
284 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
285 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
286 July 2017, <https://www.rfc-editor.org/info/rfc8198>.
287
288 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
289 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
290 January 2019, <https://www.rfc-editor.org/info/rfc8499>.
291
292 [RFC9156] Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query
293 Name Minimisation to Improve Privacy", RFC 9156,
294 DOI 10.17487/RFC9156, November 2021,
295 <https://www.rfc-editor.org/info/rfc9156>.
296
297 Acknowledgements
298
299 We would like to thank Joe Abley, Mark Andrews, Erik Auerswald, Roy
300 Arends, Ray Bellis, Vittorio Bertola, Marc Blanchet, John Bond,
301 Stéphane Bortzmeyer, David Cake, Vint Cerf, David Conrad, Steve
302 Crocker, Vladimir Cunat, Brian Dickson, Ralph Droms, Robert Edmonds,
303 Patrik Fältström, Bernd Fix, Christian Grothoff, Olafur Gudmundsson,
304 Ted Hardie, Bob Harold, Wes Hardaker, Geoff Huston, Joel Jaeggli,
305 John C Klensin, Eliot Lear, Barry Leiba, Ted Lemon, Edward Lewis,
306 John Levine, George Michaelson, Ed Pascoe, Libor Peltan, Jim Reid,
307 Martin Schanzenbach, Ben Schwartz, Arturo Servin, Peter Thomassen,
308 Paul Vixie, Duane Wessels, Paul Wouters, and Suzanne Woolf for
309 feedback.
310
311 This document was many years in the making, and we would like to
312 sincerely apologize for anyone whom we forgot to credit.
313
314 We would also like to thank Rob Wilton for serving as Responsible AD
315 for this document.
316
317 In addition, Andrew Sullivan was an author from adoption (2015)
318 through version 14 (2021).
319
320 Authors' Addresses
321
322 Warren Kumari
323 Google
324 1600 Amphitheatre Parkway
325 Mountain View, CA 94043
326 United States of America
327 Email: warren@kumari.net
328
329
330 Paul Hoffman
331 ICANN
332 Email: paul.hoffman@icann.org
333
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.