idnits 2.17.1 draft-cheshire-sudn-ipv4only-dot-arpa-15.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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7050]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 20 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC7050, but the abstract doesn't seem to directly say this. It does mention RFC7050 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 4, 2019) is 1634 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) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Cheshire 3 Internet-Draft Apple Inc. 4 Updates: 7050 (if approved) D. Schinazi 5 Intended status: Standards Track Google LLC 6 Expires: May 7, 2020 November 4, 2019 8 Special Use Domain Name 'ipv4only.arpa' 9 draft-cheshire-sudn-ipv4only-dot-arpa-15 11 Abstract 13 The specification for how a client discovers its local network's 14 NAT64 prefix [RFC7050] defines the special name 'ipv4only.arpa' for 15 this purpose, but in its Domain Name Reservation Considerations 16 section that specification indicates that the name actually has no 17 particularly special properties would require special handling, and 18 does not request IANA to record the name in the Special-Use Domain 19 Names registry. 21 Consequently, despite the well articulated special purpose of the 22 name, 'ipv4only.arpa' was not recorded in the Special-Use Domain 23 Names registry as a name with special properties. 25 As a result of this omission, in cases where software needs to give 26 this name special treatment in order for it to work correctly, there 27 was no clear mandate authorizing software authors to implement that 28 special treatment. Software implementers were left with the choice 29 between not implementing the special behavior necessary for the name 30 queries to work correctly, or implementing the special behavior and 31 being accused of being noncompliant with some RFC. 33 This document describes the special treatment required, formally 34 declares the special properties of the name, and adds similar 35 declarations for the corresponding reverse mapping names. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on May 7, 2020. 54 Copyright Notice 56 Copyright (c) 2019 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 1. Introduction 71 The specification for how a client discovers its local network's 72 NAT64 prefix [RFC7050] defines the special name 'ipv4only.arpa' for 73 this purpose, but in its Domain Name Reservation Considerations 74 section that specification indicates that the name actually has no 75 particularly special properties would require special handling, and 76 does not request IANA to record the name in the Special-Use Domain 77 Names registry [SUDN]. 79 Consequently, despite the well articulated special purpose of the 80 name, 'ipv4only.arpa' was not recorded in the Special-Use Domain 81 Names registry [SUDN] as a name with special properties. 83 This omission was discussed in the Special-Use Domain Names Problem 84 Statement [RFC8244]. 86 As a result of this omission, in cases where software needs to give 87 this name special treatment in order for it to work correctly, there 88 was no clear mandate authorizing software authors to implement that 89 special treatment. Software implementers were left with the choice 90 between not implementing the special behavior necessary for the name 91 queries to work correctly, or implementing the special behavior and 92 being accused of being noncompliant with some RFC. 94 This document describes the special treatment required, formally 95 declares the special properties of the name, and adds similar 96 declarations for the corresponding reverse mapping names. 98 2. Conventions and Terminology Used in this Section 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 102 and "OPTIONAL" in this section are to be interpreted as described 103 in "Key words for use in RFCs to Indicate Requirement Levels", 104 when, and only when, they appear in all capitals, as shown here 105 [RFC2119] [RFC8174]. 107 3. Specialness of 'ipv4only.arpa' 109 The hostname 'ipv4only.arpa' is peculiar in that it was never 110 intended to be treated like a normal hostname. 112 A typical client never looks up the IPv4 address records for 113 'ipv4only.arpa', because it is already known, by specification 114 [RFC7050], to have exactly two IPv4 address records, 192.0.0.170 and 115 192.0.0.171. No client ever has to look up the name in order to 116 learn those two addresses. 118 In contrast, clients often look up the IPv6 AAAA address records for 119 'ipv4only.arpa', which is contrary to general DNS expectations, given 120 that it is already known, by specification [RFC7050], that 121 'ipv4only.arpa' is an IPv4-only name, which has no IPv6 AAAA address 122 records. And yet, clients expect to receive, and do in fact receive, 123 positive answers for these IPv6 AAAA address records that apparently 124 should not exist. 126 This is clearly not a typical DNS name. In normal operation, clients 127 never query for the two records that do in fact exist; instead 128 clients query for records that are known to not exist, and then get 129 positive answers to those abnormal queries. Clients are using DNS to 130 perform queries for this name, but they are certainly not using DNS 131 to learn legitimate answers from the name's legitimate authoritative 132 server. Instead, the DNS protocol has, in effect, been co-opted as 133 an impromptu client-to-middlebox communication protocol, to 134 communicate with the NAT64/DNS64 [RFC6146] [RFC6147] gateway, if 135 present, and request that it disclose the prefix it is using for IPv6 136 address synthesis. 138 This use of specially-crafted DNS queries as an impromptu client-to- 139 middlebox communication protocol has a number of specific 140 consequences, outlined below, which client software needs to take 141 into account if the queries are to produce the desired results, 142 particularly when used on a multi-homed host, or when a VPN tunnel is 143 in use. The name 'ipv4only.arpa' is most definitely a special name, 144 and needs to be listed in IANA's registry along with other DNS names 145 that have special uses [SUDN]. 147 4. Consequences of 'ipv4only.arpa' not being declared special 149 As a result of the original specification [RFC7050] not formally 150 declaring 'ipv4only.arpa' to have special properties, there was no 151 clear mandate for DNS software to treat this name specially. In 152 particular, this lack of mandate for special treatment is relevant 153 (a) to the name resolution APIs and libraries on client devices, and 154 (b) to DNS64 [RFC6147] implementations. These two aspects are 155 discussed in more detail below. 157 4.1. Consequences for Name Resolution APIs and Libraries 159 A serious problem can occur with NAT64/DNS64 when a device is 160 configured to use a recursive resolver other than the one it learned 161 from the network. 163 Typically a device joining a NAT64 network will learn the recursive 164 resolver recommended for that network either via IPv6 Router 165 Advertisement Options for DNS Configuration [RFC8106] or via DNS 166 Configuration options for DHCPv6 [RFC3646]. On a NAT64 network it is 167 essential that the client use the DNS64 recursive resolver 168 recommended for that network, since only that recursive resolver can 169 be relied upon to know the appropriate prefix(es) to use for 170 synthesizing IPv6 addresses that will be acceptable to the NAT64 171 gateway. 173 However, it is becoming increasingly common for users to manually 174 override their default DNS configuration because they wish to use 175 some other public recursive resolver on the Internet, which may offer 176 better speed, better reliability, or better privacy than the local 177 network's default recursive resolver. At the time of writing, 178 examples of widely known public recursive resolver services include 179 1.1.1.1, 8.8.8.8, and 9.9.9.9. 181 Another common scenario is the use of corporate VPN client software. 182 The local network's recursive resolver will typically be unable to 183 provide answers for the company's private internal host names, so VPN 184 client software overrides the local network's default configuration, 185 to divert some or all DNS requests to the company's own private 186 internal recursive resolver, reached through the VPN tunnel. As with 187 the case described above of public recursive resolver services, the 188 company's private internal recursive resolver cannot be expected to 189 be able to synthesize IPv6 addresses correctly for use with the local 190 network's NAT64 gateway, because the company's private internal 191 recursive resolver is unlikely to be aware of the NAT64 prefix in use 192 on the NAT64 network to which the client device is currently 193 attached. It is clear that a single recursive resolver cannot meet 194 both needs. The local network's recursive resolver cannot give 195 answers for some company's private internal host names, and some 196 company's private internal recursive resolver cannot give correctly 197 synthesized IPv6 addresses suitable for the local network's NAT64 198 gateway. 200 Note that multiple NAT64 services may be simultaneously available to 201 a client. For example, the local network may provide NAT64 service 202 (to allow a IPv6-only client device to access IPv4-only Internet 203 services), while at the same time the corporate VPN may also provide 204 NAT64 service (to allow a client connecting via an IPv6-only VPN 205 tunnel to access IPv4-only corporate services). The NAT64 address 206 synthesis prefixes for the two NAT64 services may be different. In 207 this case is is essential that the NAT64 address synthesis prefix 208 used on the local network be the prefix learned from the local 209 network's recursive resolver, and the NAT64 address synthesis prefix 210 used on the VPN tunnel be the prefix learned from the VPN tunnel's 211 recursive resolver. 213 The conflict here arises because DNS is being used for two unrelated 214 purposes. The first purpose is retrieving data from a (nominally) 215 global database -- generally retrieving the IP address(es) associated 216 with a hostname. The second purpose is using the DNS protocol as a 217 middlebox communication protocol, to interrogate the local network 218 infrastructure to discover the IPv6 prefix(es) in use by the local 219 NAT64 gateway for address synthesis. 221 4.2. Consequences for DNS64 Implementations 223 As a result of there being no mandate for special treatment, queries 224 for 'ipv4only.arpa' had to be handled normally, resulting in DNS64 225 gateways performing unnecessary IPv6 address record queries (DNS 226 qtype "AAAA", always returning negative responses) and IPv4 address 227 record queries (DNS qtype "A", always returning the same positive 228 responses) to the authoritative 'arpa' name servers. 230 Having DNS64 gateways around the world issue these queries generated 231 additional load on the authoritative 'arpa' name servers, which was 232 redundant when the name 'ipv4only.arpa' is defined, by Internet 233 Standard, to have exactly two IPv4 address records, 192.0.0.170 and 234 192.0.0.171, and no other IPv4 or IPv6 address records. 236 Also, at times, for reasons that remain unclear, the authoritative 237 'arpa' name servers have been observed to be slow or unresponsive. 238 The failures of these 'ipv4only.arpa' queries result in unnecessary 239 failures of the DNS64 gateways and of the client devices that depend 240 on them for DNS64 [RFC6147] address synthesis. 242 Even when the authoritative 'arpa' name servers are operating 243 correctly, having to perform an unnecessary query to obtain an answer 244 that is already known in advance can add precious milliseconds of 245 delay, affecting user experience on the client devices waiting for 246 those synthesized replies. 248 5. Remedies 250 This document leverages operational experience to update the Domain 251 Name Reservation Considerations [RFC6761] section of the earlier 252 specification [RFC7050] with one that more accurately lists the 253 actual special properties of the name 'ipv4only.arpa', so that 254 software can legitimately implement the correct behavior necessary 255 for better performance, better reliability, and correct operation. 257 These changes affect two bodies of software, (a) the name resolution 258 APIs and libraries on client devices, and (b) DNS64 implementations. 260 The new special rules specified in this document for name resolution 261 APIs and libraries state how they should select which recursive 262 resolver to query to learn the IPv6 address synthesis prefix in use 263 on a particular physical or virtual interface. Specifically: When 264 querying for the name 'ipv4only.arpa', name resolution APIs and 265 libraries should use the recursive resolver recommended by the 266 network for the interface in question, rather than a recursive 267 resolver configured manually, a recursive resolver configured by VPN 268 software, or a full-service recursive resolver running on the local 269 host. 271 The new special rules specified in this document for DNS64 272 implementations recommend that they avoid performing run-time network 273 queries for values that are known to be fixed by specification. 275 A useful property of the way NAT64 Prefix Discovery [RFC7050] was 276 originally specified was that it allowed for incremental deployment. 277 Even if existing DNS64 gateways, that were unaware of the special 278 'ipv4only.arpa' name, were already deployed, once IANA created the 279 appropriate 'ipv4only.arpa' records, clients could begin to use the 280 new facility immediately. Clients could send their special queries 281 for 'ipv4only.arpa' to an ipv4only-unaware DNS64 gateway, and (after 282 a query to IANA's servers) the DNS64 gateway would then generate the 283 correct synthesized response. 285 While this was a useful transition strategy to enable rapid adoption, 286 it is not the ideal end situation. For better performance, better 287 reliability, and lower load in IANA's servers, it is preferable for 288 DNS64 gateways to be aware of the special 'ipv4only.arpa' name so 289 that they can avoid issuing unnecessary queries. Network operators 290 who wish to provide reliable, high performance service to their 291 customers are strongly motivated to prefer DNS64 gateways that 292 recognize the special 'ipv4only.arpa' name and apply the appropriate 293 optimizations. 295 6. Security Considerations 297 One of the known concerns with DNS64 is that it conflicts with 298 DNSSEC. If DNSSEC is used to assert cryptographically that a name 299 has no IPv6 AAAA records, then this interferes with using DNS64 300 address synthesis to assert that those nonexistent IPv6 AAAA records 301 do exist. 303 Section 3 of the DNS64 specification [RFC6147] discusses this: 305 ... DNS64 receives a query with the DO bit set and 306 the CD bit set. In this case, the DNS64 is supposed 307 to pass on all the data it gets to the query initiator. 308 This case will not work with DNS64, unless the 309 validating resolver is prepared to do DNS64 itself. 311 The NAT64 Prefix Discovery specification [RFC7050] provides the 312 mechanism for the query initiator to learn the NAT64 prefix so that 313 it can do its own validation and DNS64 synthesis as described above. 314 With this mechanism the client can (i) interrogate the local NAT64/ 315 DNS64 gateway with an 'ipv4only.arpa' query to learn the IPv6 address 316 synthesis prefix, (ii) query for the (signed) IPv4 address records 317 itself, and validate the response, and then (iii) perform its own 318 IPv6 address synthesis locally, combining the IPv6 address synthesis 319 prefix learned from the local NAT64/DNS64 gateway with the validated 320 DNSSEC-signed data learned from the global Domain Name System. 322 It is conceivable that over time, if DNSSEC adoption continues to 323 grow, the majority of clients could move to this validate-and- 324 synthesize-locally model, which reduces the DNS64 machinery to the 325 vestigial role of simply responding to the 'ipv4only.arpa' query to 326 report the local IPv6 address synthesis prefix. In no case does the 327 client care what answer(s) the authoritative 'arpa' name servers 328 might give for that query. The 'ipv4only.arpa' query is being used 329 purely as a local client-to-middlebox communication message. 331 This approach is even more attractive if it does not create an 332 additional dependency on the authoritative 'arpa' name servers to 333 answer a query that is unnecessary because the NAT64/DNS64 gateway 334 already knows the answer before it even issues the query. Avoiding 335 this unnecessary query improves performance and reliability for the 336 client, and reduces unnecessary load for the authoritative 'arpa' 337 name servers. 339 Hard-coding the known answers for 'ipv4only.arpa' IPv4 address record 340 queries (DNS qtype "A") in recursive resolvers also reduces the risk 341 of malicious devices intercepting those queries and returning 342 incorrect answers. Because the 'ipv4only.arpa' zone has to be an 343 insecure delegation (see below) DNSSEC cannot be used to protect 344 these answers from tampering by malicious devices on the path. 346 With respect to the question of whether 'ipv4only.arpa' should be a 347 secure or insecure delegation, we need to consider two paths of 348 information flow through the network: The path from the server 349 authoritative for 'ipv4only.arpa' to the DNS64 recursive resolver, 350 and the path from the DNS64 recursive resolver to the ultimate 351 client. 353 The path from the authoritative server to the DNS64 recursive 354 resolver (queries for IPv4 address records) need not be protected by 355 DNSSEC, because the DNS64 recursive resolver already knows, by 356 specification, what the answers are. In principle, if this were a 357 secure delegation, and 'ipv4only.arpa' were a signed zone, then the 358 path from the authoritative server to the DNS64 recursive resolver 359 would still work, but DNSSEC is not necessary here. Run-time 360 cryptographic signatures are not needed to verify compile-time 361 constants. 363 The path from the DNS64 recursive resolver to the ultimate client 364 (queries for IPv6 address records) *cannot* be protected by DNSSEC, 365 because the DNS64 recursive resolver is synthesizing IPv6 address 366 answers, and does not possess the secret key required to sign those 367 answers. 369 Consequently, the 'ipv4only.arpa' zone MUST be an insecure 370 delegation, to give NAT64/DNS64 gateways the freedom to synthesize 371 answers to those queries at will, without the answers being rejected 372 by DNSSEC-capable resolvers. DNSSEC-capable resolvers that follow 373 this specification MUST NOT attempt to validate answers received in 374 response to queries for the IPv6 AAAA address records for 375 'ipv4only.arpa'. 377 The original NAT64 Prefix Discovery specification [RFC7050] stated, 378 incorrectly: 380 A signed "ipv4only.arpa." allows validating DNS64 servers 381 (see [RFC6147] Section 3, Case 5, for example) to detect 382 malicious AAAA resource records. Therefore, the zone 383 serving the well-known name has to be protected with DNSSEC. 385 This document updates the previous specification [RFC7050] to correct 386 that error. The 'ipv4only.arpa' zone MUST be an insecure delegation. 388 7. IANA Considerations 390 [Once published] IANA has created an insecure delegation for 391 'ipv4only.arpa' to allow DNS64 recursive resolvers to create 392 synthesized AAAA answers within that zone. 394 IANA has recorded the following names in the 395 Special-Use Domain Names registry [SUDN]: 397 ipv4only.arpa. 398 170.0.0.192.in-addr.arpa. 399 171.0.0.192.in-addr.arpa. 401 IANA has recorded the following IPv4 addresses in the 402 IPv4 Special-Purpose Address Registry [SUv4]: 404 192.0.0.170 405 192.0.0.171 407 8. Domain Name Reservation Considerations 409 8.1. Special Use Domain Name 'ipv4only.arpa' 411 The name 'ipv4only.arpa' is defined, by Internet Standard, to have 412 two IPv4 address records with rdata 192.0.0.170 and 192.0.0.171. 414 When queried via a DNS64 [RFC6147] recursive resolver, the name 415 'ipv4only.arpa' is also defined to have IPv6 AAAA records, with rdata 416 synthesized from a combination of the NAT64 IPv6 prefix(es) and the 417 IPv4 addresses 192.0.0.170 and 192.0.0.171. This can return more 418 than one pair of IPv6 addresses if there are multiple NAT64 prefixes. 420 The name 'ipv4only.arpa' has no other IPv4 or IPv6 address records. 421 There are no subdomains of 'ipv4only.arpa'. All names falling below 422 'ipv4only.arpa' are defined to be nonexistent (NXDOMAIN). 424 The name 'ipv4only.arpa' is special to 425 (a) client software wishing to perform DNS64 address synthesis, 426 (b) APIs responsible for retrieving the correct information, and 427 (c) the DNS64 recursive resolver responding to such requests. 428 These three considerations are listed in items 2, 3 and 4 below: 430 1. Normal users should never have reason to encounter the 431 'ipv4only.arpa' domain name. If they do, they should expect 432 queries for 'ipv4only.arpa' to result in the answers required by 433 the specification [RFC7050]. Normal users have no need to know 434 that 'ipv4only.arpa' is special. 436 2. Application software may explicitly use the name 'ipv4only.arpa' 437 for NAT64/DNS64 address synthesis, and expect to get the answers 438 required by the specification [RFC7050]. If application software 439 encounters the name 'ipv4only.arpa' in the normal course of 440 handling user input, the application software should resolve that 441 name as usual and need not treat it in any special way. 443 3. Name resolution APIs and libraries MUST recognize 'ipv4only.arpa' 444 as special and MUST give it special treatment. 446 Learning a network's NAT64 prefix is by its nature an interface- 447 specific operation, and the special DNS query used to learn this 448 interface-specific NAT64 prefix MUST be sent to the DNS recursive 449 resolver address(es) the client learned via the configuration 450 machinery for that specific client interface. One implication of 451 this is that, on any host with multiple physical interfaces 452 (e.g., cellular data and Wi-Fi) and/or multiple virtual 453 interfaces (e.g., VPN tunnels), for a client to learn the NAT64 454 prefix in use on a particular interface, the DNS name resolution 455 APIs used to look up the IPv6 addresses for 'ipv4only.arpa' MUST 456 include a parameter for the client to specify on which interface 457 to perform this query. The NAT64 prefix is a per-interface 458 property, not a per-device property. 460 Regardless of any manual client DNS configuration, DNS overrides 461 configured by VPN client software, or any other mechanisms that 462 influence the choice of the client's recursive resolver 463 address(es) (including client devices that run their own local 464 recursive resolver and use the loopback address as their 465 configured recursive resolver address) all queries for 466 'ipv4only.arpa' and any subdomains of that name MUST be sent to 467 the recursive resolver learned from the network interface in 468 question via IPv6 Router Advertisement Options for DNS 469 Configuration [RFC8106], DNS Configuration options for DHCPv6 470 [RFC3646], or other configuration mechanisms. Because DNS 471 queries for 'ipv4only.arpa' are actually a special middlebox 472 communication protocol, it is essential that they go to the 473 correct middlebox for the interface in question, and failure to 474 honor this requirement would cause failure of the NAT64 Prefix 475 Discovery mechanism [RFC7050]. 477 DNSSEC-capable resolvers MUST NOT attempt to validate answers 478 received in response to queries for the IPv6 AAAA address records 479 for 'ipv4only.arpa', since, by definition, any such answers are 480 generated by the local network's NAT64/DNS64 gateway, not the 481 authoritative server responsible for that name. 483 4. For the purposes of this section, recursive resolvers fall into 484 three categories. The first category is *forwarding* recursive 485 resolvers, as commonly implemented in residential home gateways. 486 The second category is *iterative* recursive resolvers, as 487 commonly deployed by ISPs. The third category is DNS64 recursive 488 resolvers, whose purpose is to synthesize IPv6 address records. 490 Forwarding recursive resolvers SHOULD NOT recognize 491 'ipv4only.arpa' as special or give that name, or subdomains of 492 that name, any special treatment. The rationale for this is that 493 a forwarding recursive resolver, such as built in to a 494 residential home gateway, may itself be downstream of a DNS64 495 recursive resolver. Passing through the 'ipv4only.arpa' queries 496 to the upstream DNS64 recursive resolver will allow the correct 497 NAT64 prefix to be discovered. 499 Iterative recursive resolvers complying with this specification 500 MUST recognize 'ipv4only.arpa' as special, and MUST be configured 501 to behave for these names either: (a) like a forwarding recursive 502 resolver as described above (forwarding these queries to a 503 configured upstream resolver), or (b) like a DNS64 recursive 504 resolver as described below. 506 Since the authoritative name servers for 'ipv4only.arpa' cannot 507 be expected to know the local network's NAT64 address synthesis 508 prefix, all DNS64 recursive resolvers MUST recognize 509 'ipv4only.arpa' (and all of its subdomains) as special, and MUST 510 NOT attempt to look up NS records for 'ipv4only.arpa', or 511 otherwise query authoritative name servers in an attempt to 512 resolve this name. Instead, DNS64 recursive resolvers MUST act 513 as authoritative for this zone, by generating immediate responses 514 for all queries for 'ipv4only.arpa' (and any subdomain of 515 'ipv4only.arpa'), with the one exception of queries for the DS 516 record. Queries for the DS record are resolved the usual way to 517 allow a client to securely verify that the 'ipv4only.arpa' zone 518 has an insecure delegation. Note that exception is not expected 519 to received widspread usage, since any client compliant with this 520 specification already knows that 'ipv4only.arpa' is an insecure 521 delegation and will not attempt DNSSEC validation for this name. 523 DNS64 recursive resolvers MUST generate the 192.0.0.170 and 524 192.0.0.171 responses for IPv4 address queries (DNS qtype "A"), 525 the appropriate synthesized IPv6 address record responses for 526 IPv6 address queries (DNS qtype "AAAA"), and a negative 527 ("no error no answer") response for all other query types. 529 For all subdomains of 'ipv4only.arpa', DNS64 recursive resolvers 530 MUST generate immediate NXDOMAIN responses. All names falling 531 below 'ipv4only.arpa' are defined to be nonexistent. 533 An example configuration for BIND 9 showing how to achieve the 534 desired result is given in Appendix A. 536 Note that this is *not* a locally served zone in the usual sense 537 of that term [RFC6303] because this rule applies *only* to DNS64 538 recursive resolvers, not to forwarding DNS recursive resolvers. 540 5. Authoritative name server software need not recognize 541 'ipv4only.arpa' as special or handle it in any special way. 543 6. Generally speaking, operators of authoritative name servers need 544 not know anything about the name 'ipv4only.arpa', just as they do 545 not need to know anything about any other names they are not 546 responsible for. Only the administrators of the 'arpa' namespace 547 need to be aware of this name's purpose and how it should be 548 configured. In particular, 'ipv4only.arpa' MUST have the 549 required records, and MUST be an insecure delegation, to allow 550 DNS64 recursive resolvers to create synthesized AAAA answers 551 within that zone. Making the 'ipv4only.arpa' zone a secure 552 delegation would make it impossible for DNS64 recursive resolvers 553 to create synthesized AAAA answers that won't fail DNSSEC 554 validation, thereby defeating the entire purpose of the 555 'ipv4only.arpa' name. 557 7. DNS Registries/Registrars need not know anything about the name 558 'ipv4only.arpa', just as they do not need to know anything about 559 any other name they are not responsible for. 561 8.2. Names '170.0.0.192.in-addr.arpa' and '171.0.0.192.in-addr.arpa' 563 Since the IPv4 addresses 192.0.0.170 and 192.0.0.171 are defined to 564 be special, and are listed in the IPv4 Special-Purpose Address 565 Registry [SUv4], the corresponding reverse mapping names in the 566 in-addr.arpa domain are similarly special. 568 The name '170.0.0.192.in-addr.arpa' is defined, by Internet Standard, 569 to have only one DNS record, type PTR, with rdata 'ipv4only.arpa'. 571 The name '171.0.0.192.in-addr.arpa' is defined, by Internet Standard, 572 to have only one DNS record, type PTR, with rdata 'ipv4only.arpa'. 574 There are no subdomains of '170.0.0.192.in-addr.arpa' or 575 '171.0.0.192.in-addr.arpa'. All names falling below these names are 576 defined to be nonexistent (NXDOMAIN). 578 Practically speaking these two names are rarely used, but to the 579 extent that they may be, they are special only to resolver APIs and 580 libraries, as described in item 3 below: 582 1. Normal users should never have reason to encounter these two 583 reverse mapping names. However, if they do, queries for these 584 reverse mapping names should return the expected answer 585 'ipv4only.arpa'. Normal users have no need to know that these 586 reverse mapping names are special. 588 2. Application software SHOULD NOT recognize these two reverse 589 mapping names as special, and SHOULD NOT treat them differently. 590 For example, if the user were to issue the Unix command 591 "host 192.0.0.170" then the "host" command should call the name 592 resolution API or library as usual and display the result that is 593 returned. 595 3. Name resolution APIs and libraries SHOULD recognize these two 596 reverse mapping names as special and generate the required 597 responses locally. For the names '170.0.0.192.in-addr.arpa' and 598 '171.0.0.192.in-addr.arpa' PTR queries yield the result 599 'ipv4only.arpa'; all other query types yield a negative 600 ("no error no answer") response. For all subdomains of these two 601 reverse mapping domains, all queries yield an NXDOMAIN response. 602 All names falling below these two reverse mapping domains are 603 defined to be nonexistent. 605 This local self-contained generation of these responses is to 606 avoid placing unnecessary load on the authoritative 607 'in-addr.arpa' name servers. 609 4. Recursive resolvers SHOULD NOT recognize these two reverse 610 mapping names as special and SHOULD NOT, by default, give them 611 any special treatment. 613 5. Authoritative name server software need not recognize these two 614 reverse mapping names as special or handle them in any special 615 way. 617 6. Generally speaking, most operators of authoritative name servers 618 need not know anything about these two reverse mapping names, 619 just as they do not need to know anything about any other names 620 they are not responsible for. Only the operators of the 621 authoritative name servers for these two reverse mapping names 622 need to be aware that these names are special, and require fixed 623 answers specified by Internet Standard. 625 7. DNS Registries/Registrars need not know anything about these two 626 reverse mapping names, just as they do not need to know anything 627 about any other name they are not responsible for. 629 8.2.1. ip6.arpa Reverse Mapping PTR Records 631 For all IPv6 addresses synthesized by a DNS64 recursive resolver, the 632 DNS64 recursive resolver is responsible for synthesizing the 633 appropriate 'ip6.arpa' reverse mapping PTR records too, if it chooses 634 to provide reverse mapping PTR records. The same applies to the 635 synthesized IPv6 addresses corresponding to the IPv4 addresses 636 192.0.0.170 and 192.0.0.171. 638 Generally a DNS64 recursive resolver synthesizes appropriate 639 'ip6.arpa' reverse mapping PTR records by extracting the embedded 640 IPv4 address from the encoded IPv6 address, performing a reverse 641 mapping PTR query for that IPv4 address, and then synthesizing a 642 corresponding 'ip6.arpa' reverse mapping PTR record containing the 643 same rdata. 645 In the case of synthesized IPv6 addresses corresponding to the IPv4 646 addresses 192.0.0.170 and 192.0.0.171, the DNS64 recursive resolver 647 does not issue reverse mapping queries for those IPv4 addresses, but 648 instead, according to rule 3 above, immediately returns the answer 649 'ipv4only.arpa'. 651 In the case of a client that uses the 'ipv4only.arpa' query to 652 discover the IPv6 prefixes in use by the local NAT64 gateway, and 653 then proceeds to perform its own address synthesis locally (which has 654 benefits such as allowing DNSSEC validation), that client MUST also 655 synthesize 'ip6.arpa' reverse mapping PTR records for those 656 discovered prefix(es), according to the rules above: When a client's 657 name resolution APIs and libraries receive a request to look up an 658 'ip6.arpa' reverse mapping PTR record for an address that falls 659 within one of the discovered NAT64 address synthesis prefixes, the 660 software extracts the embedded IPv4 address and then, for IPv4 661 addresses 192.0.0.170 and 192.0.0.171, returns the fixed answer 662 'ipv4only.arpa', and for all other IPv4 addresses performs a reverse 663 mapping PTR query for the IPv4 address, and then synthesizes a 664 corresponding 'ip6.arpa' reverse mapping PTR record containing the 665 same rdata. 667 9. Acknowledgements 669 Thanks to Jouni Korhonen, Teemu Savolainen, and Dan Wing, for 670 devising the NAT64 Prefix Discovery mechanism [RFC7050], and for 671 their feedback on this document. 673 Thanks to Geoff Huston for his feedback on this document. 675 Thanks to Erik Kline for pointing out that the in-addr.arpa names are 676 special too. 678 Thanks to Mark Andrews for pointing out the reasons why the 679 'ipv4only.arpa' zone MUST be an insecure delegation in order for the 680 NAT64 Prefix Discovery mechanism [RFC7050] to work, and many other 681 very helpful comments. 683 Thanks particularly to Lorenzo Colitti for an especially spirited 684 hallway discussion at IETF 96 in Berlin, which lead directly to 685 significant improvements in how this document presents the issues. 687 Thanks to Dave Thaler and Warren Kumari for generously helping 688 shepherd this document through the publication process. 690 10. References 692 10.1. Normative References 694 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 695 Requirement Levels", BCP 14, RFC 2119, 696 DOI 10.17487/RFC2119, March 1997, . 699 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 700 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 701 DOI 10.17487/RFC3646, December 2003, . 704 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 705 NAT64: Network Address and Protocol Translation from IPv6 706 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 707 April 2011, . 709 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 710 Beijnum, "DNS64: DNS Extensions for Network Address 711 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 712 DOI 10.17487/RFC6147, April 2011, . 715 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 716 RFC 6761, DOI 10.17487/RFC6761, February 2013, 717 . 719 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 720 the IPv6 Prefix Used for IPv6 Address Synthesis", 721 RFC 7050, DOI 10.17487/RFC7050, November 2013, 722 . 724 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 725 "IPv6 Router Advertisement Options for DNS Configuration", 726 RFC 8106, DOI 10.17487/RFC8106, March 2017, 727 . 729 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 730 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 731 May 2017, . 733 10.2. Informative References 735 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, 736 RFC 6303, DOI 10.17487/RFC6303, July 2011, 737 . 739 [RFC8244] Lemon, T., Droms, R., and W. Kumari, "Special-Use Domain 740 Names Problem Statement", RFC 8244, DOI 10.17487/RFC8244, 741 October 2017, . 743 [SUDN] "Special-Use Domain Names Registry", 744 . 747 [SUv4] "IANA IPv4 Special-Purpose Address Registry", 748 . 751 Appendix A. Example BIND 9 Configuration 753 A BIND 9 recursive resolver can be configured to act as authoritative 754 for the necessary DNS64 names as described below. 756 In /etc/named.conf the following line is added: 758 zone "ipv4only.arpa" { type master; file "ipv4only"; }; 760 The file /var/named/ipv4only is created with the following content: 762 $TTL 86400 ; Default TTL 24 hours 763 @ IN SOA nameserver.example. admin.nameserver.example. ( 764 2016052400 ; Serial 765 7200 ; Refresh ( 7200 = 2 hours) 766 3600 ; Retry ( 3600 = 1 hour) 767 15724800 ; Expire (15724800 = 6 months) 768 60 ; Minimum 769 ) 770 @ IN NS nameserver.example. 772 @ IN A 192.0.0.170 773 @ IN A 192.0.0.171 774 @ IN AAAA 64:ff9b::192.0.0.170 ; If not using Well-Known Prefix 775 @ IN AAAA 64:ff9b::192.0.0.171 ; place chosen NAT64 prefix here 777 Authors' Addresses 779 Stuart Cheshire 780 Apple Inc. 781 One Apple Park Way 782 Cupertino, California 95014 783 USA 785 Phone: +1 (408) 996-1010 786 Email: cheshire@apple.com 788 David Schinazi 789 Google LLC 790 1600 Amphitheatre Parkway 791 Mountain View, California 94043 792 USA 794 Email: dschinazi.ietf@gmail.com