idnits 2.17.00 (12 Aug 2021) /tmp/idnits34091/draft-ihren-dnsop-v6-name-space-fragment-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 342 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 18 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (November 2001) is 7491 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 49, but not defined == Unused Reference: 'RFC1034' is defined on line 315, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 318, but no explicit reference was found in the text == Unused Reference: 'RFC2826' is defined on line 321, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2826 -- Possible downref: Non-RFC (?) normative reference: ref. 'DNS-proxy' -- Possible downref: Non-RFC (?) normative reference: ref. 'DNS-opreq' Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Please publish this new draft as 2 draft-ihren-dnsop-v6-name-space-fragment-00.txt 4 Johan Ihren 6 Internet Draft Johan Ihren 7 draft-ihren-dnsop-v6-name-space-fragment-00.txt Autonomica 8 November 2001 9 Expires in six months 11 IPv4-to-IPv6 migration and DNS name space fragmentation 13 Status of this Memo 15 This memo provides information to the Internet community. It does 16 no specify an Internet standard of any kind. This memo is in full 17 conformance with all provisions of Section 10 of RFC2026. 19 The list of current Internet-Drafts can be accessed at 20 http://www.ietf.org/ietf/1id-abstracts.txt The list of 21 Internet-Draft Shadow Directories can be accessed at 22 http://www.ietf.org/shadow.html. 24 Abstract 26 This memo documents some problems forseen in transitioning from a 27 IPv4-only DNS hierarchy via a long period of mixture to an 28 IPv6-mostly situation sometime in the future. The mixture period is 29 expected to be very long, and hence design choices should very much 30 take this into account, rather than just regard the transition as a 31 relatively short period of pain. 33 The main problem with transition that this paper focus on is what 34 to do about the name space fragmentation that may result from 35 certain DNS data only being available over one type of transport 36 (i.e. v4 or v6) which is thereby likely unavailable to hosts that 37 can cannot utilize that transport. 39 Two orthogonal issues are identified and discussed: deployment and 40 use. The former while technically simple holds certain dangers that 41 should be avoided. The "use" (as in performing DNS lookups) is much 42 more complicated, and a roadmap for this is presented. 44 1. Terminology 46 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", 47 "RECOMMENDED", and "MAY" in this document are to be interpreted as 48 described in RFC 2119 [RFC2119]. 50 The phrase "v4 name server" indicates a name server available over 51 IPv4 transport. It does not imply anything about what DNS data is 52 served. Likewise, "v6 name server" indicates a name server 53 available over IPv6 transport. 55 2. Introduction to the problem of name space fragmentation 57 With all DNS data only available over IPv4 transport everything is 58 simple. IPv4 resolvers can use the intended mechanism of following 59 referrals from the root and down while IPv6 resolvers have to work 60 through a "translator", i.e. they have to use a second name server 61 on a so-called "dual stack" host as a "forwarder" since they cannot 62 access the DNS data directly. This is not a scalable solution. 64 With all DNS data only available over IPv6 transport everything 65 would be equally simple, with the exception of old legacy IPv4 name 66 servers having to switch to a forwarding configuration. 68 However, the second situation will not arise in a foreseeable 69 time. Instead, it is expected that the transition will be from IPv4 70 only to a mixture of IPv4 and IPv6, with DNS data of theoretically 71 three categories depending on whether it is available only over 72 IPv4 transport, only over IPv6 or both. 74 The latter is the best situation, and a major question is how to 75 ensure that it as quickly as possible becomes the norm. However, 76 while it is obvious that some DNS data will only be available over 77 v4 transport for a long time it is also obvious that it is 78 important to avoid fragmenting the name space available to IPv4 79 only hosts. I.e. during transition it is not acceptable to break 80 the name space that we presently have available for IPv4-only 81 hosts. 83 3. Consequences of deploying a "IPv6 root name server" 85 If and when a root name server that is accessible over IPv6 86 transport is deployed it will immediately become possible to change 87 IPv6-only name servers to a "native configuration", i.e. to a 88 configuration where they follow referrals directly from the root 89 (which is now accessible to them because of the v6 transport). 91 However, initially they will typically quite soon get a so-called 92 "referral" to a name server only available over IPv4 transport, and 93 this will be impossible to follow, since there is no common 94 transport available. Therefore the name it is trying to lookup will 95 not get looked up and the result is that a v6-only name server 96 cannot lookup the same names that its v4-only counterpart can. 98 There are two available methods of addressing this problem: 100 a) ignore it, i.e. don't solve the problem, but put the effort into 101 helping deployment along so that the problem will shrink over 102 time. 104 b) provide some sort of "transport bridging", i.e. create a 105 fallback mechanism that enables a name server with only one type 106 of transport to reach a name server only available over the 107 other transport via some sort of proxy service. See for instance 108 [DNS-opreq] and [DNS-proxy] for discussions. 110 Regardless of how this problem is handled it is important to 111 realize that it only concerns the fragmented name space in 112 IPv6. I.e. the IPv4 name space is not (yet) fragmented, and a more 113 important question is possibly how to keep it unfragmented. 115 4. Policy based avoidance of name space fragmentation. 117 Today there are only a few DNS "zones" on the public Internet that 118 are only available over v6 transport, and they can mostly be 119 regarded as "experimental". However, as soon as there is a root 120 name server available over v6 transport it is reasonable to expect 121 that it will become more common with v6-only zones over time. 123 This would not be a good development, since this will fragment the 124 previously unfragmented IPv4 name space and there are strong 125 reasons to find a mechanism to avoid it. 127 4.1. Requirement of IPv4 address for at least one name server. 129 To ensure that all zones remain available over IPv4 transport one 130 method would be to require that nameservers authoritative for a 131 zone as part of the zone validation process ensure that there are 132 IPv4 address records available for the name servers of any child 133 delegations within the zone). 135 I.e. the future policy would be: 137 "Every delegation point should have at least one name server 138 for the child zone reachable over IPv4 transport". 140 To ensure this the authoritative server will have to lookup the 141 address records of the name servers that are part of any 142 "delegation" points in the zone. 144 I.e. for given the domain EXAMPLE.COM with the following data 146 $ORIGIN example.com. 147 child.example.com. IN NS ns.example.com. 148 child.example.com. IN NS dns.autonomica.se. 149 ns.example.com. IN A 1.2.3.4 151 the delegation of CHILD.EXAMPLE.COM is to the two name servers 152 "ns.example.com" and "dns.autonomica.se". The first name server, 153 "ns.example.com", obviously has an IPv4 address (as shown by the 154 "glue" record on the last line). 156 However, "ns.example.com" may have additional addresses assiciated 157 with it. Also there is no way for the server loading the zone to 158 know the address(es) of "dns.autonomica.se". Therefore, to find out 159 all the publicly available addresses they have to be queried for. 161 4.2. Zone validation for non-recursive servers. 163 Non-recursive authoritative servers are name servers that run 164 without ever asking questions. A change in the zone validation 165 requirements that force them to query for the addresses of name 166 servers that are part of delegations in the zone change this, since 167 they now have to query for these addresses. 169 However, the main reason that it is important to be able to run 170 without asking questions is to avoid "caching" possibly bogus 171 answers. This need can be managed by requiring that a non recursive 172 name server throw away the looked up address information after 173 having used it for validation of the delegations in the zone. 175 4.3. Future requirement of IPv6 address for at least one name server. 177 The immediate need for clarified policies for delegation is to 178 ensure that IPv4 name space does not start to fragment. Over time, 179 however, it is reasonable to expect that it may become important to 180 add a similar requirement to IPv6 name space. 182 I.e. an even more refined policy possible at some point in the 183 future would be: 185 "Every delegation point should have at least one name server 186 for the child zone reachable over IPv4 transport (i.e. should 187 have an A record) and at least one name server reachable over 188 IPv6 transport (i.e. should have an AAAA record)". 190 4.4. Implementation issues for new zone validation requirements. 192 Exactly what action should be taken when a zone does not validate 193 is not immediately clear. Immediate alternatives include: 195 a) fail the entire zone 197 b) load the zone but remove the delegation that failed validation 199 c) load the entire zone but issue a warning message about the 200 delegation that failed validation. 202 A likely implementation will make it configurable what action to 203 take. 205 5. Overview of suggested transition method. 207 By following the steps outlined below it will be possible to 208 transition without outages or lack of service. The assumption is 209 that the site has only v4 name servers or possibly v4 name servers 210 plus v6 name server in a forwarding configuration. All DNS data is 211 on the v4 name servers. 213 1) Do not change the method of resolution on any name server. 214 I.e. v4 servers go to the root and follow referrals while v6 215 servers go to their translator/forwarder which lookup the name 216 and return the end result. 218 2) Start mirroring DNS data into v6 by providing v6 name servers 219 serving the zones. Add v6 address information to to the zones 220 and as glue at the parent zone. Note that it is important that 221 the zone should have the same contents regardless of whether it 222 is the v4 version or the v6 version. Anything else will lead to 223 confusion. 225 4) Wait for the announcement of the DNS root zone being available 226 from a v6 name server. 228 5) Ensure that the entire path from the root down to the domain in 229 question is reachable over both IPv4 and IPv6 transport. 231 When this is accomplished it it possible to begin a migration of 232 the lookup of selected services to be available over IPv6 233 (i.e. typically by adding a AAAA record for a server of some sort). 235 6. How to deploy DNS hierarchy in v6 space. 237 The main problem with changing the DNS data so that it will become 238 available over both IPv6 and IPv4 transport is one of scale. There 239 are too many name servers and too many DNS zones for any kind of 240 forced migration to be aven remotely possible. 242 The way of achieving deployment is by providing domain owner with 244 a) a reason to deploy 246 b) a method to deploy 248 c) a way of verififying the correctness of the resulting configuration 250 6.1. A reason to deploy. 252 It is important to the migration process that zones migrate to 253 become available over v6 transport (as well as v4 transport). But 254 it is difficult to actually require such deployment too early in 255 the migration process. 257 Over time, however, it will become more reasonable to add such a 258 requirement. One likely method to do this will be by updating the 259 requirements for proper zone validation as was outlined above. 261 6.2. How to deploy DNS data. 263 Assuming the owner of the DNS domain has access to both IPv4 and 264 IPv6 address space that is globally routed. The steps to take are 265 then 267 a) identify all name servers that will serve the DNS domain, with 268 their IPv4 and/or IPv6 addresses 270 b) arrange for a suitable method of zone synchronization 272 c) announce the new set of servers to the parent zone, including 273 possible new IPv6 glue 275 It is recommended that the name servers run on single stack 276 machines, i.e. machines that are only able to utilize either IPv4 277 transport or IPv6 transport, but not both. 279 A common recommendation (mostly orthogonal to IPv6 transition 280 issues) is that authoritative name servers only serve data, 281 i.e. they do not act as caching resolvers. That way, since they 282 operate in non-recursive mode, they will not have any cache, and 283 hence will not be able to give out wrongful answers based upon 284 errors in the cache. 286 Since the announced name servers are single stack, the primary 287 master from which they fetch zone data will typically have to be 288 dual stack or otherwise some other method of data transfer has to 289 be arranged. 291 7. Security Considerations 293 Much of the security of the Internet relies, often wrongly, but 294 still, on the DNS. Thus, changes to the characteristics of the DNS 295 may impact the security of Internet based services. 297 Although it will be avoided, there may be unintended consequences 298 as a result of operational deployment of RR types and protocols 299 already approved by the IETF. When or if such consequences are 300 identified, appropriate feedback will be provided to the IETF and 301 the operational community on the efficacy of said interactions. 303 8. Summary. 305 The name space fragmentation problem is identified and examined at 306 some length. 308 A solution based upon a change in the validation method of 309 delegation points is suggested. This will both help keep the v4 310 name space unfragmented and may also help speed up deployment of 311 DNS hierarchy in v6 space. 313 9. References 315 [RFC1034] Domain names - concepts and facilities. 316 P.V. Mockapetris. 318 [RFC1035] Domain names - implementation and specification. 319 P.V. Mockapetris. 321 [RFC2826] IAB Technical Comment on th Unique DNS Root 323 [DNS-proxy] draft-durand-dns-proxy-00.txt 324 Alain Durand 326 [DNS-opreq] draft-ietf-ngtrans-dns-ops-req-02.txt 327 Alain Durand 329 A. Authors' Address 331 Johan Ihren 332 Autonomica 333 Bellmansgatan 30 334 SE-118 47 Stockholm, Sweden 335 johani@autonomica.se