idnits 2.17.1 draft-iab-arpa-authoritative-servers-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document updates RFC3172, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3172, updated by this document, for RFC5378 checks: 2001-04-27) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 12, 2021) is 1018 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Davies 3 Internet-Draft IANA 4 Updates: 3172 (if approved) J. Arkko 5 Intended status: Informational Ericsson 6 Expires: January 13, 2022 July 12, 2021 8 Nameservers for the Address and Routing Parameter Area ("arpa") Domain 9 draft-iab-arpa-authoritative-servers-01 11 Abstract 13 This document describes revisions to operational practices to 14 separate function of the "arpa" top-level domain in the DNS from its 15 historical operation alongside the DNS root zone. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 13, 2022. 34 Copyright Notice 36 Copyright (c) 2021 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Requirements for the "arpa" zone . . . . . . . . . . . . . . 3 53 3. Transition Process . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. Dedicated nameserver hostnames . . . . . . . . . . . . . 3 55 3.2. Separation of infrastructure . . . . . . . . . . . . . . 4 56 3.3. Zone administration . . . . . . . . . . . . . . . . . . . 4 57 3.4. Conclusion of process . . . . . . . . . . . . . . . . . . 4 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 62 6.2. Informative References . . . . . . . . . . . . . . . . . 5 63 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 The "arpa" top-level domain [RFC3172] is designated as an 69 "infrastructure domain" to support techniques defined by Internet 70 standards. Zones under the "arpa" domain provide various mappings, 71 such as IP addresses to domain names and E.164 numbers to URIs. It 72 also contains special use names such as "home", which is a non-unique 73 name used in residential networks. 75 Historically, the "arpa" zone has been hosted on almost all of the 76 root nameservers, and [RFC3172] envisages the "arpa" domain to be 77 "sufficiently critical that the operational requirements for the root 78 nameservers apply to the operational requirements of the "arpa" 79 servers". To date, this has been implemented by serving the "arpa" 80 domain directly on a subset of the root server infrastructure. 82 This bundling of root nameserver and "arpa" nameserver operations has 83 entwined management of the zones' contents and their infrastructure. 84 As a result, some proposals under consideration by the IETF involving 85 the "arpa" zone have been discarded due to the risk of conflict with 86 operations associated with managing the content of the root zone, or 87 administering the root nameservers. 89 The separation described in this document resolves operational 90 impacts of synchronizing edits to the root zone and the "arpa" zone 91 by eliminating the current dependency and allowing more tailored 92 operations based on the unique requirements of each zone. 94 2. Requirements for the "arpa" zone 96 The "arpa" domain continues to play a role in critical Internet 97 operations, and this change does not propose weakening operational 98 requirements described in [RFC3172] for the domain. Future 99 operational requirements for the "arpa" domain are encouraged to 100 follow strong baseline requirements such as those documented in 101 [RFC7720]. 103 Changes to the administration of the "arpa" zone do not alter the 104 management practices of other zones delegated within the "arpa" 105 namespace. For example, "ip6.arpa" would continue to be managed in 106 accordance with [RFC5855]. 108 3. Transition Process 110 The process will dedicate new hostnames to the servers authoritative 111 for the "arpa" zone, but will initially serve the "arpa" zone from 112 the same hosts. 114 Once completed, subsequent transitional phases could include using 115 new hosts to replace or augment the existing root nameserver hosts, 116 and separation of the editing and distribution of the "arpa" zone 117 from necessarily being connected to the root zone. Any future 118 management considerations regarding how such changes may be performed 119 are beyond the scope of this document. 121 3.1. Dedicated nameserver hostnames 123 Consistent with the use of the "arpa" namespace itself to host name 124 servers for other delegations in the "arpa" zone ([RFC5855]), this 125 document specifies a new namespace of "ns.arpa", with the nameserver 126 set for the "arpa" zone to be initially labelled as follows: 128 a.ns.arpa 129 b.ns.arpa 130 c.ns.arpa 131 ... 133 Dedicated hostnames eliminate a logical dependency that requires the 134 coordinated editing of the nameservers for the "arpa" zone and the 135 root zone. This component of this transition does not require the 136 underlying hosts that provide "arpa" name service (that is, the root 137 nameservers) be altered. The "arpa" zone will initially map the new 138 hostnames to the same IP addresses that already provide service under 139 the respective hostnames within root-servers.net. 141 Because these nameservers are completely within the "arpa" zone, they 142 will require glue records in the root zone. This is consistent with 143 current practice and requires no operational changes to the root 144 zone. 146 3.2. Separation of infrastructure 148 After initially migrating the "arpa" zone to use hostnames that are 149 not shared with the root zone, the underlying name service is 150 expected to evolve such that it no longer directly aligns to a subset 151 of root nameserver instances. With no shared infrastructure between 152 the root nameservers and the "arpa" nameservers, future novel 153 applications for the "arpa" zone may be possible. 155 Any subsequent changes to the parties providing name service for the 156 zone is considered a normal management responsibility, and would be 157 performed in accordance with [RFC3172]. 159 3.3. Zone administration 161 Publication of the "arpa" zone file to the authoritative "arpa" name 162 servers is currently undertaken alongside the root zone maintenance 163 functions. Upon the separation of the "arpa" infrastructure from the 164 root nameserver infrastructure, publication of the "arpa" zone no 165 longer necessarily needs to be technically linked or inter-related to 166 the root zone publication mechanisms. 168 3.4. Conclusion of process 170 Full technical separation of operations of the "arpa" zone and root 171 zone minimally requires the following to be satisfied: 173 o The "arpa" zone no longer shares any hostnames in its NS-set with 174 the root zone; 176 o The hosts that provide authoritative name service are not the same 177 hosts as the root nameservers, do not share any IPv4 or IPv6 178 addresses with the root servers, and are sufficiently separately 179 provisioned such that any unique "arpa" zone requirements can be 180 deployed without affecting how root zone service is provided; 182 o The editorial and publication process for the "arpa" zone has any 183 common dependencies with the root zone process removed, so that 184 the "arpa" zone can be managed, edited and provisioned wholly 185 independently of the root zone. 187 Such separation is ultimately sought to allow for novel uses of the 188 "arpa" zone without the risk of inadvertantly impacting root zone and 189 root server operations. It is recognized that achieving this state 190 requires a deliberative process involving significant coordination to 191 ensure impacts are minimized. 193 4. IANA Considerations 195 The IANA shall coordinate the creation of the "ns.arpa" namespace and 196 populate it with address records that reflect the IP addresses of the 197 contemporary root servers documented within "root-servers.net" as its 198 initial state. The namespace may either be provisioned directly 199 within the "arpa" zone (as an empty non-terminal), or through 200 establishing a dedicated "ns.arpa" zone, according to operational 201 requirements. 203 The IANA will initially migrate the 12 NS records for the "arpa" zone 204 to point to their respective new entries in the "ns.arpa" domain. 206 Subsequently, the IAB and IANA will consult and coordinate with all 207 relevant parties on activity to reduce or eliminate reliance upon 208 root zone and root server infrastructure for serving the "arpa" zone. 209 Such changes will be performed in compliance with [RFC3172] and shall 210 be conducted with all due care and deliberation to mitigate potential 211 impacts on critical infrastructure. 213 5. Security Considerations 215 The security of the "arpa" zone is not necessarily impacted by any 216 aspects of these changes. Robust practices associated with 217 administering the content of the zone (including signing the zone 218 with DNSSEC) as well as its distribution will continue to be 219 necessary. 221 6. References 223 6.1. Normative References 225 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 226 Requirements for the Address and Routing Parameter Area 227 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, 228 September 2001, . 230 6.2. Informative References 232 [RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6 233 Reverse Zones", BCP 155, RFC 5855, DOI 10.17487/RFC5855, 234 May 2010, . 236 [RFC7720] Blanchet, M. and L-J. Liman, "DNS Root Name Service 237 Protocol and Deployment Requirements", BCP 40, RFC 7720, 238 DOI 10.17487/RFC7720, December 2015, 239 . 241 Acknowledgments 243 Thank you Alyssa Cooper, Michelle Cotton, Lars-Johan Liman, Wes 244 Hardaker, Ted Hardie, Paul Hoffman, Russ Housley, Oscar Robles-Garay, 245 Duane Wessels and Suzanne Woolf for providing review and feedback. 247 Authors' Addresses 249 Kim Davies 250 Internet Assigned Numbers Authority 251 PTI/ICANN 252 12025 Waterfront Drive 253 Los Angeles 90094 254 United States of America 256 Email: kim.davies@iana.org 258 Jari Arkko 259 Ericsson Research 260 02700 Kauniainen 261 Finland 263 Email: jari.arkko@ericsson.com