idnits 2.17.1 draft-cheshire-sudn-ipv4only-dot-arpa-05.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 (October 31, 2016) is 2734 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 October 31, 2016 6 Expires: May 4, 2017 8 Special Use Domain Name 'ipv4only.arpa' 9 draft-cheshire-sudn-ipv4only-dot-arpa-05 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 July 2016 'ipv4only.arpa' still does not appear as one of 20 the names with special properties that are recorded in the Special- 21 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 4, 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 July 2016 'ipv4only.arpa' still does not appear as one of 68 the names with special properties that are recorded in the Special- 69 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. 231 The name 'ipv4only.arpa' is special only to 232 (a) client software wishing to perform DNS64 address synthesis, and 233 (b) the DNS64 recursive/caching server responding to such requests. 234 These two considerations are listed in items 2 and 4 below: 236 1. Normal users should never have reason to encounter the 237 'ipv4only.arpa' domain name. If they do, they should expect 238 queries for 'ipv4only.arpa' to result in the answers required by 239 the specification [RFC7050]. Normal users have no need to know 240 that 'ipv4only.arpa' is special. 242 2. Application software may explicitly use the name 'ipv4only.arpa' 243 for NAT64/DNS64 address synthesis, and expect to get the answers 244 required by the specification [RFC7050]. If application software 245 encounters the name 'ipv4only.arpa' in the normal course of 246 handling user input, the application software should resolve that 247 name as usual and need not treat it in any special way. 249 3. Name resolution APIs and libraries MUST NOT recognize 250 'ipv4only.arpa' as special and MUST NOT treat it differently. 251 Name resolution APIs MUST treat this name just as they would any 252 other normal DNS name, and send queries for it to their 253 configured recursive/caching DNS server(s). 254 Failure to honor this requirement would cause failure of 255 the NAT64 Prefix Discovery mechanism [RFC7050]. 257 4. Recursive/caching DNS servers SHOULD recognize 'ipv4only.arpa' as 258 special and SHOULD NOT, by default, attempt to look up NS records 259 for it, or otherwise query authoritative DNS servers in an 260 attempt to resolve this name. Instead, recursive/caching DNS 261 servers SHOULD, by default, act as authoritative and generate 262 immediate responses for all such queries. 264 Traditional recursive/caching DNS servers that act as 265 authoritative for this name MUST generate only the 192.0.0.170 266 and 192.0.0.171 responses for IPv4 address queries 267 (DNS qtype "A"), and a negative ("no error no answer") response 268 for all other query types. 270 All DNS64 recursive/caching DNS servers MUST generate the 271 192.0.0.170 and 192.0.0.171 responses for IPv4 address queries 272 (DNS qtype "A"), the appropriate synthesized IPv6 address record 273 responses for IPv6 address queries (DNS qtype "AAAA"), and a 274 negative ("no error no answer") response for all other query 275 types. 277 This local self-contained generation of these responses is to 278 avoid placing unnecessary load on the authoritative 'arpa' name 279 servers. 281 Example configurations for BIND 9 showing how to achieve these 282 results are given in Appendix A. 284 5. Traditional authoritative DNS server software need not recognize 285 'ipv4only.arpa' as special or handle it in any special way. 286 Recursive/caching DNS servers SHOULD routinely act as 287 authoritative for this name and return the results described 288 above. Only the administrators of the 'arpa' namespace need to 289 explicitly configure their actual authoritative name servers to 290 be authoritative for this name and to generate the appropriate 291 answers; all other authoritative name servers will not be 292 configured to know anything about this name and will reject 293 queries for it, as they would reject queries for any other name 294 about which they have no information. 296 6. Generally speaking, operators of authoritative DNS servers need 297 not know anything about the name 'ipv4only.arpa', just as they 298 don't need to know anything about any other names they are not 299 responsible for. Operators of authoritative DNS servers who are 300 configuring their name servers to be authoritative for this name 301 MUST understand that 'ipv4only.arpa' is a special name, with 302 records rigidly specified by Internet Standard (generally this 303 applies only to the administrators of the 'arpa' namespace). 305 7. DNS Registries/Registrars need not know anything about the name 306 'ipv4only.arpa', just as they don't need to know anything about 307 any other name they are not responsible for. Only the 308 administrators of the 'arpa' namespace need to be aware of this 309 name's purpose and how it should be configured. 311 6.3. 170.0.0.192.in-addr.arpa and 171.0.0.192.in-addr.arpa 313 Since the IPv4 addresses 192.0.0.170 and 192.0.0.171 are defined to 314 be special, and are listed in the IPv4 Special-Purpose Address 315 Registry [SUv4], the corresponding reverse mapping names in the 316 in-addr.arpa domain are similarly special. 318 The name '170.0.0.192.in-addr.arpa' is defined, by Internet Standard, 319 to have only a single DNS record, type PTR, with rdata 320 'ipv4only.arpa'. 322 The name '171.0.0.192.in-addr.arpa' is defined, by Internet Standard, 323 to have only a single DNS record, type PTR, with rdata 324 'ipv4only.arpa'. 326 Practically speaking these two names are rarely used, but to the 327 extent that they may be, they are special only to recursive/caching 328 DNS servers as described in item 4 below: 330 1. Normal users should never have reason to encounter these two 331 reverse mapping names. However, if they do, queries for these 332 reverse mapping names should return the expected answer 333 'ipv4only.arpa'. Normal users have no need to know that these 334 reverse mapping names are special. 336 2. Application software SHOULD NOT recognize these two reverse 337 mapping names as special, and SHOULD NOT treat them differently. 338 For example, if the user were to issue the Unix command 339 "host 192.0.0.170" then the "host" command should issue the query 340 as usual and display the result that is returned. 342 3. Name resolution APIs and libraries MUST NOT recognize these two 343 reverse mapping names as special and MUST NOT treat them 344 differently. Name resolution APIs MUST treat these names just as 345 they would any other normal DNS name, and send queries for them 346 to their configured recursive/caching DNS server(s). 348 4. Recursive/caching DNS servers SHOULD recognize these two reverse 349 mapping names as special and SHOULD NOT, by default, attempt to 350 look up NS records for them, or otherwise query authoritative DNS 351 servers in an attempt to resolve them. Instead, recursive/ 352 caching DNS servers SHOULD, by default, act as authoritative and 353 generate immediate responses for all such queries. Recursive/ 354 caching DNS servers that do this MUST generate only the 355 'ipv4only.arpa' response for PTR queries, and a negative ("no 356 error no answer") response for all other query types. This local 357 generation of these responses is to avoid placing unnecessary 358 load on the authoritative 'in-addr.arpa' name servers. 360 5. Traditional authoritative DNS server software need not recognize 361 these two reverse mapping names as special or handle them in any 362 special way. 363 As a practical matter, only the administrators of the 364 '192.in-addr.arpa' namespace will configure their name servers to 365 be authoritative for these names and to generate the appropriate 366 answers; all other authoritative name servers will not be 367 configured to know anything about these names and will reject 368 queries for them as they would reject queries for any other name 369 about which they have no information. 371 6. Generally speaking, operators of authoritative DNS servers need 372 not know anything about these two reverse mapping names, just as 373 they don't need to know anything about any other names they are 374 not responsible for. Operators of authoritative DNS servers who 375 are configuring their name servers to be authoritative for this 376 name MUST understand that these two reverse mapping names are 377 special, with answers specified by Internet Standard (generally 378 this applies only to the administrators of the '192.in-addr.arpa' 379 namespace). 381 7. DNS Registries/Registrars need not know anything about these two 382 reverse mapping names, just as they don't need to know anything 383 about any other name they are not responsible for. Only the 384 administrators of the '192.in-addr.arpa' namespace need to be 385 aware of the purpose of these two names. 387 6.4. ip6.arpa Reverse Mapping PTR Records 389 For all IPv6 addresses synthesized by the NAT64 gateway, the DNS64 390 recursive/caching server is responsible for synthesizing the 391 appropriate ip6.arpa reverse mapping PTR records, if it chooses to do 392 so. The same applies to the synthesized IPv6 addresses corresponding 393 to the IPv4 addresses 192.0.0.170 and 192.0.0.171. 395 Generally a DNS64 recursive/caching server synthesizes appropriate 396 ip6.arpa reverse mapping PTR records by extracting the embedded IPv4 397 address from the encoded IPv6 address, performing a reverse mapping 398 query for that IPv4 address, and then synthesizing a corresponding 399 ip6.arpa reverse mapping PTR record containing the same rdata. 401 In the case of synthesized IPv6 addresses corresponding to the IPv4 402 addresses 192.0.0.170 and 192.0.0.171, the DNS64 recursive/caching 403 server does not issue reverse mapping queries for those IPv4 404 addresses, but instead, according to rule 3 above, immediately 405 returns the answer 'ipv4only.arpa'. 407 7. Acknowledgements 409 Thanks to Jouni Korhonen, Teemu Savolainen, and Dan Wing, for 410 devising the NAT64 Prefix Discovery mechanism [RFC7050], and for 411 their feedback on this document. Thanks to Erik Kline for pointing 412 out that the in-addr.arpa names are special too. Thanks particularly 413 to Lorenzo Colitti for an especially spirited hallway discussion at 414 IETF 96 in Berlin, which lead directly to significant improvements in 415 how this document explained the issues. 417 8. References 419 8.1. Normative References 421 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 422 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 423 RFC2119, March 1997, 424 . 426 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 427 NAT64: Network Address and Protocol Translation from IPv6 428 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 429 April 2011, . 431 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 432 Beijnum, "DNS64: DNS Extensions for Network Address 433 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 434 DOI 10.17487/RFC6147, April 2011, 435 . 437 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 438 RFC 6761, DOI 10.17487/RFC6761, February 2013, 439 . 441 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 442 the IPv6 Prefix Used for IPv6 Address Synthesis", 443 RFC 7050, DOI 10.17487/RFC7050, November 2013, 444 . 446 8.2. Informative References 448 [SUDN] "Special-Use Domain Names Registry", . 451 [SUv4] "IANA IPv4 Special-Purpose Address Registry", . 454 Appendix A. Example BIND 9 Configuration 456 A BIND 9 recursive/caching DNS server could be configured to act as 457 authoritative for the appropriate names as follows. 459 In /etc/named.conf the following lines are added: 461 zone "ipv4only.arpa" { type master; file "ipv4only"; }; 462 zone "170.0.0.192.in-addr.arpa" { type master; file "ipv4only-r"; }; 463 zone "171.0.0.192.in-addr.arpa" { type master; file "ipv4only-r"; }; 465 The file /var/named/ipv4only is created with the following content. 466 (The lines marked "Only for DNS64 server" are omitted on a standard 467 recursive/caching DNS server.) 469 $TTL 86400 ; Default TTL 24 hours 470 @ IN SOA nameserver.example. admin.nameserver.example. ( 471 2016052400 ; Serial 472 7200 ; Refresh ( 7200 = 2 hours) 473 3600 ; Retry ( 3600 = 1 hour) 474 15724800 ; Expire (15724800 = 6 months) 475 60 ; Minimum 476 ) 477 @ IN NS nameserver.example. 479 @ IN A 192.0.0.170 480 @ IN A 192.0.0.171 481 @ IN AAAA 64:ff9b::192.0.0.170 ; Only for DNS64 server 482 @ IN AAAA 64:ff9b::192.0.0.171 ; Only for DNS64 server 484 The file /var/named/ipv4only-r is created with the following content: 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 PTR ipv4only.arpa. 498 Authors' Addresses 500 Stuart Cheshire 501 Apple Inc. 502 1 Infinite Loop 503 Cupertino, California 95014 504 USA 506 Phone: +1 408 974 3207 507 Email: cheshire@apple.com 509 David Schinazi 510 Apple Inc. 511 1 Infinite Loop 512 Cupertino, California 95014 513 USA 515 Phone: +1 669 227 9921 516 Email: dschinazi@apple.com