rfc9476xml2.original.xml   rfc9476.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<rfc category="std" consensus="true" docName="draft-ietf-dnsop-alt-tld-25" ipr="
trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?> <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<?rfc sortrefs="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category=" std" consensus="true" docName="draft-ietf-dnsop-alt-tld-25" number="9476" ipr="t rust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="tru e" sortRefs="true" version="3">
<?rfc iprnotified="no" ?> <front>
<?rfc strict="yes"?> <!-- [rfced] Please note that the title of the document has been updated as
follows:
<?rfc compact="yes" ?> Original:
The ALT Special Use Top Level Domain
<front> Current:
<!-- WK: Set long title. --> The ALT Special-Use Top-Level Domain
-->
-&gt; <title abbrev="Reserved .alt TLD">The .alt Special-Use Top-Level
<title abbrev="Reserve ALT TLD">The ALT Special Use Top Level
Domain</title> Domain</title>
<seriesInfo name="RFC" value="9476"/>
<author fullname="Warren Kumari" initials="W." surname="Kumari"> <author fullname="Warren Kumari" initials="W." surname="Kumari">
<organization>Google</organization> <organization>Google</organization>
<address> <address>
<postal> <postal>
<street>1600 Amphitheatre Parkway</street> <street>1600 Amphitheatre Parkway</street>
<city>Mountain View</city>
<city>Mountain View, CA</city> <region>CA</region>
<code>94043</code>
<code>94043</code> <country>United States of America</country>
<country>US</country>
</postal> </postal>
<email>warren@kumari.net</email> <email>warren@kumari.net</email>
</address> </address>
</author> </author>
<author fullname="Paul Hoffman" initials="P." surname="Hoffman"> <author fullname="Paul Hoffman" initials="P." surname="Hoffman">
<organization>ICANN</organization> <organization>ICANN</organization>
<address> <address>
<email>paul.hoffman@icann.org</email> <email>paul.hoffman@icann.org</email>
</address> </address>
</author> </author>
<date year="2023" month="September" />
<area>ops</area>
<workgroup>dnsop</workgroup>
<date /> <!-- [rfced] Please insert any keywords (beyond those that appear in the
title) for use on https://www.rfc-editor.org/search.
<area>template</area> -->
<workgroup>dnsop</workgroup> <keyword>special-use domain names</keyword>
<abstract> <abstract>
<t>This document reserves a TLD label, "alt" to be used in <t>This document reserves a Top-Level Domain (TLD) label "alt" to be
non-DNS contexts. It also provides advice and guidance to developers used in non-DNS contexts. It also provides advice and guidance to
developing alternative namespaces.</t> developers creating alternative namespaces.</t>
<t>[ This document is being
collaborated on in Github at &lt;https://github.com/wkumari/draft-wkumari-
dnsop-alt-tld&gt;.
The most recent version of the document, open
issues, etc should all be available here. The authors (gratefully)
accept pull requests. ]</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<t>Many Internet protocols need to name entities. Names that look <name>Introduction</name>
like DNS names (a series of labels separated with dots) have become <t>Many Internet protocols need to name entities. Names that look like
common, even in systems that are not part of the global DNS administered DNS names (a series of labels separated with dots) have become common,
by IANA. This document reserves the top-level label "alt" (short for even in systems that are not part of the global DNS administered by
"alternative") as a special-use domain name (<xref target="RFC6761"/>). Th IANA. This document reserves the top-level label "alt" (short for
is "alternative") as a special-use domain name <xref target="RFC6761"
top-level label can be used as the final (rightmost) label to signify format="default"/>. This top-level label can be used as the final
that the name is not rooted in the global DNS, and that it should not be (rightmost) label to signify that the name is not rooted in the global
resolved using the DNS protocol.</t> DNS and that it should not be resolved using the DNS protocol.</t>
<t>In <xref target="iana-6761"/>, the IANA is requested to add the .alt na
me
to the "Special-Use Domain Name" registry. IANA sets aside names in that
registry, as described in <eref target="https://www.iana.org/domains/reser
ved"/>.</t>
<t>Throughout the rest of this document, the top-level "alt" label is show
n
as ".alt" to match the common presentation form of DNS names.</t>
<t>The techniques in this document are primarily intended to address some
of the
issues discussed in <xref target="RFC8244"/>, which contains
additional background on the issues with special use domain names.</t>
<t>In this document, ".alt" was chosen for the special-use domain name ins <t>Throughout the rest of this document, the top-level "alt" label is
tead shown as ".alt" to match the common presentation form of DNS names.</t>
of something like "alt.arpa" so that systems that use the name do not have <t>As detailed in <xref target="iana-6761" format="default"/>, IANA has
to added the .alt name to the "Special-Use Domain Name" registry. IANA
worry that a parent of their name would be resolved if the name leaked to sets aside names in that registry, as described in <eref
the target="https://www.iana.org/domains/reserved" brackets="angle"/>.</t>
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 c
ase.</t>
<section title="Terminology"> <!-- [rfced] Regarding Section 1:
<t>This document assumes familiarity with DNS terms; please see a) Would you like to switch these two paragraphs so that the
<xref target="RFC8499"/>. Terminology that is specific to this document explanation of the usage of ".alt" instead of "alt" comes before the
is:</t> IANA request?
b) Would you like to use the phrase 'the top-level label "alt"'
to match how it appears in the first paragraph of Section 1?
<t><list style="symbols"> Original:
<t>DNS name: Domain names that are intended to be used with DNS In Section 3.1, the IANA is requested to add the .alt name to the
resolution, either in the global DNS or in some other context.</t> "Special-Use Domain Name" registry. IANA sets aside names in that
registry, as described in https://www.iana.org/domains/reserved.
<t>DNS context: The namespace anchored at the globally-unique DNS Throughout the rest of this document, the top-level "alt" label is
root, administered by IANA. This is the namespace or context that shown as ".alt" to match the common presentation form of DNS names.
"normal" DNS uses.</t>
<t>non-DNS context: Any other (alternative) namespace.</t> Perhaps:
Throughout the rest of this document, the top-level label "alt" is
shown as ".alt" to match the common presentation form of DNS names.
<t>pseudo-TLD: A label that appears in a fully-qualified domain As detailed in Section 3.1, IANA has added the .alt name to the
name in the position of a TLD, but which is not part of the "Special-Use Domain Name" registry. IANA sets aside names in that
global DNS. This term is not intended to be pejorative.</t> registry, as described in <https://www.iana.org/domains/reserved>.
-->
<t>TLD: See the definition in Section 2 of <xref target="RFC8499"/>. <t>The techniques in this document are primarily intended to address
</t> some of the issues discussed in <xref target="RFC8244"
</list></t> format="default"/>, which contains additional background on the issues
with special-use domain names.</t>
<t>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.</t>
<section numbered="true" toc="default">
<name>Terminology</name>
<t>This document assumes familiarity with DNS terms; please see <xref
target="RFC8499" format="default"/>. Terminology that is specific to
this document is:</t>
<dl spacing="normal" newline="false">
<dt>DNS name:</dt>
<dd>Domain names that are intended to be used with DNS resolution,
either in the global DNS or in some other context.</dd>
<dt>DNS context:</dt>
<dd>The namespace anchored at the globally unique DNS root and
administered by IANA. This is the namespace or context that "normal"
DNS uses.</dd>
<dt>non-DNS context:</dt>
<dd>Any other (alternative) namespace.</dd>
<dt>pseudo-TLD:</dt>
<dd>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.</dd>
<dt>TLD:</dt>
<dd>See the definition in <xref target="RFC8499" sectionFormat="of"
section="2"/>.</dd>
</dl>
</section> </section>
<section numbered="true" toc="default">
<section title="Requirements Terminology"> <name>Requirements Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"OPTIONAL" in this document are to be interpreted as described in BCP 14 NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, t "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
hey "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
appear in all capitals, as shown here.</t> are to be interpreted as described in BCP&nbsp;14 <xref
target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.
</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="The alt Namespace"> <name>The .alt Namespace</name>
<t>This document reserves the .alt label <t>This document reserves the .alt label
for use as an unmanaged pseudo-TLD for use as an unmanaged pseudo-TLD
namespace. The .alt label can be used in any domain name as a 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 to signify that this is an alternative (non-DNS) namespace and should
not be looked up in a DNS context.</t> not be looked up in a DNS context.</t>
<t>This document uses ".alt" for the pseudo-TLD in the presentation <t>This document uses ".alt" for the pseudo-TLD in the presentation
format for the DNS, corresponding to a 0x03616c7400 suffix in DNS wire for mat. format for the DNS, corresponding to a 0x03616c7400 suffix in DNS wire for mat.
The on-the-wire formats for non-DNS protocols might be The on-the-wire formats for non-DNS protocols might be
different.</t> different.</t>
<t>Because names beneath .alt are in an alternative namespace, they have n o <t>Because names beneath .alt are in an alternative namespace, they have n o
significance in the regular DNS context. DNS stub and recursive resolvers significance in the regular DNS context. DNS stub and recursive resolvers
do not need to look them up in the DNS context.</t> do not need to look them up in the DNS context.</t>
<t>DNS resolvers that serve the DNS protocol and non-DNS protocols at the <t>DNS resolvers that serve the DNS protocol and non-DNS protocols at the
same time might consider .alt like a DNS entry in the same time might consider .alt like a DNS entry in the
"Transport-Independent Locally-Served DNS Zone Registry" that is part of "Transport-Independent Locally-Served DNS Zone Registry" that is part of
IANA's "Locally-Served DNS Zones" registry, except that .alt is always 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 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 that this document does not request adding .alt to these registries
because .alt, by this specification, is not a DNS name.</t> because .alt, by this specification, is not a DNS name.</t>
<t>Note that using .alt as a pseudo-TLD does not mandate how the non-DNS <t>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 protocol will handle the name. To maximize compatibility with existing
applications, it is suggested, but not required, that non-DNS protocols 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 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 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 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 does not make any suggestion for how non-DNS protocols deal with the wire
format of their names.</t> format of their names.</t>
<t>Groups wishing to create new alternative namespaces may create their <t>Groups wishing to create new alternative namespaces may create their
alternative namespace under a label that names their namespace under the alternative namespace under a label that names their namespace under the
.alt pseudo-TLD. This document defines neither a registry nor governance .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. 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 There is no guarantee of unambiguous mappings from names to name
resolution mechanisms. Mitigation or resolution of collisions that occur resolution mechanisms. Mitigation or resolution of collisions that occur
under .alt are outside the scope of this document and outside the IETF's r emit. under .alt are outside the scope of this document and outside the IETF's r emit.
Users are advised to consider the associated risks when using names under .alt.</t> Users are advised to consider the associated risks when using names under .alt.</t>
<t>Regardless of the expectations above, names in the .alt pseudo-TLD will leak <t>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 th at outside the context in which they are valid. Decades of experience show th at
such names will appear at recursive resolvers, and will thus also appear a t the such names will appear at recursive resolvers and will thus also appear at the
root servers for the global DNS.</t> root servers for the global DNS.</t>
<t>Sending traffic to the root servers that is known to always elicit an <t>Sending traffic to the root servers that is known to always elicit an
NXDOMAIN response, such as queries for names ending in .alt, wastes NXDOMAIN response, such as queries for names ending in .alt, wastes
resources on both the resolver and the root server. resources on both the resolver and the root server.
Caching resolvers performing aggressive use of DNSSEC-validated caches Caching resolvers performing aggressive use of DNSSEC-validated caches
(described in <xref target="RFC8198"/>) may mitigate this by (described in <xref target="RFC8198" format="default"/>) may mitigate this by
synthesizing negative answers from cached NSEC records for names under synthesizing negative answers from cached NSEC records for names under
.alt. Similarly, caching resolvers using QNAME .alt. Similarly, caching resolvers using QNAME
minimisation (described in <xref target="RFC9156"/>) minimization (described in <xref target="RFC9156" format="default"/>)
will cause less of this traffic to the root servers because the negative will cause less of this traffic to the root servers because the negative
responses will cover all names under .alt.</t> responses will cover all names under .alt.</t>
<t>Currently deployed projects and protocols that are using pseudo-TLDs <t>Currently deployed projects and protocols that are using pseudo-TLDs
are recommended to move under the .alt pseudo-TLD, but this is not a requi rement. are recommended to move under the .alt pseudo-TLD, but this is not a requi rement.
Rather, the .alt pseudo-TLD is being reserved so that current and future Rather, the .alt pseudo-TLD is being reserved so that current and future
projects of a similar nature have a designated place to create projects of a similar nature have a designated place to create
alternative resolution namespaces that will not conflict with the alternative resolution namespaces that will not conflict with the
regular DNS context.</t> regular DNS context.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="IANA Considerations"> <name>IANA Considerations</name>
<section anchor="iana-6761" numbered="true" toc="default">
<section title="Special-Use Domain Name Registry" anchor="iana-6761"> <name>Special-Use Domain Name Registry</name>
<t>The IANA has added the .alt name to the "Special-Use
<t>The IANA is requested to add the .alt name to the "Special-Use Domain Name" registry <xref target="RFC6761" format="default"/> with a ref
Domain Name" registry (<xref target="RFC6761"/>), and reference this erence to this RFC.</t>
document.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Domain Name Reservation Considerations"> <name>Domain Name Reservation Considerations</name>
<t>This section exists to meet the requirements of <xref
<t>This section exists to meet the requirements of <xref target="RFC6761"/ target="RFC6761" format="default"/>. The questions posed in <xref
>. target="RFC6761" format="default"/> were largely written assuming a
The questions posed in RFC 6761 were largely written assuming a DNS resolu DNS resolution system, and so some of the questions are not especially
tion relevant or well suited.</t>
system, and so some of the questions are not especially relevant or well <ol type="1" spacing="normal">
suited.</t> <li>Users might or might not recognize that names in the .alt
pseudo-TLD as special.</li>
<t>1. Users might or might not recognize that names in the .alt pseudo-TLD <li>Application software that uses alternative namespaces in the .alt
as pseudo-TLD are expected to have their own processing rules for their
special.</t> own names, probably in specialized resolver APIs, libraries, and/or
application software. Application software that is not specifically
<t>2. Application software that uses alternative namespaces in the .alt designed to use names in the .alt pseudo-TLD are not expected to make
pseudo-TLD are expected to have their own processing rules for their own n their software recognize these names as special.</li>
ames, <li>Developers of name resolution APIs and libraries that are
probably in specialized resolver APIs, libraries, and/or application softw specifically designed to implement resolution of an alternative name
are. resolution system are expected to recognize names in the .alt
Application software that is not specifically designed to use names in the pseudo-TLD as special and thus perform resolution of those names. The
.alt exact mechanism used by the name resolution APIs and libraries will
pseudo-TLD are not expected to make their software recognize these names a obviously depend on the particular alternative resolution
s system. Regular DNS resolution APIs and libraries are not expected to
special.</t> recognize or treat names in the .alt pseudo-TLD differently.</li>
<li>Caching DNS servers <bcp14>SHOULD NOT</bcp14> recognize names in
<t>3. Developers of name resolution APIs and libraries that are specifical the .alt pseudo-TLD as special and <bcp14>SHOULD NOT</bcp14> perform
ly any special handling with them.</li>
designed to implement resolution of an alternative name resolution system <li>Authoritative DNS servers <bcp14>SHOULD NOT</bcp14> recognize
are names in the .alt pseudo-TLD as special and <bcp14>SHOULD NOT</bcp14>
expected to recognize names in the .alt pseudo-TLD as special and thus per perform any special handling with them.</li>
form <li>DNS server operators will treat names in the .alt pseudo-TLD as
resolution of those names. The exact mechanism used by the name resolution they would names in any other TLD not in the global DNS. DNS server
APIs operators may be aware that queries for names ending in .alt are not
and libraries will obviously depend on the particular alternative resoluti DNS names and that queries for those names were leaked into the DNS
on context. This information can be useful for support or debugging
system. Regular DNS resolution APIs and libraries are not expected to reco purposes.</li>
gnize <li>It is not possible for DNS registries/registrars to register DNS
or treat names in the .alt pseudo-TLD differently.</t> names in the .alt pseudo-TLD as the .alt will not exist in the global
DNS root.</li>
<t>4. Caching DNS servers SHOULD NOT recognize names in the .alt pseudo-TL </ol>
D as
special and SHOULD NOT perform any special handling with them.</t>
<t>5. Authoritative DNS servers SHOULD NOT recognize names in the .alt
pseudo-TLD as special and SHOULD NOT perform any special handling with
them.</t>
<t>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 quer
ies
for those names were leaked into the DNS context. This information can be
useful for support or debugging purposes.</t>
<t>7. It is not possible for DNS registries/registrars to register DNS nam
es
in the .alt pseudo-TLD as the .alt will not exist in the global DNS root.<
/t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Privacy Considerations"> <name>Privacy Considerations</name>
<t>This document reserves .alt to be used to indicate that a name is not <t>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 a DNS name. Unfortunately, these queries will undoubtedly leak into the
global DNS. This is a general problem with alternative namespaces and not global DNS. This is a general problem with alternative namespaces and not
confined to names ending in .alt.</t> confined to names ending in .alt.</t>
<t>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.
<!--[rfced] Does "the value" refer to the "name", or is it separate?
Also, should the meaning of "(re-)identification" be written out
with "and" or "or"?
<t>For example, a value such as "example.alt" could easily cause a privacy Original:
issue for any names in that namespace that are leaked to the Internet. In addition, if a name ending in .alt is sufficiently
In addition, if a name ending in .alt is sufficiently unique, long-lasting unique, long-lasting, and frequently leaks into the global DNS, then
, and regardless of how the value is constructed, that value can act
frequently leaks into the global DNS, then regardless of how the value is similar to a web cookie with all the associated downsides of
constructed, (re-)identification.
that value can act similar to a web cookie with all the associated downsid
es of
(re-)identification.</t>
</section>
<section anchor="security" title="Security Considerations">
<t>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 offere
d by that system.</t>
</section>
<section title="Acknowledgements"> Perhaps (if "the value" is the name mentioned at the start):
<t>We would like to thank Joe Abley, Mark Andrews, Erik Auerswald, Roy In addition, if a name ending in .alt is sufficiently
Arends, Ray Bellis, Vittorio Bertola, Marc Blanchet, John Bond, Stephane unique, long-lasting, and frequently leaks into the global DNS, then
Bortzmeyer, David Cake, Vint Cerf, David Conrad, Steve Crocker, Vladimir regardless of how the name is constructed, it can act similar to a
Cunat, Brian Dickson, Ralph Droms, Robert Edmonds, Patrik Faltstrom, web cookie with all the associated downsides of identification or
Bernd Fix, Christian Grothoff, Olafur Gudmundsson, Ted Hardie, Bob re-identification.
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.</t>
<t>This document was many years in the making, and we would like to In addition, if a name ending in .alt is sufficiently
sincerely apologize for anyone who we forgot to credit.</t> unique, long-lasting, and frequently leaks into the global DNS, then
<t>We would also like to thank Rob Wilton for serving as Responsible AD regardless of how the name is constructed, it can act similar to a
for this document.</t> web cookie with all the associated downsides of identification or
<t>In addition, Andrew Sullivan was an author from adoption (2015) re-identification.</t>
through version 14 (2021).</t> </section>
<section anchor="security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>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.</t>
</section> </section>
</middle>
</middle>
<back> <back>
<references title="Normative References"> <references>
<?rfc include='https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.21 <name>References</name>
19.xml'?> <references>
<name>Normative References</name>
<?rfc include='https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.67 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
61.xml'?> 119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<?rfc include='https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.81 761.xml"/>
74.xml'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<?rfc include='https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.82 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
44.xml'?> 244.xml"/>
</references> </references>
<references>
<references title="Informative References"> <name>Informative References</name>
<?rfc include='https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.81 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
98.xml'?> 198.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include='https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.84 499.xml"/>
99.xml'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
156.xml"/>
<?rfc include='https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.91 </references>
56.xml'?>
</references> </references>
<section numbered="false" toc="default">
<name>Acknowledgements</name>
<t>We would like to thank <contact fullname="Joe Abley"/>, <contact
fullname="Mark Andrews"/>, <contact fullname="Erik Auerswald"/>,
<contact fullname="Roy Arends"/>, <contact fullname="Ray Bellis"/>,
<contact fullname="Vittorio Bertola"/>, <contact fullname="Marc
Blanchet"/>, <contact fullname="John Bond"/>, <contact
fullname="Stéphane Bortzmeyer"/>, <contact fullname="David Cake"/>,
<contact fullname="Vint Cerf"/>, <contact fullname="David Conrad"/>,
<contact fullname="Steve Crocker"/>, <contact fullname="Vladimir
Cunat"/>, <contact fullname="Brian Dickson"/>, <contact fullname="Ralph
Droms"/>, <contact fullname="Robert Edmonds"/>, <contact
fullname="Patrik Fältström"/>, <contact fullname="Bernd Fix"/>, <contact
fullname="Christian Grothoff"/>, <contact fullname="Olafur
Gudmundsson"/>, <contact fullname="Ted Hardie"/>, <contact fullname="Bob
Harold"/>, <contact fullname="Wes Hardaker"/>, <contact fullname="Geoff
Huston"/>, <contact fullname="Joel Jaeggli"/>, <contact fullname="John C
Klensin"/>, <contact fullname="Eliot Lear"/>, <contact fullname="Barry
Leiba"/>, <contact fullname="Ted Lemon"/>, <contact fullname="Edward
Lewis"/>, <contact fullname="John Levine"/>, <contact fullname="George
Michaelson"/>, <contact fullname="Ed Pascoe"/>, <contact fullname="Libor
Peltan"/>, <contact fullname="Jim Reid"/>, <contact fullname="Martin
Schanzenbach"/>, <contact fullname="Ben Schwartz"/>, <contact
fullname="Arturo Servin"/>, <contact fullname="Peter Thomassen"/>,
<contact fullname="Paul Vixie"/>, <contact fullname="Duane Wessels"/>,
<contact fullname="Paul Wouters"/>, and <contact fullname="Suzanne
Woolf"/> for feedback.</t>
<t>This document was many years in the making, and we would like to
sincerely apologize for anyone who we forgot to credit.</t>
<t>We would also like to thank <contact fullname="Rob Wilton"/> for
serving as Responsible AD for this document.</t>
<t>In addition, <contact fullname="Andrew Sullivan"/> was an author from
adoption (2015) through version 14 (2021).</t>
</section>
</back>
<section title="Changes / Author Notes."> <!-- [rfced] Throughout the text, please review the variance of
<t>[RFC Editor: Please remove this section before publication ]</t> the following terms and let us know if any updates are needed.
<t>From -24 to -25:<list style="symbols">
<t>Capitalized a SHOULD NOT.</t>
</list></t>
<t>From -23 to -24:<list style="symbols">
<t>Small changes based on inputs from IESG review.</t>
</list></t>
<t>From -22 to -23:<list style="symbols">
<t>Small changes based on inputs from IETF Last Call.</t>
</list></t>
<t>From -21 to -22:<list style="symbols">
<t>Addressed issues from AD review - https://mailarchive.ietf.org/ar
ch/msg/dnsop/aIkeZUqKDZzzseCPfiIJ9J6zYXc/</t>
<t>Combined some of the acknowledgements into one paragraph.</t>
</list></t>
<t>From -20 to -21:<list style="symbols">
<t>During WGLC review, replaced the descriptive text with the requir
ements from RFC 6761 with a list.
This in turn required adding in the BCP 14 boilerplate.</t>
<t>During WGLC review, made a few more requested changes</t>
</list></t>
<t>From -19 to -20:<list style="symbols">
<t>Expanded the privacy considerations</t>
<t>Clarified benefit of using aggressive NSEC</t>
<t>Clarified that the .alt namespace is unmanaged and thus comes wit
h risks.</t>
<t>Added description of why .alt was chosen instead of alt.arpa</t>
<t>Removed 2119 language because there are no MUSTs or SHOULDs</t>
</list></t>
<t>From -18 to -19:<list style="symbols">
<t>Document was discussed at IETF115</t>
<t>Changed the intended status to Standards Track at the request of th
e responsible AD (Rob Wilton)</t>
<t>Clarified that this only deals with some of the problems from RFC 8
244</t>
<t>Removed text telling protocol designers that they should differenti
ate their names from other designers</t>
<t>Added a note that .alt names will leak out of the local context</t>
<t>Reminded resolver operators that there are already ways to reduce .
alt traffic to the root servers</t>
<t>Moved the paragraph related to 6761 to the IANA Considerations sect
ion</t>
<t>Strengthened the security considerations</t>
<t>Added references for QNAME minimization and agressive NSEC caching<
/t>
</list></t>
<t>From -16 to -18:<list style="symbols">
<t>Lots of editorial fix-ups</t>
<t>Fixed reference to RFC 8499</t>
<t>Clarified presentation format for .alt</t>
<t>Clarified that IANA will set aside the name when it goes into the 6
761 registry</t>
<t>Removed the loose registry for names under .alt</t>
<t>Added back the required discussion for RFC 6761</t>
</list></t>
<t>From -15 to -16:<list style="symbols">
<t>Many simplifications to focus the document on the technical bits
as much as possible, based on mailing list feedback.</t>
<t>Removed unused references.</t>
<t>Removed the RFC 2119 language because it is no longer used in the d
ocument.</t>
<t>Added a non-normative IANA registry.</t>
<t>Added Paul Hoffman as second author to help get the draft moving in
the DNSOP WG again.</t>
</list></t>
<t>From -14 to -15:<list style="symbols">
<t>[Pinky]: Gee, Brain. What are we going to do tonight?</t>
<t>[The Brain]: The same thing we do every 6 months, Pinky. Post a
new version of this document, with only the version number changed.</t
>
</list></t>
<t>From -13 to -14:<list style="symbols">
<t>Andrew asked to be removed as co-author, due to potential perceptio
n of CoI.</t>
<t>Erik Auerswald provided Github issues and comments re: references a
nd grammar.</t>
</list></t>
<t>From -12 to -13:<list style="symbols">
<t>Just bumping versions to prevent expiration. </t>
</list></t>
<t>From -08 to -12:<list style="symbols">
<t>Just bumping versions to prevent expiration. </t>
<t>Updated references (aggressive-nsec is now RFC 8198,
draft-ietf-dnsop-sutld-ps is now 8244).</t>
</list></t>
<t>From -07 to -08:<list style="symbols">
<t>Made it clear that this is only for non-DNS.</t>
<t>As per Interim consensus, removed the "add this to local zones"
text.</t>
<t>Added a Privacy Considerations section</t>
<t>Grammar fix -- "alternative" is more correct than "alternate",
replaced.</t>
</list></t>
<t>From -06 to -07:<list style="symbols">
<t>Rolled up the GItHub releases in to a full release.</t>
</list></t>
<t>From -07.2 to -07.3 (GitHub point release):<list>
<t>Removed 'sandbox' at Stephane's suggestion -
https://www.ietf.org/mail-archive/web/dnsop/current/msg18495.html</t>
<t>Suggested (in 4.1 bullet 3) that DNS libraries ignore these --
Bob Harold -
https://mailarchive.ietf.org/arch/msg/dnsop/a_ruPf8osSzi_hCzCqOxYLXhYo
A</t>
<t>Added some pointers to the SUTLD document.</t>
</list></t>
<t>From -07.1 to -07.2 (Github point release):<list style="symbols">
<t>Reverted the &lt;TBD&gt; string (at request of chairs).</t>
<t>Added an editors note explaining the above.</t>
<t>Removed some more background, editorializing, etc.</t>
</list></t>
<t>From -06 to -07.1
(https://github.com/wkumari/draft-wkumari-dnsop-alt-tld/tree/7988fcf06100f
7a17f21e6993b781690b5774472):<list
style="symbols">
<t>Replaced ALT with &lt;TBD&gt; at the suggestions of George.</t>
</list></t>
<t>From -05 to -06:<list style="symbols">
<t>Removed a large amount of background - we now have the (adopted)
tldr document for that.</t>
<t>Made it clear that pseudo-TLD is not intended to be
pejorative.</t>
<t>Tried to make it cleat that this is something people can choose
to use - or not.</t>
</list></t>
<t>From -04 to -05:<list style="symbols">
<t>Version bump - we are waiting in the queue for progress on SUN,
bumping this to keep it alive.</t>
</list></t>
<t>From -03 to -04:<list style="symbols">
<t>3 changes - the day, the month and the year (a bump to keep
alive).</t>
</list></t>
<t>From -02 to -03:<list style="symbols">
<t>Incorporate suggestions from Stephane and Paul Hoffman.</t>
</list></t>
<t>From -01 to -02:<list style="symbols">
<t>Merged a bunch of changes from Paul Hoffman. Thanks for sending a
git pull.</t>
</list></t>
<t>From -00 to 01:<list style="symbols">
<t>Removed the "delegated to new style AS112 servers" text -this was
legacy from the omnicient AS112 days. (Joe Abley)</t>
<t>Removed the "Advice to implemntors" section. This used to
recommend that people used a subdomain of a domain in the DNS. It
was pointed out that this breaks things badly if the domain
expires.</t>
<t>Added text about why we don't want to adminster a registry for
ALT.</t>
</list></t>
<t>From Individual-06 to DNSOP-00<list style="symbols">
<t>Nothing changed, simply renamed draft-wkumari-dnsop-alt-tld to
draft-ietf-dnsop-alt-tld</t>
</list></t>
<t>From -05 to -06<list style="symbols">
<t>Incorporated comments from a number of people, including a number
of suggestion heard at the IETF meeting in Dallas, and the DNSOP
Interim meeting in May, 2015.</t>
<t>Removed the "Let's have an (optional) IANA registry for people to
(opportinistically) register their string, if they want that option"
stuff. It was, um, optional....</t>
</list></t>
<t>From -04 to -05</t>
<t><list style="symbols">
<t>Went through and made sure that I'd captured the feedback
received.</t>
<t>Comments from Ed Lewis.</t>
<t>Filled in the "Domain Name Reservation Considerations" section of
RFC6761.</t>
<t>Removed examples from .Onion.</t>
</list></t>
<t>From -03 to -04</t>
<t><list style="symbols">
<t>Incorporated some comments from Paul Hoffman</t>
</list></t>
<t>From -02 to -03</t>
<t><list style="symbols">
<t>After discussions with chairs, made this much more generic (not
purely non-DNS), and some cleanup.</t>
</list></t>
<t>From -01 to -02</t>
<t><list style="symbols"> ALT
<t>Removed some fluffy wording, tightened up the language some.</t> "alt"
</list></t> alt
".alt"
.alt
-->
<t>From -00 to -01.</t> <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.
<t><list style="symbols"> Note that our script did not flag any words in particular, but this should
<t>Fixed the abstract.</t> still be reviewed as a best practice.
-->
<t>Recommended that folk root their non-DNS namespace under a DNS
namespace that they control (Joe Abley)</t>
</list></t>
</section>
</back>
</rfc> </rfc>
 End of changes. 60 change blocks. 
494 lines changed or deleted 271 lines changed or added

This html diff was produced by rfcdiff 1.48.