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   
    8                  The .alt Special-Use Top-Level Domain                     
   10 Abstract                                                                   
   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.                             
   16 Status of This Memo                                                        
   18    This is an Internet Standards Track document.                           
   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.               
   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.                                
   30 Copyright Notice                                                           
   32    Copyright (c) 2023 IETF Trust and the persons identified as the         
   33    document authors.  All rights reserved.                                 
   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.                                             
   45 Table of Contents                                                          
   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                                                      
   62 1.  Introduction                                                           
   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.                  
   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.     
   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>.      
   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.                 
   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.            
   91 1.1.  Terminology                                                          
   93    This document assumes familiarity with DNS terms; please see            
   94    [RFC8499].  Terminology that is specific to this document is:           
   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.       
   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.                                                   
  103    non-DNS context:  Any other (alternative) namespace.                    
  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.                               
  109    TLD:  See the definition in Section 2 of [RFC8499].                     
  111 1.2.  Requirements Terminology                                             
  113    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",     
  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.                                                
  119 2.  The .alt Namespace                                                     
  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.                           
  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.                                                              
  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.               
  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.                 
  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.                 
  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.                       
  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.       
  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.                     
  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.                                  
  184 3.  IANA Considerations                                                    
  186 3.1.  Special-Use Domain Name Registry                                     
  188    The IANA has added the .alt name to the "Special-Use Domain Name"       
  189    registry [RFC6761] with a reference to this RFC.                        
  191 3.2.  Domain Name Reservation Considerations                               
  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.                                                
  198    1.  Users might or might not recognize that names in the .alt pseudo-   
  199        TLD as special.                                                     
  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.                                             
  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.                                                        
  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.                                                          
  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.                                                          
  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.                                      
  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.                                                    
  238 4.  Privacy Considerations                                                 
  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.                    
  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.                                                         
  253 5.  Security Considerations                                                
  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.                            
  261 6.  References                                                             
  263 6.1.  Normative References                                                 
  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>.                   
  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>.                   
  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>.         
  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>.     
  282 6.2.  Informative References                                               
  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>.        
  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>.     
  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>.                   
  297 Acknowledgements                                                           
  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.                                                               
  311    This document was many years in the making, and we would like to        
  312    sincerely apologize for anyone whom we forgot to credit.                
  314    We would also like to thank Rob Wilton for serving as Responsible AD    
  315    for this document.                                                      
  317    In addition, Andrew Sullivan was an author from adoption (2015)         
  318    through version 14 (2021).                                              
  320 Authors' Addresses                                                         
  322    Warren Kumari                                                           
  323    Google                                                                  
  324    1600 Amphitheatre Parkway                                               
  325    Mountain View, CA 94043                                                 
  326    United States of America                                                
  327    Email: warren@kumari.net                                                
  330    Paul Hoffman                                                            
  331    ICANN                                                                   
  332    Email: paul.hoffman@icann.org                                           

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.