idnits 2.17.1 draft-cheshire-sudn-ipv4only-dot-arpa-04.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 30, 2016) is 2706 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 30, 2016 6 Expires: May 3, 2017 8 Special Use Domain Name 'ipv4only.arpa' 9 draft-cheshire-sudn-ipv4only-dot-arpa-04 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 3, 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 SHOULD NOT recognize 250 'ipv4only.arpa' as special and SHOULD NOT treat it differently. 251 Name resolution APIs SHOULD send queries for this name to their 252 configured recursive/caching DNS server(s). 254 4. Recursive/caching DNS servers SHOULD recognize 'ipv4only.arpa' as 255 special and SHOULD NOT, by default, attempt to look up NS records 256 for it, or otherwise query authoritative DNS servers in an 257 attempt to resolve this name. Instead, recursive/caching DNS 258 servers SHOULD, by default, act as authoritative and generate 259 immediate responses for all such queries. 261 Traditional recursive/caching DNS servers that act as 262 authoritative for this name MUST generate only the 192.0.0.170 263 and 192.0.0.171 responses for IPv4 address queries 264 (DNS qtype "A"), and a negative ("no error no answer") response 265 for all other query types. 267 All DNS64 recursive/caching DNS servers MUST generate the 268 192.0.0.170 and 192.0.0.171 responses for IPv4 address queries 269 (DNS qtype "A"), the appropriate synthesized IPv6 address record 270 responses for IPv6 address queries (DNS qtype "AAAA"), and a 271 negative ("no error no answer") response for all other query 272 types. 274 This local self-contained generation of these responses is to 275 avoid placing unnecessary load on the authoritative 'arpa' name 276 servers. 278 Example configurations for BIND 9 showing how to achieve these 279 results are given in Appendix A. 281 5. Traditional authoritative DNS server software need not recognize 282 'ipv4only.arpa' as special or handle it in any special way. 283 Recursive/caching DNS servers SHOULD routinely act as 284 authoritative for this name and return the results described 285 above. Only the administrators of the 'arpa' namespace need to 286 explicitly configure their actual authoritative name servers to 287 be authoritative for this name and to generate the appropriate 288 answers; all other authoritative name servers will not be 289 configured to know anything about this name and will reject 290 queries for it, as they would reject queries for any other name 291 about which they have no information. 293 6. Generally speaking, operators of authoritative DNS servers need 294 not know anything about the name 'ipv4only.arpa', just as they 295 don't need to know anything about any other names they are not 296 responsible for. Operators of authoritative DNS servers who are 297 configuring their name servers to be authoritative for this name 298 MUST understand that 'ipv4only.arpa' is a special name, with 299 records rigidly specified by Internet Standard (generally this 300 applies only to the administrators of the 'arpa' namespace). 302 7. DNS Registries/Registrars need not know anything about the name 303 'ipv4only.arpa', just as they don't need to know anything about 304 any other name they are not responsible for. Only the 305 administrators of the 'arpa' namespace need to be aware of this 306 name's purpose and how it should be configured. 308 6.3. 170.0.0.192.in-addr.arpa and 171.0.0.192.in-addr.arpa 310 Since the IPv4 addresses 192.0.0.170 and 192.0.0.171 are defined to 311 be special, and are listed in the IPv4 Special-Purpose Address 312 Registry [SUv4], the corresponding reverse mapping names in the 313 in-addr.arpa domain are similarly special. 315 The name '170.0.0.192.in-addr.arpa' is defined, by Internet Standard, 316 to have only a single DNS record, type PTR, with rdata 317 'ipv4only.arpa'. 319 The name '171.0.0.192.in-addr.arpa' is defined, by Internet Standard, 320 to have only a single DNS record, type PTR, with rdata 321 'ipv4only.arpa'. 323 Practically speaking these two names are rarely used, but to the 324 extent that they may be, they are special only to recursive/caching 325 DNS servers as described in item 4 below: 327 1. Normal users should never have reason to encounter these two 328 reverse mapping names. However, if they do, queries for these 329 reverse mapping names should return the expected answer 330 'ipv4only.arpa'. Normal users have no need to know that these 331 reverse mapping names are special. 333 2. Application software SHOULD NOT recognize these two reverse 334 mapping names as special, and SHOULD NOT treat them differently. 335 For example, if the user were to issue the Unix command 336 "host 192.0.0.170" then the "host" command should issue the query 337 as usual and display the result that is returned. 339 3. Name resolution APIs and libraries SHOULD NOT recognize these two 340 reverse mapping names as special and SHOULD NOT treat them 341 differently. Name resolution APIs SHOULD send queries for these 342 names to their configured recursive/caching DNS server(s). 344 4. Recursive/caching DNS servers SHOULD recognize these two reverse 345 mapping names as special and SHOULD NOT, by default, attempt to 346 look up NS records for them, or otherwise query authoritative DNS 347 servers in an attempt to resolve them. Instead, recursive/ 348 caching DNS servers SHOULD, by default, act as authoritative and 349 generate immediate responses for all such queries. 351 Recursive/caching DNS servers that act as authoritative for these 352 names MUST generate only the 'ipv4only.arpa' response for PTR 353 queries, and a negative ("no error no answer") response for all 354 other query types. This local self-contained generation of these 355 responses is to avoid placing unnecessary load on the 356 authoritative 'in-addr.arpa' name servers. 358 5. Traditional authoritative DNS server software need not recognize 359 these two reverse mapping names as special or handle them in any 360 special way. 361 As a practical matter, only the administrators of the 362 '192.in-addr.arpa' namespace will configure their name servers to 363 be authoritative for these names and to generate the appropriate 364 answers; all other authoritative name servers will not be 365 configured to know anything about these names and will reject 366 queries for them as they would reject queries for any other name 367 about which they have no information. 369 6. Generally speaking, operators of authoritative DNS servers need 370 not know anything about these two reverse mapping names, just as 371 they don't need to know anything about any other names they are 372 not responsible for. Operators of authoritative DNS servers who 373 are configuring their name servers to be authoritative for this 374 name MUST understand that these two reverse mapping names are 375 special, with answers specified by Internet Standard (generally 376 this applies only to the administrators of the '192.in-addr.arpa' 377 namespace). 379 7. DNS Registries/Registrars need not know anything about these two 380 reverse mapping names, just as they don't need to know anything 381 about any other name they are not responsible for. Only the 382 administrators of the '192.in-addr.arpa' namespace need to be 383 aware of the purpose of these two names. 385 6.4. ip6.arpa Reverse Mapping PTR Records 387 For all IPv6 addresses synthesized by the NAT64 gateway, the DNS64 388 recursive/caching server is responsible for synthesizing the 389 appropriate ip6.arpa reverse mapping PTR records, if it chooses to do 390 so. The same applies to the synthesized IPv6 addresses corresponding 391 to the IPv4 addresses 192.0.0.170 and 192.0.0.171. 393 Generally a DNS64 recursive/caching server synthesizes appropriate 394 ip6.arpa reverse mapping PTR records by extracting the embedded IPv4 395 address from the encoded IPv6 address, performing a reverse mapping 396 query for that IPv4 address, and then synthesizing a corresponding 397 ip6.arpa reverse mapping PTR record containing the same rdata. 399 In the case of synthesized IPv6 addresses corresponding to the IPv4 400 addresses 192.0.0.170 and 192.0.0.171, the DNS64 recursive/caching 401 server does not issue mapping queries for those IPv4 addresses, but 402 instead, according to rule 3 above, immediately returns the answer 403 'ipv4only.arpa'. 405 7. References 407 7.1. Normative References 409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 410 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 411 RFC2119, March 1997, 412 . 414 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 415 NAT64: Network Address and Protocol Translation from IPv6 416 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 417 April 2011, . 419 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 420 Beijnum, "DNS64: DNS Extensions for Network Address 421 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 422 DOI 10.17487/RFC6147, April 2011, 423 . 425 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 426 RFC 6761, DOI 10.17487/RFC6761, February 2013, 427 . 429 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 430 the IPv6 Prefix Used for IPv6 Address Synthesis", 431 RFC 7050, DOI 10.17487/RFC7050, November 2013, 432 . 434 7.2. Informative References 436 [SUDN] "Special-Use Domain Names Registry", . 439 [SUv4] "IANA IPv4 Special-Purpose Address Registry", . 442 Appendix A. Example BIND 9 Configuration 444 A BIND 9 recursive/caching DNS server could be configured to act as 445 authoritative for the appropriate names as follows. 447 In /etc/named.conf the following lines are added: 449 zone "ipv4only.arpa" { type master; file "ipv4only"; }; 450 zone "170.0.0.192.in-addr.arpa" { type master; file "ipv4only-r"; }; 451 zone "171.0.0.192.in-addr.arpa" { type master; file "ipv4only-r"; }; 453 The file /var/named/ipv4only is created with the following content. 454 (The lines marked "Only for DNS64 server" are omitted on a standard 455 recursive/caching DNS server.) 457 $TTL 86400 ; Default TTL 24 hours 458 @ IN SOA nameserver.example. admin.nameserver.example. ( 459 2016052400 ; Serial 460 7200 ; Refresh ( 7200 = 2 hours) 461 3600 ; Retry ( 3600 = 1 hour) 462 15724800 ; Expire (15724800 = 6 months) 463 60 ; Minimum 464 ) 465 @ IN NS nameserver.example. 467 @ IN A 192.0.0.170 468 @ IN A 192.0.0.171 469 @ IN AAAA 64:ff9b::192.0.0.170 ; Only for DNS64 server 470 @ IN AAAA 64:ff9b::192.0.0.171 ; Only for DNS64 server 472 The file /var/named/ipv4only-r is created with the following content: 474 $TTL 86400 ; Default TTL 24 hours 475 @ IN SOA nameserver.example. admin.nameserver.example. ( 476 2016052400 ; Serial 477 7200 ; Refresh ( 7200 = 2 hours) 478 3600 ; Retry ( 3600 = 1 hour) 479 15724800 ; Expire (15724800 = 6 months) 480 60 ; Minimum 481 ) 482 @ IN NS nameserver.example. 484 @ IN PTR ipv4only.arpa. 486 Authors' Addresses 488 Stuart Cheshire 489 Apple Inc. 490 1 Infinite Loop 491 Cupertino, California 95014 492 USA 494 Phone: +1 408 974 3207 495 Email: cheshire@apple.com 497 David Schinazi 498 Apple Inc. 499 1 Infinite Loop 500 Cupertino, California 95014 501 USA 503 Phone: +1 669 227 9921 504 Email: dschinazi@apple.com