idnits 2.17.1 draft-cheshire-sudn-ipv4only-dot-arpa-17.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 18 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 19, 2020) is 1491 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) -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 0 errors (**), 0 flaws (~~), 3 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: September 20, 2020 March 19, 2020 8 Special Use Domain Name 'ipv4only.arpa' 9 draft-cheshire-sudn-ipv4only-dot-arpa-17 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 that would require special handling, 18 and does not request IANA to record the name in the Special-Use 19 Domain 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 This document describes the special treatment required, formally 26 declares the special properties of the name, adds similar 27 declarations for the corresponding reverse mapping names, and updates 28 RFC7050. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 20, 2020. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Specialness of 'ipv4only.arpa' . . . . . . . . . . . . . . . 3 66 3. Consequences of 'ipv4only.arpa' not being declared special . 4 67 4. Remedies . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 7. Domain Name Reservation Considerations . . . . . . . . . . . 10 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 Appendix A. Example BIND 9 Configuration . . . . . . . . . . . . 19 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 76 1. Introduction 78 The specification for how a client discovers its local network's 79 NAT64 prefix [RFC7050] defines the special name 'ipv4only.arpa' for 80 this purpose, but in its Domain Name Reservation Considerations 81 section that specification indicates that the name actually has no 82 particularly special properties that would require special handling, 83 and does not request IANA to record the name in the Special-Use 84 Domain Names registry [SUDN]. 86 Consequently, despite the well articulated special purpose of the 87 name, 'ipv4only.arpa' was not recorded in the Special-Use Domain 88 Names registry [SUDN] as a name with special properties. 90 This omission was discussed in the Special-Use Domain Names Problem 91 Statement [RFC8244]. 93 As a result of this omission, in cases where software needs to give 94 this name special treatment in order for it to work correctly, there 95 was no clear mandate authorizing software authors to implement that 96 special treatment. Software implementers were left with the choice 97 between not implementing the special behavior necessary for the name 98 queries to work correctly, or implementing the special behavior and 99 being accused of being noncompliant with some RFC. 101 This document describes the special treatment required, formally 102 declares the special properties of the name, and adds similar 103 declarations for the corresponding reverse mapping names. 105 1.1. Conventions and Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 109 and "OPTIONAL" in this document are to be interpreted as described 110 in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 111 all capitals, as shown here. 113 2. Specialness of 'ipv4only.arpa' 115 The hostname 'ipv4only.arpa' is peculiar in that it was never 116 intended to be treated like a normal hostname. 118 A typical client never has any reason to look up the IPv4 address 119 records for 'ipv4only.arpa'. No normal user is ever trying to view a 120 web site hosted at that domain name, or trying to send email to an 121 email address at that domain name. The name 'ipv4only.arpa' is 122 already known, by IETF specification [RFC7050], to have exactly two 123 IPv4 address records, 192.0.0.170 and 192.0.0.171. No client ever 124 has to look up the name in order to learn those two addresses. 126 In contrast, clients often look up the IPv6 AAAA address records for 127 'ipv4only.arpa', which is contrary to general DNS expectations, given 128 that it is already known, by IETF specification [RFC7050], that 129 'ipv4only.arpa' is an IPv4-only name, which has no IPv6 AAAA address 130 records. And yet, clients expect to receive, and do in fact receive, 131 positive answers for these IPv6 AAAA address records that apparently 132 should not exist. 134 This odd query behaviour comes not because clients are using DNS to 135 learn legitimate answers from the name's legitimate authoritative 136 server. Instead, the DNS protocol has, in effect, been co-opted as 137 an improvised client-to-middlebox communication protocol, to look for 138 a DNS64/NAT64 [RFC6146] [RFC6147] gateway and, if one is present, to 139 request that it disclose the prefix it is using for IPv6 address 140 synthesis. 142 This use of specially crafted DNS queries as an improvised client-to- 143 middlebox communication protocol has a number of specific 144 consequences, outlined below, which client software needs to take 145 into account if the queries are to produce the desired results, 146 particularly when used on a multi-homed host, or when a VPN tunnel is 147 in use. The name 'ipv4only.arpa' is most definitely a special name, 148 and needs to be listed in IANA's registry along with other DNS names 149 that have special uses [SUDN]. 151 3. Consequences of 'ipv4only.arpa' not being declared special 153 As a result of the original specification [RFC7050] not formally 154 declaring 'ipv4only.arpa' to have special properties, there was no 155 clear mandate for DNS software to treat this name specially. In 156 particular, this lack of mandate for special treatment is relevant 157 (a) to the name resolution APIs and libraries on client devices, and 158 (b) to DNS64 [RFC6147] implementations. These two aspects are 159 discussed in more detail below. 161 3.1. Consequences for Name Resolution APIs and Libraries 163 A serious problem can occur with DNS64/NAT64 when a device is 164 configured to use a recursive resolver other than the one it learned 165 from the network. 167 A device joining a NAT64 network will learn the recursive resolver 168 recommended for that network, typically via IPv6 Router Advertisement 169 Options for DNS Configuration [RFC8106] or via DNS Configuration 170 options for DHCPv6 [RFC3646]. On a NAT64 network it is essential 171 that the client use the DNS64 recursive resolver recommended for that 172 network, since only that recursive resolver can be relied upon to 173 know the appropriate prefix(es) to use for synthesizing IPv6 174 addresses that will be acceptable to that NAT64 gateway. 176 However, it is becoming increasingly common for users to manually 177 override their default DNS configuration because they wish to use 178 some other public recursive resolver on the Internet, which may offer 179 better speed, better reliability, or better privacy than the local 180 network's default recursive resolver. At the time of writing, 181 examples of widely known public recursive resolver services include 182 Cloudflare Public DNS [DNS1], Google Public DNS [DNS8], and Quad9 183 [DNS9]. 185 Another common scenario is the use of corporate or personal VPN 186 client software. Both for privacy reasons, and also because the 187 local network's recursive resolver will typically be unable to 188 provide answers for the company's private internal host names, so VPN 189 client software overrides the local network's default configuration, 190 to divert some or all DNS requests to the company's own private 191 internal recursive resolver, reached through the VPN tunnel. As with 192 the case described above of public recursive resolver services, the 193 company's private internal recursive resolver cannot be expected to 194 be able to synthesize IPv6 addresses correctly for use with the local 195 network's NAT64 gateway, because the company's private internal 196 recursive resolver is unlikely to be aware of the NAT64 prefix in use 197 on the NAT64 network to which the client device is currently 198 attached. It is clear that a single recursive resolver cannot meet 199 both needs. The local network's recursive resolver cannot give 200 answers for some company's private internal host names, and some 201 company's private internal recursive resolver cannot give correctly 202 synthesized IPv6 addresses suitable for the local network's NAT64 203 gateway. 205 Note that multiple NAT64 services may be simultaneously available to 206 a client. For example, the local network may provide NAT64 service 207 (to allow a IPv6-only client device to access IPv4-only Internet 208 services), while at the same time a corporate VPN may also provide 209 NAT64 service (to allow a client connecting via an IPv6-only VPN 210 tunnel to access IPv4-only corporate services). The NAT64 address 211 synthesis prefixes for the two NAT64 services may be different. In 212 this case it is essential that the NAT64 address synthesis prefix 213 used on the local network be the prefix learned from the local 214 network's recursive resolver, and the NAT64 address synthesis prefix 215 used on the VPN tunnel be the prefix learned from the VPN tunnel's 216 recursive resolver. 218 The conflict here arises because DNS is being used for two unrelated 219 purposes. The first purpose is retrieving data from a (nominally) 220 global database -- generally retrieving the IP address(es) associated 221 with a hostname. The second purpose is using the DNS protocol as a 222 middlebox communication protocol, to interrogate the local network 223 infrastructure to discover the IPv6 prefix(es) in use by the local 224 NAT64 gateway for address synthesis. 226 3.2. Consequences for DNS64 Implementations 228 As a result of there being no mandate for special treatment, queries 229 for 'ipv4only.arpa' had to be handled normally, resulting in DNS64 230 gateways performing unnecessary IPv6 address record queries (DNS 231 qtype "AAAA", always returning negative responses) and IPv4 address 232 record queries (DNS qtype "A", always returning the same positive 233 responses) to the authoritative 'arpa' name servers. 235 Having DNS64 gateways around the world issue these queries generated 236 additional load on the authoritative 'arpa' name servers, which was 237 redundant when the name 'ipv4only.arpa' is defined, by IETF 238 specification [RFC7050], to have exactly two IPv4 address records, 239 192.0.0.170 and 192.0.0.171, and no other IPv4 or IPv6 address 240 records. 242 Also, at times, for reasons that remain unclear, the authoritative 243 'arpa' name servers have been observed to be slow or unresponsive. 244 The failures of these 'ipv4only.arpa' queries result in unnecessary 245 failures of the DNS64 gateways and of the client devices that depend 246 on them for DNS64 [RFC6147] address synthesis. 248 Even when the authoritative 'arpa' name servers are operating 249 correctly, having to perform an unnecessary query to obtain an answer 250 that is already known in advance can add precious milliseconds of 251 delay, affecting user experience on the client devices waiting for 252 those synthesized replies. 254 4. Remedies 256 This document leverages operational experience to update the Domain 257 Name Reservation Considerations [RFC6761] section of the earlier 258 specification [RFC7050] with one that more accurately lists the 259 actual special properties of the name 'ipv4only.arpa', so that 260 software can legitimately implement the correct behavior necessary 261 for better performance, better reliability, and correct operation. 263 These changes affect two bodies of software, (a) the name resolution 264 APIs and libraries on client devices, and (b) DNS64 implementations. 266 The new special rules specified in this document for name resolution 267 APIs and libraries state how they should select which recursive 268 resolver to query to learn the IPv6 address synthesis prefix in use 269 on a particular physical or virtual interface. Specifically: When 270 querying for the name 'ipv4only.arpa', name resolution APIs and 271 libraries should use the recursive resolver recommended by the 272 network for the interface in question, rather than a recursive 273 resolver configured manually, a recursive resolver configured by VPN 274 software, or a full-service recursive resolver running on the local 275 host. Superficially this might seem like a security issue, since the 276 user might have explicitly configured the particular DNS resolver 277 they wish to use, and rather than using that, the name resolution 278 code ignores the user's stated preference and uses untrusted input 279 received from the network instead. However, the 'ipv4only.arpa' 280 query is not really a DNS query in the usual sense; even though it 281 may look like a DNS query, it is actually an improvised client-to- 282 middlebox communication protocol in disguise. For NAT64 to work at 283 all, it is necessary for the interface on which NAT64 translation is 284 being performed to tell the host the address of the DNS64 recursive 285 resolver the host must use to learn the NAT64 prefix being used by 286 that NAT64. This is typically done via IPv6 Router Advertisement 287 Options for DNS Configuration [RFC8106] or via DNS Configuration 288 options for DHCPv6 [RFC3646]. 290 The new special rules specified in this document for DNS64 291 implementations recommend that they avoid performing run-time network 292 queries for values that are known to be fixed by specification. 294 A useful property of the way NAT64 Prefix Discovery [RFC7050] was 295 originally specified was that it allowed for incremental deployment. 296 Even if existing DNS64 gateways, that were unaware of the special 297 'ipv4only.arpa' name, were already deployed, once IANA created the 298 appropriate 'ipv4only.arpa' records, clients could begin to use the 299 new facility immediately. Clients could send their special queries 300 for 'ipv4only.arpa' to an ipv4only-unaware DNS64 gateway, and (after 301 a query to IANA's servers) the DNS64 gateway would then generate the 302 correct synthesized response. 304 While this was a useful transition strategy to enable rapid adoption, 305 it is not the ideal end situation. For better performance, better 306 reliability, and lower load in IANA's servers, it is preferable for 307 DNS64 gateways to be aware of the special 'ipv4only.arpa' name so 308 that they can avoid issuing unnecessary queries. Network operators 309 who wish to provide reliable, high performance service to their 310 customers are motivated to prefer DNS64 gateways that recognize the 311 special 'ipv4only.arpa' name and apply the appropriate optimizations. 313 5. Security Considerations 315 One of the known concerns with DNS64 is that it conflicts with 316 DNSSEC. If DNSSEC is used to assert cryptographically that a name 317 has no IPv6 AAAA records, then this interferes with using DNS64 318 address synthesis to assert that those nonexistent IPv6 AAAA records 319 do exist. 321 Section 3 of the DNS64 specification [RFC6147] discusses this: 323 ... DNS64 receives a query with the DO bit set and 324 the CD bit set. In this case, the DNS64 is supposed 325 to pass on all the data it gets to the query initiator. 326 This case will not work with DNS64, unless the 327 validating resolver is prepared to do DNS64 itself. 329 The NAT64 Prefix Discovery specification [RFC7050] provides the 330 mechanism for the query initiator to learn the NAT64 prefix so that 331 it can do its own validation and DNS64 synthesis as described above. 332 With this mechanism the client can (i) interrogate the local DNS64/ 333 NAT64 gateway with an 'ipv4only.arpa' query to learn the IPv6 address 334 synthesis prefix, (ii) query for the (signed) IPv4 address records 335 itself, and validate the response, and then (iii) perform its own 336 IPv6 address synthesis locally, combining the IPv6 address synthesis 337 prefix learned from the local DNS64/NAT64 gateway with the validated 338 DNSSEC-signed data learned from the global Domain Name System. 340 It is conceivable that over time, if DNSSEC adoption continues to 341 grow, the majority of clients could move to this validate-and- 342 synthesize-locally model, which reduces the DNS64 machinery to the 343 vestigial role of simply responding to the 'ipv4only.arpa' query to 344 report the local IPv6 address synthesis prefix. In no case does the 345 client care what answer(s) the authoritative 'arpa' name servers 346 might give for that query. The 'ipv4only.arpa' query is being used 347 purely as a local client-to-middlebox communication message. 349 This approach is even more attractive if it does not create an 350 additional dependency on the authoritative 'arpa' name servers to 351 answer a query that is unnecessary because the DNS64/NAT64 gateway 352 already knows the answer before it even issues the query. Avoiding 353 this unnecessary query improves performance and reliability for the 354 client, and reduces unnecessary load for the authoritative 'arpa' 355 name servers. 357 Hard-coding the known answers for 'ipv4only.arpa' IPv4 address record 358 queries (DNS qtype "A") in recursive resolvers also reduces the risk 359 of malicious devices intercepting those queries and returning 360 incorrect answers. Because the 'ipv4only.arpa' zone has to be an 361 insecure delegation (see below) DNSSEC cannot be used to protect 362 these answers from tampering by malicious devices on the path. 364 With respect to the question of whether 'ipv4only.arpa' should be a 365 secure or insecure delegation, we need to consider two paths of 366 information flow through the network: The path from the server 367 authoritative for 'ipv4only.arpa' to the DNS64 recursive resolver, 368 and the path from the DNS64 recursive resolver to the ultimate 369 client. 371 The path from the authoritative server to the DNS64 recursive 372 resolver (queries for IPv4 address records) need not be protected by 373 DNSSEC, because the DNS64 recursive resolver already knows, by 374 specification, what the answers are. In principle, if this were a 375 secure delegation, and 'ipv4only.arpa' were a signed zone, then the 376 path from the authoritative server to the DNS64 recursive resolver 377 would still work, but DNSSEC is not necessary here. Run-time 378 cryptographic signatures are not needed to verify compile-time 379 constants. Validating the signatures could only serve to introduce 380 potential failures into the system for minimal benefit. 382 The path from the DNS64 recursive resolver to the ultimate client 383 (queries for IPv6 address records) *cannot* be protected by DNSSEC, 384 because the DNS64 recursive resolver is synthesizing IPv6 address 385 answers, and does not possess the DNSSEC secret key required to sign 386 those answers. 388 Consequently, the 'ipv4only.arpa' zone MUST be an insecure 389 delegation, to give DNS64/NAT64 gateways the freedom to synthesize 390 answers to those queries at will, without the answers being rejected 391 by DNSSEC-capable resolvers. DNSSEC-capable resolvers that follow 392 this specification MUST NOT attempt to validate answers received in 393 response to queries for the IPv6 AAAA address records for 394 'ipv4only.arpa'. Note that the name 'ipv4only.arpa' has no use 395 outside of being used for this special DNS pseudo-query used to learn 396 the DNS64/NAT64 address synthesis prefix, so the lack of DNSSEC 397 security for that name is not a problem. 399 The original NAT64 Prefix Discovery specification [RFC7050] stated, 400 incorrectly: 402 A signed "ipv4only.arpa." allows validating DNS64 servers 403 (see [RFC6147] Section 3, Case 5, for example) to detect 404 malicious AAAA resource records. Therefore, the zone 405 serving the well-known name has to be protected with DNSSEC. 407 This document updates the previous specification [RFC7050] to correct 408 that error. The 'ipv4only.arpa' zone MUST be an insecure delegation. 410 6. IANA Considerations 412 [Once published] IANA has created an insecure delegation for 413 'ipv4only.arpa' to allow DNS64 recursive resolvers to create 414 synthesized AAAA answers within that zone. 416 IANA has recorded the following names in the 417 Special-Use Domain Names registry [SUDN]: 419 ipv4only.arpa. 420 170.0.0.192.in-addr.arpa. 421 171.0.0.192.in-addr.arpa. 423 IANA has recorded the following IPv4 addresses in the 424 IPv4 Special-Purpose Address Registry [SUv4]: 426 192.0.0.170 427 192.0.0.171 429 7. Domain Name Reservation Considerations 431 7.1. Special Use Domain Name 'ipv4only.arpa' 433 The name 'ipv4only.arpa' is defined, by IETF specification [RFC7050], 434 to have two IPv4 address records with rdata 192.0.0.170 and 435 192.0.0.171. 437 When queried via a DNS64 [RFC6147] recursive resolver, the name 438 'ipv4only.arpa' is also defined to have IPv6 AAAA records, with rdata 439 synthesized from a combination of the NAT64 IPv6 prefix(es) and the 440 IPv4 addresses 192.0.0.170 and 192.0.0.171. This can return more 441 than one pair of IPv6 addresses if there are multiple NAT64 prefixes. 443 The name 'ipv4only.arpa' has no other IPv4 or IPv6 address records. 444 There are no subdomains of 'ipv4only.arpa'. All names falling below 445 'ipv4only.arpa' are defined to be nonexistent (NXDOMAIN). 447 The name 'ipv4only.arpa' is special to 448 (a) client software wishing to perform DNS64 address synthesis, 449 (b) APIs responsible for retrieving the correct information, and 450 (c) the DNS64 recursive resolver responding to such requests. 451 These three considerations are listed in items 2, 3 and 4 below: 453 1. Normal users should never have reason to encounter the 454 'ipv4only.arpa' domain name. If they do, they should expect 455 queries for 'ipv4only.arpa' to result in the answers required by 456 the specification [RFC7050]. Normal users have no need to know 457 that 'ipv4only.arpa' is special. 459 2. Application software may explicitly use the name 'ipv4only.arpa' 460 for DNS64/NAT64 address synthesis, and expect to get the answers 461 required by the specification [RFC7050]. If application software 462 encounters the name 'ipv4only.arpa' in the normal course of 463 handling user input, the application software should resolve that 464 name as usual and need not treat it in any special way. 466 3. Name resolution APIs and libraries MUST recognize 'ipv4only.arpa' 467 as special and MUST give it special treatment. 469 Learning a network's NAT64 prefix is by its nature an interface- 470 specific operation, and the special DNS query used to learn this 471 interface-specific NAT64 prefix MUST be sent to the DNS recursive 472 resolver address(es) the client learned via the configuration 473 machinery for that specific client interface. The NAT64 prefix 474 is a per-interface property, not a per-device property. 476 Regardless of any manual client DNS configuration, DNS overrides 477 configured by VPN client software, or any other mechanisms that 478 influence the choice of the client's recursive resolver 479 address(es) (including client devices that run their own local 480 recursive resolver and use the loopback address as their 481 configured recursive resolver address) all queries for 482 'ipv4only.arpa' and any subdomains of that name MUST be sent to 483 the recursive resolver learned from the network interface in 484 question via IPv6 Router Advertisement Options for DNS 485 Configuration [RFC8106], DNS Configuration options for DHCPv6 486 [RFC3646], or other configuration mechanisms. Because DNS 487 queries for 'ipv4only.arpa' are actually a special middlebox 488 communication protocol, it is essential that they go to the 489 correct middlebox for the interface in question, and failure to 490 honor this requirement would cause failure of the NAT64 Prefix 491 Discovery mechanism [RFC7050]. 493 One implication of this is that, on multi-homed devices (devices 494 that allow more than one logical or physical IP interface to be 495 active at the same time, e.g., cellular data and Wi-Fi, or one 496 physical interface plus a VPN connection), clients MUST use 497 interface-aware name resolution APIs. On different (logical or 498 physical) interfaces, different DNS64 answers may be received, 499 and DNS64 answers are only valid for the interface on which they 500 were received. On multi-homed devices (including devices that 501 support VPN), name resolution APIs that do not include interface 502 parameters will not work reliably with NAT64. On single-homed 503 devices, interface-unaware name resolution APIs are acceptable 504 since when only one interface can be active at a time there is no 505 need to specify an interface. 507 DNSSEC-capable resolvers MUST NOT attempt to validate answers 508 received in response to queries for the IPv6 AAAA address records 509 for 'ipv4only.arpa', since, by definition, any such answers are 510 generated by the local network's DNS64/NAT64 gateway, not the 511 authoritative server responsible for that name. 513 4. For the purposes of this section, recursive resolvers fall into 514 two categories. The first category is traditional recursive 515 resolvers, which includes *forwarding* recursive resolvers, as 516 commonly implemented in residential home gateways, and 517 *iterative* recursive resolvers, as commonly deployed by ISPs. 518 More information on these terms can be found in DNS Terminology 519 [RFC8499]. The second category is DNS64 recursive resolvers, 520 whose purpose is to synthesize IPv6 address records. These may 521 be *forwarding* DNS64 recursive resolvers or *iterative* DNS64 522 recursive resolvers, and they work in partnership with a 523 companion NAT64 gateway to communicate the appropriate NAT64 524 address synthesis prefix to clients. 526 Traditional forwarding recursive resolvers SHOULD NOT recognize 527 'ipv4only.arpa' as special or give that name, or subdomains of 528 that name, any special treatment. The rationale for this is that 529 a traditional forwarding recursive resolver, such as built in to 530 a residential home gateway, may itself be downstream of a DNS64 531 recursive resolver. Passing through the 'ipv4only.arpa' queries 532 to the upstream DNS64 recursive resolver will allow the correct 533 NAT64 prefix to be discovered. 535 Traditional iterative recursive resolvers that are not explicitly 536 configured to synthesize IPv6 prefixes on behalf of a companion 537 NAT64 gateway need not recognize 'ipv4only.arpa' as special or 538 take any special action. 540 Forwarding or iterative recursive resolvers that have been 541 explicitly configured to perform DNS64 address synthesis in 542 support of a companion NAT64 gateway (i.e, "DNS64 recursive 543 resolvers") MUST recognize 'ipv4only.arpa' as special. The 544 authoritative name servers for 'ipv4only.arpa' cannot be expected 545 to know the local network's NAT64 address synthesis prefix, so 546 consulting the authoritative name servers for IPv6 address 547 records for 'ipv4only.arpa' is futile. All DNS64 recursive 548 resolvers MUST recognize 'ipv4only.arpa' (and all of its 549 subdomains) as special, and MUST NOT attempt to look up NS 550 records for 'ipv4only.arpa', or otherwise query authoritative 551 name servers in an attempt to resolve this name. Instead, DNS64 552 recursive resolvers MUST act as authoritative for this zone, by 553 generating immediate responses for all queries for 554 'ipv4only.arpa' (and any subdomain of 'ipv4only.arpa'), with the 555 one exception of queries for the DS record. Queries for the DS 556 record are resolved the usual way to allow a client to securely 557 verify that the 'ipv4only.arpa' zone has an insecure delegation. 558 Note that this exception is not expected to receive widespread 559 usage, since any client compliant with this specification already 560 knows that 'ipv4only.arpa' is an insecure delegation and will not 561 attempt DNSSEC validation for this name. 563 DNS64 recursive resolvers MUST generate the 192.0.0.170 and 564 192.0.0.171 responses for IPv4 address queries (DNS qtype "A"), 565 the appropriate synthesized IPv6 address record responses for 566 IPv6 address queries (DNS qtype "AAAA"), and a negative 567 ("no error no answer") response for all other query types except 568 DS. 570 For all subdomains of 'ipv4only.arpa', DNS64 recursive resolvers 571 MUST generate immediate NXDOMAIN responses. All names falling 572 below 'ipv4only.arpa' are defined to be nonexistent. 574 An example configuration for BIND 9 showing how to achieve the 575 desired result is given in Appendix A. 577 Note that this is *not* a locally served zone in the usual sense 578 of that term [RFC6303] because this rule applies *only* to DNS64 579 recursive resolvers, not to forwarding DNS recursive resolvers. 581 5. Authoritative name server software need not recognize 582 'ipv4only.arpa' as special or handle it in any special way. 584 6. Generally speaking, operators of authoritative name servers need 585 not know anything about the name 'ipv4only.arpa', just as they do 586 not need to know anything about any other names they are not 587 responsible for. Only the administrators of the 'arpa' namespace 588 need to be aware of this name's purpose and how it should be 589 configured. In particular, 'ipv4only.arpa' MUST have the 590 required records, and MUST be an insecure delegation, to allow 591 DNS64 recursive resolvers to create synthesized AAAA answers 592 within that zone. Making the 'ipv4only.arpa' zone a secure 593 delegation would make it impossible for DNS64 recursive resolvers 594 to create synthesized AAAA answers that will be accepted by 595 DNSSEC validating clients, thereby defeating the entire purpose 596 of the 'ipv4only.arpa' name. 598 7. DNS Registries/Registrars need not know anything about the name 599 'ipv4only.arpa', just as they do not need to know anything about 600 any other name they are not responsible for. 602 7.2. Names '170.0.0.192.in-addr.arpa' and '171.0.0.192.in-addr.arpa' 604 Since the IPv4 addresses 192.0.0.170 and 192.0.0.171 are defined to 605 be special, and are listed in the IPv4 Special-Purpose Address 606 Registry [SUv4], the corresponding reverse mapping names in the 607 in-addr.arpa domain are similarly special. 609 The name '170.0.0.192.in-addr.arpa' is defined, by IETF specification 610 [RFC7050], to have only one DNS record, type PTR, with rdata 611 'ipv4only.arpa'. 613 The name '171.0.0.192.in-addr.arpa' is defined, by IETF specification 614 [RFC7050], to have only one DNS record, type PTR, with rdata 615 'ipv4only.arpa'. 617 There are no subdomains of '170.0.0.192.in-addr.arpa' or 618 '171.0.0.192.in-addr.arpa'. All names falling below these names are 619 defined to be nonexistent (NXDOMAIN). 621 Practically speaking these two names are rarely used, but to the 622 extent that they may be, they are special only to resolver APIs and 623 libraries, as described in item 3 below: 625 1. Normal users should never have reason to encounter these two 626 reverse mapping names. However, if they do, queries for these 627 reverse mapping names should return the expected answer 628 'ipv4only.arpa'. Normal users have no need to know that these 629 reverse mapping names are special. 631 2. Application software SHOULD NOT recognize these two reverse 632 mapping names as special, and SHOULD NOT treat them differently. 633 For example, if the user were to issue the Unix command 634 "host 192.0.0.170" then the "host" command should call the name 635 resolution API or library as usual and display the result that is 636 returned. 638 3. Name resolution APIs and libraries SHOULD recognize these two 639 reverse mapping names as special and generate the required 640 responses locally. For the names '170.0.0.192.in-addr.arpa' and 641 '171.0.0.192.in-addr.arpa' PTR queries yield the result 642 'ipv4only.arpa'; all other query types yield a negative 643 ("no error no answer") response. For all subdomains of these two 644 reverse mapping domains, all queries yield an NXDOMAIN response. 645 All names falling below these two reverse mapping domains are 646 defined to be nonexistent. 648 This local self-contained generation of these responses is to 649 avoid placing unnecessary load on the authoritative 650 'in-addr.arpa' name servers. 652 4. Recursive resolvers SHOULD NOT recognize these two reverse 653 mapping names as special and SHOULD NOT, by default, give them 654 any special treatment. 656 5. Authoritative name server software need not recognize these two 657 reverse mapping names as special or handle them in any special 658 way. 660 6. Generally speaking, most operators of authoritative name servers 661 need not know anything about these two reverse mapping names, 662 just as they do not need to know anything about any other names 663 they are not responsible for. Only the operators of the 664 authoritative name servers for these two reverse mapping names 665 need to be aware that these names are special, and require fixed 666 answers specified by IETF specification. 668 7. DNS Registries/Registrars need not know anything about these two 669 reverse mapping names, just as they do not need to know anything 670 about any other name they are not responsible for. 672 7.2.1. ip6.arpa Reverse Mapping PTR Records 674 For all IPv6 addresses synthesized by a DNS64 recursive resolver, the 675 DNS64 recursive resolver is responsible for synthesizing the 676 appropriate 'ip6.arpa' reverse mapping PTR records too, if it chooses 677 to provide reverse mapping PTR records. The same applies to the 678 synthesized IPv6 addresses corresponding to the IPv4 addresses 679 192.0.0.170 and 192.0.0.171. 681 Generally a DNS64 recursive resolver synthesizes appropriate 682 'ip6.arpa' reverse mapping PTR records by extracting the embedded 683 IPv4 address from the encoded IPv6 address, performing a reverse 684 mapping PTR query for that IPv4 address, and then synthesizing a 685 corresponding 'ip6.arpa' reverse mapping PTR record containing the 686 same rdata. 688 In the case of synthesized IPv6 addresses corresponding to the IPv4 689 addresses 192.0.0.170 and 192.0.0.171, the DNS64 recursive resolver 690 does not issue reverse mapping queries for those IPv4 addresses, but 691 instead, according to rule 3 above, immediately returns the answer 692 'ipv4only.arpa'. 694 In the case of a client that uses the 'ipv4only.arpa' query to 695 discover the IPv6 prefixes in use by the local NAT64 gateway, and 696 then proceeds to perform its own address synthesis locally (which has 697 benefits such as allowing DNSSEC validation), that client MUST also 698 synthesize 'ip6.arpa' reverse mapping PTR records for those 699 discovered prefix(es), according to the rules above: When a client's 700 name resolution APIs and libraries receive a request to look up an 701 'ip6.arpa' reverse mapping PTR record for an address that falls 702 within one of the discovered NAT64 address synthesis prefixes, the 703 software extracts the embedded IPv4 address and then, for IPv4 704 addresses 192.0.0.170 and 192.0.0.171, returns the fixed answer 705 'ipv4only.arpa', and for all other IPv4 addresses performs a reverse 706 mapping PTR query for the IPv4 address, and then synthesizes a 707 corresponding 'ip6.arpa' reverse mapping PTR record containing the 708 same rdata. 710 8. Acknowledgements 712 Thanks to Jouni Korhonen, Teemu Savolainen, and Dan Wing, for 713 devising the NAT64 Prefix Discovery mechanism [RFC7050], and for 714 their feedback on this document. 716 Thanks to Geoff Huston for his feedback on this document. 718 Thanks to Erik Kline for pointing out that the in-addr.arpa names are 719 special too. 721 Thanks to Mark Andrews for conclusively pointing out the reasons why 722 the 'ipv4only.arpa' zone must be an insecure delegation in order for 723 the NAT64 Prefix Discovery mechanism [RFC7050] to work, and many 724 other very helpful comments. 726 Thanks particularly to Lorenzo Colitti for an especially spirited 727 hallway discussion at IETF 96 in Berlin, which lead directly to 728 significant improvements in how this document presents the issues. 730 Thanks to Scott Bradner, Bernie Volz, Barry Leiba, Mirja Kuehlewind, 731 Suresh Krishnan, Benjamin Kaduk, Roman Danyliw, Eric Vyncke and the 732 other IESG reviewers for their thoughtful feedback. 734 Thanks to Dave Thaler and Warren Kumari for generously helping 735 shepherd this document through the publication process. 737 9. References 739 9.1. Normative References 741 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 742 Requirement Levels", BCP 14, RFC 2119, 743 DOI 10.17487/RFC2119, March 1997, 744 . 746 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 747 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 748 DOI 10.17487/RFC3646, December 2003, 749 . 751 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 752 NAT64: Network Address and Protocol Translation from IPv6 753 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 754 April 2011, . 756 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 757 Beijnum, "DNS64: DNS Extensions for Network Address 758 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 759 DOI 10.17487/RFC6147, April 2011, 760 . 762 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 763 RFC 6761, DOI 10.17487/RFC6761, February 2013, 764 . 766 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 767 the IPv6 Prefix Used for IPv6 Address Synthesis", 768 RFC 7050, DOI 10.17487/RFC7050, November 2013, 769 . 771 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 772 "IPv6 Router Advertisement Options for DNS Configuration", 773 RFC 8106, DOI 10.17487/RFC8106, March 2017, 774 . 776 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 777 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 778 May 2017, . 780 9.2. Informative References 782 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, 783 RFC 6303, DOI 10.17487/RFC6303, July 2011, 784 . 786 [RFC8244] Lemon, T., Droms, R., and W. Kumari, "Special-Use Domain 787 Names Problem Statement", RFC 8244, DOI 10.17487/RFC8244, 788 October 2017, . 790 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 791 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 792 January 2019, . 794 [SUDN] "Special-Use Domain Names Registry", 795 . 798 [SUv4] "IANA IPv4 Special-Purpose Address Registry", 799 . 802 [DNS1] "1.1.1.1 - The free app that makes your Internet safer", 803 . 805 [DNS8] "Google Public DNS", 806 . 808 [DNS9] "Quad9 - Internet Security and Privacy In a Few Easy 809 Steps", . 811 Appendix A. Example BIND 9 Configuration 813 A BIND 9 recursive resolver can be configured to act as authoritative 814 for the necessary DNS64 names as described below. 816 In /etc/named.conf the following line is added: 818 zone "ipv4only.arpa" { type master; file "ipv4only"; }; 820 The file /var/named/ipv4only is created with the following content: 822 $TTL 86400 ; Default TTL 24 hours 823 @ IN SOA nameserver.example. admin.nameserver.example. ( 824 2016052400 ; Serial 825 7200 ; Refresh ( 7200 = 2 hours) 826 3600 ; Retry ( 3600 = 1 hour) 827 15724800 ; Expire (15724800 = 6 months) 828 60 ; Minimum 829 ) 830 @ IN NS nameserver.example. 832 @ IN A 192.0.0.170 833 @ IN A 192.0.0.171 834 @ IN AAAA 64:ff9b::192.0.0.170 ; If not using Well-Known Prefix 835 @ IN AAAA 64:ff9b::192.0.0.171 ; place chosen NAT64 prefix here 837 Authors' Addresses 839 Stuart Cheshire 840 Apple Inc. 841 One Apple Park Way 842 Cupertino, California 95014 843 USA 845 Phone: +1 (408) 996-1010 846 Email: cheshire@apple.com 848 David Schinazi 849 Google LLC 850 1600 Amphitheatre Parkway 851 Mountain View, California 94043 852 USA 854 Email: dschinazi.ietf@gmail.com