idnits 2.17.1 draft-cheshire-sudn-ipv4only-dot-arpa-06.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 : ---------------------------------------------------------------------------- ** 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 19 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 15, 2016) is 2718 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: 1 error (**), 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 D. Schinazi 4 Updates: 7050 (if approved) Apple Inc. 5 Intended status: Standards Track November 15, 2016 6 Expires: May 19, 2017 8 Special Use Domain Name 'ipv4only.arpa' 9 draft-cheshire-sudn-ipv4only-dot-arpa-06 11 Abstract 13 The specification for how a client discovers its network's NAT64 14 prefix [RFC7050] defines the special name 'ipv4only.arpa' for this 15 purpose, but declares it to be a non-special name in that 16 specification's Domain Name Reservation Considerations section. 18 Consequently, despite the well articulated special purpose of the 19 name, as of November 2016 'ipv4only.arpa' still does not appear as 20 one of the names with special properties that are recorded in the 21 Special-Use Domain Names registry. 23 This document formally declares the actual special properties of the 24 name, and adds similar declarations for the corresponding reverse 25 mapping names. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 19, 2017. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 1. Introduction 61 The specification for how a client discovers its network's NAT64 62 prefix [RFC7050] defines the special name 'ipv4only.arpa' for this 63 purpose, but declares it to be a non-special name in that 64 specification's Domain Name Reservation Considerations section. 66 Consequently, despite the well articulated special purpose of the 67 name, as of November 2016 'ipv4only.arpa' still does not appear as 68 one of the names with special properties that are recorded in the 69 Special-Use Domain Names registry [SUDN]. 71 This document formally declares the actual special properties of the 72 name. This document also adds similar declarations for the 73 corresponding reverse mapping names. 75 2. Specialness of 'ipv4only.arpa' 77 The hostname 'ipv4only.arpa' is peculiar in that it was never 78 intended to be treated like a normal hostname. 80 A typical client never looks up the IPv4 address records for 81 'ipv4only.arpa', because it is already known, by specification 82 [RFC7050], to have exactly two IPv4 address records, 192.0.0.170 and 83 192.0.0.171. No client ever has to look the name in order to learn 84 those two addresses. 86 In contrast, clients often look up the IPv6 AAAA address records for 87 'ipv4only.arpa', which is contrary to general DNS expectations, given 88 that it is already known, by specification [RFC7050], that no such 89 IPv6 AAAA address records exist. And yet, clients expect to receive, 90 and do in fact receive, positive answers for these IPv6 AAAA address 91 records that are known to not exist. 93 This is clearly not a typical DNS name. In normal operation, clients 94 never query for the two records that do in fact exist; instead they 95 query for records that are known to not exist, and then get positive 96 answers to those abnormal queries. Clients are using DNS to perform 97 queries for this name, but they are certainly not using DNS to learn 98 legitimate answers from the name's legitimate authoritative server. 99 Instead, these clients have, in effect, co-opted the DNS protocol as 100 an impromptu client-to-middlebox communication protocol, to 101 communicate with the NAT64/DNS64 [RFC6146][RFC6147] gateway, if 102 present, and request that it disclose the prefix it is using for IPv6 103 address synthesis. 105 It is this use of specially-crafted DNS queries as an impromptu 106 client-to-middlebox communication protocol that makes the name 107 'ipv4only.arpa' most definitely a special name, and one that should, 108 in the spirit of openness and honesty, be listed in IANA's registry 109 along with other DNS names that have special uses [SUDN]. 111 3. Consequences of 'ipv4only.arpa' previously being declared unspecial 113 As a result of the original specification [RFC7050] not formally 114 declaring 'ipv4only.arpa' to have special properties, there was no 115 mandate for any server software to treat this name specially. 116 Consequently, queries for this name had to be handled normally, 117 resulting in unnecessary queries to the authoritative 'arpa' name 118 servers. 120 Having millions of devices around the world issue these queries 121 generated pointless additional load on the authoritative 'arpa' name 122 servers, which was completely unnecessary when the name 123 'ipv4only.arpa' is defined, by Internet Standard, to have exactly two 124 IPv4 address records, 192.0.0.170 and 192.0.0.171, and no other 125 records of any type. 127 Also, at times, for reasons that are as yet unclear, the 128 authoritative 'arpa' name servers have been observed to be slow or 129 unresponsive. The failures of these 'ipv4only.arpa' queries result 130 in unnecessary failures of software that depends on them for DNS64 131 [RFC6147] address synthesis. 133 Even when the authoritative 'arpa' name servers are operating 134 correctly, having to perform an unnecessary query to obtain an answer 135 that is already known in advance can add precious milliseconds of 136 delay for no reason. 138 This document leverages this operational experience to update the 139 Domain Name Reservation Considerations section [RFC6761] of the 140 earlier specification [RFC7050] with one that accurately lists the 141 actual special properties of the name 'ipv4only.arpa' so that 142 software can legitimately make appropriate performance and 143 reliability optimizations. 145 4. Security Considerations 147 Hard-coding the known answers for 'ipv4only.arpa' queries in 148 recursive/caching DNS servers reduces the risk of malicious devices 149 intercepting those queries and returning incorrect answers, 150 particularly in the case of recursive/caching DNS servers that do not 151 perform DNSSEC validation. 153 One of the known concerns with DNS64 [RFC6147] is that it interferes 154 with DNSSEC. DNSSEC may cryptographically assert that a name has no 155 IPv6 AAAA records, while at the same time DNS64 address synthesis is 156 contradicting this and claiming that IPv6 AAAA records do exist. 158 Section 3 of the DNS64 specification [RFC6147] discusses this: 160 ... DNS64 receives a query with the DO bit set and 161 the CD bit set. In this case, the DNS64 is supposed 162 to pass on all the data it gets to the query initiator. 163 This case will not work with DNS64, unless the 164 validating resolver is prepared to do DNS64 itself. 166 The NAT64 Prefix Discovery specification [RFC7050] provides the 167 mechanism for the query initiator to learn the NAT64 prefix so that 168 it can do its own validation and DNS64 synthesis as described above. 169 With this mechanism the client can (i) interrogate the local NAT64/ 170 DNS64 gateway with an 'ipv4only.arpa' query to learn the IPv6 address 171 synthesis prefix, (ii) query for the (signed) IPv4 address records 172 itself, and then (iii) perform its own IPv6 address synthesis 173 locally, combining the IPv6 address synthesis prefix learned from the 174 local NAT64/DNS64 gateway with the secure DNSSEC-signed data learned 175 from the global Domain Name System. 177 It is conceivable that over time, if DNSSEC is successful, the 178 majority of clients could move to this validate-and-synthesize- 179 locally model, which reduces the DNS64 machinery to the vestigial 180 role of simply responding to the 'ipv4only.arpa' query to report the 181 local IPv6 address synthesis prefix. In no case does the client care 182 what answer(s) the authoritative 'arpa' name servers might give for 183 that query. The 'ipv4only.arpa' query is being used purely as a 184 local client-to-middlebox communication message. 186 This approach is even more attractive if it doesn't create an 187 additional dependency on the authoritative 'arpa' name servers to 188 answer a query that is unnecessary because the NAT64/DNS64 gateway 189 already knows the answer before it even issues the query. Avoiding 190 this unnecessary query improves performance and reliability for the 191 client, and reduces unnecessary load for the authoritative 'arpa' 192 name servers. 194 5. IANA Considerations 196 [Once published, this should say] 198 IANA has recorded the following names in the 199 Special-Use Domain Names registry [SUDN]: 200 ipv4only.arpa. 201 170.0.0.192.in-addr.arpa. 202 171.0.0.192.in-addr.arpa. 204 IANA has recorded the following IPv4 addresses in the 205 IPv4 Special-Purpose Address Registry [SUv4]: 206 192.0.0.170 207 192.0.0.171 209 6. Domain Name Reservation Considerations 211 6.1. Conventions and Terminology Used in this Section 213 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 214 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 215 "OPTIONAL" in this section are to be interpreted as described in "Key 216 words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 218 6.2. ipv4only.arpa 220 The name 'ipv4only.arpa' is defined, by Internet Standard, to have 221 two IPv4 address records with rdata 192.0.0.170 and 192.0.0.171. 223 When queried via a DNS64 [RFC6147] recursive/caching server, the name 224 'ipv4only.arpa' is also defined to have IPv6 AAAA records, with rdata 225 synthesized from a combination of the NAT64 IPv6 prefix(es), and the 226 IPv4 addresses 192.0.0.170 and 192.0.0.171. This can return more 227 than one pair of IPv6 addresses if there are multiple NAT64 prefixes. 229 The name 'ipv4only.arpa' has no other DNS records of any type. 230 There are no subdomains of ipv4only.arpa. All names falling below 231 'ipv4only.arpa' are defined to be nonexistent (NXDOMAIN). 233 The name 'ipv4only.arpa' is special only to 234 (a) client software wishing to perform DNS64 address synthesis, and 235 (b) the DNS64 recursive/caching server responding to such requests. 236 These two considerations are listed in items 2 and 4 below: 238 1. Normal users should never have reason to encounter the 239 'ipv4only.arpa' domain name. If they do, they should expect 240 queries for 'ipv4only.arpa' to result in the answers required by 241 the specification [RFC7050]. Normal users have no need to know 242 that 'ipv4only.arpa' is special. 244 2. Application software may explicitly use the name 'ipv4only.arpa' 245 for NAT64/DNS64 address synthesis, and expect to get the answers 246 required by the specification [RFC7050]. If application software 247 encounters the name 'ipv4only.arpa' in the normal course of 248 handling user input, the application software should resolve that 249 name as usual and need not treat it in any special way. 251 3. Name resolution APIs and libraries MUST NOT recognize 252 'ipv4only.arpa' as special and MUST NOT treat it differently. 253 Name resolution APIs MUST treat this name just as they would any 254 other normal DNS name, and send queries for it to their 255 configured recursive/caching DNS server(s). 256 Failure to honor this requirement would cause failure of 257 the NAT64 Prefix Discovery mechanism [RFC7050]. 259 4. Recursive/caching DNS servers SHOULD recognize 'ipv4only.arpa' as 260 special and SHOULD NOT, by default, attempt to look up NS records 261 for it, or otherwise query authoritative DNS servers in an 262 attempt to resolve this name. Instead, recursive/caching DNS 263 servers SHOULD, by default, act as authoritative and generate 264 immediate responses for all such queries. 266 Traditional recursive/caching DNS servers that act as 267 authoritative for this name MUST generate only the 192.0.0.170 268 and 192.0.0.171 responses for IPv4 address queries 269 (DNS qtype "A"), and a negative ("no error no answer") response 270 for all other query types. 272 All DNS64 recursive/caching DNS servers MUST generate the 273 192.0.0.170 and 192.0.0.171 responses for IPv4 address queries 274 (DNS qtype "A"), the appropriate synthesized IPv6 address record 275 responses for IPv6 address queries (DNS qtype "AAAA"), and a 276 negative ("no error no answer") response for all other query 277 types. 279 For all subdomains of 'ipv4only.arpa', recursive/caching DNS 280 servers SHOULD generate immediate NXDOMAIN responses. All names 281 falling below 'ipv4only.arpa' are defined to be nonexistent. 283 This local self-contained generation of these responses is to 284 avoid placing unnecessary load on the authoritative 'arpa' name 285 servers. 287 Example configurations for BIND 9 showing how to achieve these 288 results are given in Appendix A. 290 5. Traditional authoritative DNS server software need not recognize 291 'ipv4only.arpa' as special or handle it in any special way. 292 Recursive/caching DNS servers SHOULD routinely act as 293 authoritative for this name and return the results described 294 above. Only the administrators of the 'arpa' namespace need to 295 explicitly configure their actual authoritative name servers to 296 be authoritative for this name and to generate the appropriate 297 answers; all other authoritative name servers will not be 298 configured to know anything about this name and will reject 299 queries for it, as they would reject queries for any other name 300 about which they have no information. 302 6. Generally speaking, operators of authoritative DNS servers need 303 not know anything about the name 'ipv4only.arpa', just as they 304 don't need to know anything about any other names they are not 305 responsible for. Operators of authoritative DNS servers who are 306 configuring their name servers to be authoritative for this name 307 MUST understand that 'ipv4only.arpa' is a special name, with 308 records rigidly specified by Internet Standard (generally this 309 applies only to the administrators of the 'arpa' namespace). 311 7. DNS Registries/Registrars need not know anything about the name 312 'ipv4only.arpa', just as they don't need to know anything about 313 any other name they are not responsible for. Only the 314 administrators of the 'arpa' namespace need to be aware of this 315 name's purpose and how it should be configured. 317 6.3. 170.0.0.192.in-addr.arpa and 171.0.0.192.in-addr.arpa 319 Since the IPv4 addresses 192.0.0.170 and 192.0.0.171 are defined to 320 be special, and are listed in the IPv4 Special-Purpose Address 321 Registry [SUv4], the corresponding reverse mapping names in the 322 in-addr.arpa domain are similarly special. 324 The name '170.0.0.192.in-addr.arpa' is defined, by Internet Standard, 325 to have only a single DNS record, type PTR, with rdata 326 'ipv4only.arpa'. 328 The name '171.0.0.192.in-addr.arpa' is defined, by Internet Standard, 329 to have only a single DNS record, type PTR, with rdata 330 'ipv4only.arpa'. 332 There are no subdomains of '170.0.0.192.in-addr.arpa' or 333 '171.0.0.192.in-addr.arpa'. All names falling below these names are 334 defined to be nonexistent (NXDOMAIN). 336 Practically speaking these two names are rarely used, but to the 337 extent that they may be, they are special only to recursive/caching 338 DNS servers as described in item 4 below: 340 1. Normal users should never have reason to encounter these two 341 reverse mapping names. However, if they do, queries for these 342 reverse mapping names should return the expected answer 343 'ipv4only.arpa'. Normal users have no need to know that these 344 reverse mapping names are special. 346 2. Application software SHOULD NOT recognize these two reverse 347 mapping names as special, and SHOULD NOT treat them differently. 348 For example, if the user were to issue the Unix command 349 "host 192.0.0.170" then the "host" command should issue the query 350 as usual and display the result that is returned. 352 3. Name resolution APIs and libraries MUST NOT recognize these two 353 reverse mapping names as special and MUST NOT treat them 354 differently. Name resolution APIs MUST treat these names just as 355 they would any other normal DNS name, and send queries for them 356 to their configured recursive/caching DNS server(s). 358 4. Recursive/caching DNS servers SHOULD recognize these two reverse 359 mapping names as special and SHOULD NOT, by default, attempt to 360 look up NS records for them, or otherwise query authoritative DNS 361 servers in an attempt to resolve them. Instead, recursive/ 362 caching DNS servers SHOULD, by default, act as authoritative and 363 generate immediate responses for all such queries. Recursive/ 364 caching DNS servers that do this MUST generate only the 365 'ipv4only.arpa' response for PTR queries, and a negative 366 ("no error no answer") response for all other query types. 368 For all subdomains of these two reverse mapping domains, 369 recursive/caching DNS servers SHOULD generate immediate NXDOMAIN 370 responses. All names falling below these two reverse mapping 371 domains are defined to be nonexistent. 373 This local self-contained generation of these responses is to 374 avoid placing unnecessary load on the authoritative 375 'in-addr.arpa' name servers. 377 5. Traditional authoritative DNS server software need not recognize 378 these two reverse mapping names as special or handle them in any 379 special way. 380 As a practical matter, only the administrators of the 381 '192.in-addr.arpa' namespace will configure their name servers to 382 be authoritative for these names and to generate the appropriate 383 answers; all other authoritative name servers will not be 384 configured to know anything about these names and will reject 385 queries for them as they would reject queries for any other name 386 about which they have no information. 388 6. Generally speaking, operators of authoritative DNS servers need 389 not know anything about these two reverse mapping names, just as 390 they don't need to know anything about any other names they are 391 not responsible for. Operators of authoritative DNS servers who 392 are configuring their name servers to be authoritative for this 393 name MUST understand that these two reverse mapping names are 394 special, with answers specified by Internet Standard (generally 395 this applies only to the administrators of the '192.in-addr.arpa' 396 namespace). 398 7. DNS Registries/Registrars need not know anything about these two 399 reverse mapping names, just as they don't need to know anything 400 about any other name they are not responsible for. Only the 401 administrators of the '192.in-addr.arpa' namespace need to be 402 aware of the purpose of these two names. 404 6.3.1. ip6.arpa Reverse Mapping PTR Records 406 For all IPv6 addresses synthesized by the NAT64 gateway, the DNS64 407 recursive/caching server is responsible for synthesizing the 408 appropriate ip6.arpa reverse mapping PTR records, if it chooses to do 409 so. The same applies to the synthesized IPv6 addresses corresponding 410 to the IPv4 addresses 192.0.0.170 and 192.0.0.171. 412 Generally a DNS64 recursive/caching server synthesizes appropriate 413 ip6.arpa reverse mapping PTR records by extracting the embedded IPv4 414 address from the encoded IPv6 address, performing a reverse mapping 415 query for that IPv4 address, and then synthesizing a corresponding 416 ip6.arpa reverse mapping PTR record containing the same rdata. 418 In the case of synthesized IPv6 addresses corresponding to the IPv4 419 addresses 192.0.0.170 and 192.0.0.171, the DNS64 recursive/caching 420 server does not issue reverse mapping queries for those IPv4 421 addresses, but instead, according to rule 3 above, immediately 422 returns the answer 'ipv4only.arpa'. 424 7. Acknowledgements 426 Thanks to Jouni Korhonen, Teemu Savolainen, and Dan Wing, for 427 devising the NAT64 Prefix Discovery mechanism [RFC7050], and for 428 their feedback on this document. Thanks to Erik Kline for pointing 429 out that the in-addr.arpa names are special too. Thanks particularly 430 to Lorenzo Colitti for an especially spirited hallway discussion at 431 IETF 96 in Berlin, which lead directly to significant improvements in 432 how this document presents the issues. 434 8. References 436 8.1. Normative References 438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 439 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 440 RFC2119, March 1997, 441 . 443 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 444 NAT64: Network Address and Protocol Translation from IPv6 445 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 446 April 2011, . 448 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 449 Beijnum, "DNS64: DNS Extensions for Network Address 450 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 451 DOI 10.17487/RFC6147, April 2011, 452 . 454 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 455 RFC 6761, DOI 10.17487/RFC6761, February 2013, 456 . 458 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 459 the IPv6 Prefix Used for IPv6 Address Synthesis", 460 RFC 7050, DOI 10.17487/RFC7050, November 2013, 461 . 463 8.2. Informative References 465 [SUDN] "Special-Use Domain Names Registry", . 468 [SUv4] "IANA IPv4 Special-Purpose Address Registry", . 471 Appendix A. Example BIND 9 Configuration 473 A BIND 9 recursive/caching DNS server could be configured to act as 474 authoritative for the appropriate names as follows. 476 In /etc/named.conf the following lines are added: 478 zone "ipv4only.arpa" { type master; file "ipv4only"; }; 479 zone "170.0.0.192.in-addr.arpa" { type master; file "ipv4only-r"; }; 480 zone "171.0.0.192.in-addr.arpa" { type master; file "ipv4only-r"; }; 482 The file /var/named/ipv4only is created with the following content. 483 (The lines marked "Only for DNS64 server" are omitted on a standard 484 recursive/caching DNS server.) 486 $TTL 86400 ; Default TTL 24 hours 487 @ IN SOA nameserver.example. admin.nameserver.example. ( 488 2016052400 ; Serial 489 7200 ; Refresh ( 7200 = 2 hours) 490 3600 ; Retry ( 3600 = 1 hour) 491 15724800 ; Expire (15724800 = 6 months) 492 60 ; Minimum 493 ) 494 @ IN NS nameserver.example. 496 @ IN A 192.0.0.170 497 @ IN A 192.0.0.171 498 @ IN AAAA 64:ff9b::192.0.0.170 ; Only for DNS64 server 499 @ IN AAAA 64:ff9b::192.0.0.171 ; Only for DNS64 server 501 The file /var/named/ipv4only-r is created with the following content: 503 $TTL 86400 ; Default TTL 24 hours 504 @ IN SOA nameserver.example. admin.nameserver.example. ( 505 2016052400 ; Serial 506 7200 ; Refresh ( 7200 = 2 hours) 507 3600 ; Retry ( 3600 = 1 hour) 508 15724800 ; Expire (15724800 = 6 months) 509 60 ; Minimum 510 ) 511 @ IN NS nameserver.example. 513 @ IN PTR ipv4only.arpa. 515 Authors' Addresses 517 Stuart Cheshire 518 Apple Inc. 519 1 Infinite Loop 520 Cupertino, California 95014 521 USA 523 Phone: +1 408 974 3207 524 Email: cheshire@apple.com 526 David Schinazi 527 Apple Inc. 528 1 Infinite Loop 529 Cupertino, California 95014 530 USA 532 Phone: +1 669 227 9921 533 Email: dschinazi@apple.com