idnits 2.17.1 draft-cheshire-sudn-ipv4only-dot-arpa-03.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 date (July 18, 2016) is 2832 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 (~~), 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 D. Schinazi 4 Updates: 7050 (if approved) Apple Inc. 5 Intended status: Standards Track July 18, 2016 6 Expires: January 19, 2017 8 Special Use Domain Name 'ipv4only.arpa' 9 draft-cheshire-sudn-ipv4only-dot-arpa-03 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 treats it as a non special name in the document's Domain 16 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 January 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 treats it as a non special name in the document's Domain 64 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. Clients never normally query 94 for the two records that do in fact exist, instead querying for 95 records that are known to not exist, and getting positive answers to 96 those abnormal queries. Clients are using DNS to perform queries for 97 this name, but they are certainly not using DNS to learn legitimate 98 answers from the name's legitimate authoritative server. Instead, 99 clients are using these pseudo-DNS queries as an impromptu middlebox 100 communication protocol, to communicate with the NAT64/DNS64 101 [RFC6146][RFC6147] gateway, if present, and request that it disclose 102 the prefix it is using for IPv6 address synthesis. 104 It is this use of specially-crafted DNS queries for 'ipv4only.arpa' 105 as an impromptu middlebox communication protocol that makes the name 106 'ipv4only.arpa' noteworthy, and legitimately qualifying to be 107 described as a 'special' name. 109 3. Consequences of 'ipv4only.arpa' previously being unspecial 111 As a result of the original specification [RFC7050] not formally 112 declaring 'ipv4only.arpa' to have special properties, there was no 113 mandate for any server software to treat this name specially. 114 Consequently, queries for this name had to be handled normally, 115 resulting in unnecessary queries to the authoritative 'arpa' name 116 servers. 118 Having millions of devices around the world issue these queries 119 generated pointless additional load on the authoritative 'arpa' name 120 servers, which was completely unnecessary when the name 121 'ipv4only.arpa' is defined, by Internet Standard, to have exactly two 122 IPv4 address records, 192.0.0.170 and 192.0.0.171, and no other 123 records of any type. 125 Also, at times, for reasons that are as yet unclear, the 126 authoritative 'arpa' name servers have been observed to be slow or 127 unresponsive. The failures of these 'ipv4only.arpa' queries result 128 in unnecessary failures of software that depends on them for DNS64 129 [RFC6147] address synthesis. 131 Even when the authoritative 'arpa' name servers are operating 132 correctly, having to perform an unnecessary query to obtain an answer 133 that is already known in advance can add precious milliseconds of 134 delay for no reason. 136 This document leverages this operational experience to update the 137 Domain Name Reservation Considerations section [RFC6761] of the 138 earlier specification [RFC7050] with one that accurately lists the 139 actual special properties of the name 'ipv4only.arpa' so that 140 software can legitimately make appropriate performance and 141 reliability optimizations. 143 4. Security Considerations 145 Hard-coding the known answers for 'ipv4only.arpa' queries in 146 recursive/caching DNS servers reduces the risk of malicious devices 147 intercepting those queries and returning incorrect answers, 148 particularly in the case of recursive/caching DNS servers that do not 149 perform DNSSEC validation. 151 One of the known concerns with DNS64 [RFC6147] is that it interferes 152 with DNSSEC. DNSSEC may cryptographically assert that a name has no 153 IPv6 AAAA records, while at the same time DNS64 address synthesis is 154 contradicting this and claiming that IPv6 AAAA records do exist. 156 Section 3 of the DNS64 specification [RFC6147] discusses this: 158 ... DNS64 receives a query with the DO bit set and 159 the CD bit set. In this case, the DNS64 is supposed 160 to pass on all the data it gets to the query initiator. 161 This case will not work with DNS64, unless the 162 validating resolver is prepared to do DNS64 itself. 164 The NAT64 Prefix Discovery specification [RFC7050] provides the 165 mechanism for the query initiator to learn the NAT64 prefix so that 166 it can do its own validation and DNS64 synthesis as described above. 167 With this mechanism the client can (i) interrogate the local NAT64/ 168 DNS64 gateway with an 'ipv4only.arpa' query to learn the IPv6 address 169 synthesis prefix, (ii) query for the (signed) IPv4 address records 170 itself, and then (iii) perform its own IPv6 address synthesis 171 locally, combining the IPv6 address synthesis prefix learned from the 172 local NAT64/DNS64 gateway with the secure DNSSEC-signed data learned 173 from the global Domain Name System. 175 It is conceivable that over time, if DNSSEC is successful, the 176 majority of clients could move to this validate-and-synthesize- 177 locally model, which reduces the DNS64 machinery to the vestigial 178 role of simply responding to the 'ipv4only.arpa' query to report the 179 local IPv6 address synthesis prefix. In no case does the client care 180 what answer(s) the authoritative 'arpa' name servers might give for 181 that query. The 'ipv4only.arpa' query is being used purely as a 182 local client-to-middlebox communication message. 184 This approach is even more attractive if it doesn't create an 185 additional dependency on the authoritative 'arpa' name servers to 186 answer a query that is unnecessary because the NAT64/DNS64 gateway 187 already knows the answer before it even issues the query. Avoiding 188 this unnecessary query improves performance and reliability for the 189 client, and reduces unnecessary load for the authoritative 'arpa' 190 name servers. 192 5. IANA Considerations 194 [Once published, this should say] 196 IANA has recorded the following names in the 197 Special-Use Domain Names registry [SUDN]: 198 ipv4only.arpa. 199 170.0.0.192.in-addr.arpa. 200 171.0.0.192.in-addr.arpa. 202 IANA has recorded the following IPv4 addresses in the 203 IPv4 Special-Purpose Address Registry [SUv4]: 204 192.0.0.170 205 192.0.0.171 207 6. Domain Name Reservation Considerations 209 6.1. Conventions and Terminology Used in this Section 211 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 212 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 213 "OPTIONAL" in this document are to be interpreted as described in 214 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 216 6.2. ipv4only.arpa 218 The name 'ipv4only.arpa' is defined, by Internet Standard, to have 219 two IPv4 address records with rdata 192.0.0.170 and 192.0.0.171. 221 When queried via a DNS64 [RFC6147] recursive/caching server, the name 222 'ipv4only.arpa' is also defined to have IPv6 AAAA records, with rdata 223 synthesized from a combination of the NAT64 IPv6 prefix(es), and the 224 IPv4 addresses 192.0.0.170 and 192.0.0.171. This can return more 225 than one pair of IPv6 addresses if there are multiple NAT64 prefixes. 227 The name 'ipv4only.arpa' has no other DNS records of any type. 229 The name 'ipv4only.arpa' is special only to 230 (a) client software wishing to perform DNS64 address synthesis, and 231 (b) the DNS64 recursive/caching server responding to such requests. 232 These two considerations are listed in items 2 and 4 below: 234 1. Normal users should never have reason to encounter the 235 'ipv4only.arpa' domain name. If they do, they should expect 236 queries for 'ipv4only.arpa' to result in the answers required by 237 the specification [RFC7050]. Normal users have no need to know 238 that 'ipv4only.arpa' is special. 240 2. Application software may explicitly use the name 'ipv4only.arpa' 241 for NAT64/DNS64 address synthesis, and expect to get the answers 242 required by the specification [RFC7050]. If application software 243 encounters the name 'ipv4only.arpa' in the normal course of 244 handling user input, the application software should resolve that 245 name as usual and need not treat it in any special way. 247 3. Name resolution APIs and libraries SHOULD NOT recognize 248 'ipv4only.arpa' as special and SHOULD NOT treat it differently. 249 Name resolution APIs SHOULD send queries for this name to their 250 configured recursive/caching DNS server(s). 252 4. Recursive/caching DNS servers SHOULD recognize 'ipv4only.arpa' as 253 special and SHOULD NOT, by default, attempt to look up NS records 254 for it, or otherwise query authoritative DNS servers in an 255 attempt to resolve this name. Instead, recursive/caching DNS 256 servers SHOULD, by default, act as authoritative and generate 257 immediate responses for all such queries. 259 Traditional recursive/caching DNS servers that act as 260 authoritative for this name MUST generate only the 192.0.0.170 261 and 192.0.0.171 responses for IPv4 address queries (DNS qtype 262 "A"), and a "no error no answer" response for all other query 263 types. 265 All DNS64 recursive/caching DNS servers MUST generate the 266 192.0.0.170 and 192.0.0.171 responses for IPv4 address queries 267 (DNS qtype "A"), the appropriate synthesized IPv6 address record 268 responses for IPv6 address queries (DNS qtype "AAAA"), and a 269 "no error no answer" response for all other query types. 270 This local self-contained generation of these responses is to 271 avoid placing unnecessary load on the authoritative 'arpa' name 272 servers. 274 Example configurations for BIND 9 showing how to achieve these 275 results are given in Appendix A. 277 5. Traditional authoritative DNS server software need not recognize 278 'ipv4only.arpa' as special or handle it in any special way. 279 Recursive/caching DNS servers SHOULD routinely act as 280 authoritative for this name and return the results described 281 above. Only the administrators of the 'arpa' namespace need to 282 explicitly configure their actual authoritative name servers to 283 be authoritative for this name and to generate the appropriate 284 answers; all other authoritative name servers will not be 285 configured to know anything about this name and will reject 286 queries for it as they would reject queries for any other name 287 about which they have no information. 289 6. Generally speaking, operators of authoritative DNS servers need 290 not know anything about the name 'ipv4only.arpa', just as they 291 don't need to know anything about any other names they are not 292 responsible for. Operators of authoritative DNS servers who are 293 configuring their name servers to be authoritative for this name 294 MUST understand that 'ipv4only.arpa' is a special name, with 295 records rigidly specified by Internet Standard (generally this 296 applies only to the administrators of the 'arpa' namespace). 298 7. DNS Registries/Registrars need not know anything about the name 299 'ipv4only.arpa', just as they don't need to know anything about 300 any other name they are not responsible for. Only the 301 administrators of the 'arpa' namespace need to be aware of this 302 name's purpose and how it should be configured. 304 6.3. 170.0.0.192.in-addr.arpa and 171.0.0.192.in-addr.arpa 306 Since the IPv4 addresses 192.0.0.170 and 192.0.0.171 are defined to 307 be special, and are listed in the IPv4 Special-Purpose Address 308 Registry [SUv4], the corresponding reverse mapping names in the 309 in-addr.arpa domain are similarly special. 311 The name '170.0.0.192.in-addr.arpa' is defined, by Internet Standard, 312 to have only a single DNS record, type PTR, with rdata 313 'ipv4only.arpa'. 315 The name '171.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 Practically speaking these two names are rarely used, but to the 320 extent that they may be, they are special only to recursive/caching 321 DNS servers as described in item 4 below: 323 1. Normal users should never have reason to encounter these two 324 reverse mapping names. However, if they do, queries for these 325 reverse mapping names should return the expected answer 326 'ipv4only.arpa'. Normal users have no need to know that these 327 reverse mapping names are special. 329 2. Application software SHOULD NOT recognize these two reverse 330 mapping names as special, and SHOULD NOT treat them differently. 331 For example, if the user were to issue the Unix command 332 "host 192.0.0.170" then the "host" command should issue the query 333 as usual and display the result that is returned. 335 3. Name resolution APIs and libraries SHOULD NOT recognize these two 336 reverse mapping names as special and SHOULD NOT treat them 337 differently. Name resolution APIs SHOULD send queries for these 338 names to their configured recursive/caching DNS server(s). 340 4. Recursive/caching DNS servers SHOULD recognize these two reverse 341 mapping names as special and SHOULD NOT, by default, attempt to 342 look up NS records for them, or otherwise query authoritative DNS 343 servers in an attempt to resolve them. Instead, recursive/ 344 caching DNS servers SHOULD, by default, act as authoritative and 345 generate immediate responses for all such queries. 347 Recursive/caching DNS servers that act as authoritative for these 348 names MUST generate only the 'ipv4only.arpa' response for PTR 349 queries, and a "no error no answer" response for all other query 350 types. This local self-contained generation of these responses 351 is to avoid placing unnecessary load on the authoritative 352 'in-addr.arpa' name servers. 354 5. Traditional authoritative DNS server software need not recognize 355 these two reverse mapping names as special or handle them in any 356 special way. 357 As a practical matter, only the administrators of the 358 'in-addr.arpa' namespace will configure their name servers to be 359 authoritative for these names and to generate the appropriate 360 answers; all other authoritative name servers will not be 361 configured to know anything about these names and will reject 362 queries for them as they would reject queries for any other name 363 about which they have no information. 365 6. Generally speaking, operators of authoritative DNS servers need 366 not know anything about these two reverse mapping names, just as 367 they don't need to know anything about any other names they are 368 not responsible for. Operators of authoritative DNS servers who 369 are configuring their name servers to be authoritative for this 370 name MUST understand that these two reverse mapping names are 371 special, with answers specified by Internet Standard (generally 372 this applies only to the administrators of the 'in-addr.arpa' 373 namespace). 375 7. DNS Registries/Registrars need not know anything about these two 376 reverse mapping names, just as they don't need to know anything 377 about any other name they are not responsible for. Only the 378 administrators of the 'in-addr.arpa' namespace need to be aware 379 of the purpose of these two names. 381 6.4. ip6.arpa Reverse Mapping PTR Records 383 For all IPv6 addresses synthesized by the NAT64 gateway, the DNS64 384 recursive/caching server is responsible for synthesizing the 385 appropriate ip6.arpa reverse mapping PTR records, if it chooses to do 386 so. The same applies to the synthesized IPv6 addresses corresponding 387 to the IPv4 addresses 192.0.0.170 and 192.0.0.171. 389 Generally a DNS64 recursive/caching server synthesizes appropriate 390 ip6.arpa reverse mapping PTR records by extracting the embedded IPv4 391 address from the encoded IPv6 address, performing a reverse mapping 392 query for that IPv4 address, and then synthesizing a corresponding 393 ip6.arpa reverse mapping PTR record containing the same rdata. 395 In the case of synthesized IPv6 addresses corresponding to the IPv4 396 addresses 192.0.0.170 and 192.0.0.171, the DNS64 recursive/caching 397 server does not issue mapping queries for those IPv4 addresses, but 398 instead, according to rule 3 above, immediately returns the answer 399 'ipv4only.arpa'. 401 7. References 403 7.1. Normative References 405 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 406 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 407 RFC2119, March 1997, 408 . 410 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 411 NAT64: Network Address and Protocol Translation from IPv6 412 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 413 April 2011, . 415 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 416 Beijnum, "DNS64: DNS Extensions for Network Address 417 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 418 DOI 10.17487/RFC6147, April 2011, 419 . 421 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 422 RFC 6761, DOI 10.17487/RFC6761, February 2013, 423 . 425 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 426 the IPv6 Prefix Used for IPv6 Address Synthesis", 427 RFC 7050, DOI 10.17487/RFC7050, November 2013, 428 . 430 7.2. Informative References 432 [SUDN] "Special-Use Domain Names Registry", . 435 [SUv4] "IANA IPv4 Special-Purpose Address Registry", . 438 Appendix A. Example BIND 9 Configuration 440 A BIND 9 recursive/caching DNS server could be configured to act as 441 authoritative for the appropriate names as follows. 443 In /etc/named.conf the following lines are added: 445 zone "ipv4only.arpa" { type master; file "ipv4only"; }; 446 zone "170.0.0.192.in-addr.arpa" { type master; file "ipv4only-r"; }; 447 zone "171.0.0.192.in-addr.arpa" { type master; file "ipv4only-r"; }; 449 The file /var/named/ipv4only is created with the following content. 450 (The lines marked "Only for DNS64 server" are omitted on a standard 451 recursive/caching DNS server.) 453 $TTL 86400 ; Default TTL 24 hours 454 @ IN SOA nameserver.example. admin.nameserver.example. ( 455 2016052400 ; Serial 456 7200 ; Refresh ( 7200 = 2 hours) 457 3600 ; Retry ( 3600 = 1 hour) 458 15724800 ; Expire (15724800 = 6 months) 459 60 ; Minimum 460 ) 461 @ IN NS nameserver.example. 463 @ IN A 192.0.0.170 464 @ IN A 192.0.0.171 465 @ IN AAAA 64:ff9b::192.0.0.170 ; Only for DNS64 server 466 @ IN AAAA 64:ff9b::192.0.0.171 ; Only for DNS64 server 468 The file /var/named/ipv4only-r is created with the following content: 470 $TTL 86400 ; Default TTL 24 hours 471 @ IN SOA nameserver.example. admin.nameserver.example. ( 472 2016052400 ; Serial 473 7200 ; Refresh ( 7200 = 2 hours) 474 3600 ; Retry ( 3600 = 1 hour) 475 15724800 ; Expire (15724800 = 6 months) 476 60 ; Minimum 477 ) 478 @ IN NS nameserver.example. 480 @ IN PTR ipv4only.arpa. 482 Authors' Addresses 484 Stuart Cheshire 485 Apple Inc. 486 1 Infinite Loop 487 Cupertino, California 95014 488 USA 490 Phone: +1 408 974 3207 491 Email: cheshire@apple.com 493 David Schinazi 494 Apple Inc. 495 1 Infinite Loop 496 Cupertino, California 95014 497 USA 499 Phone: +1 669 227 9921 500 Email: dschinazi@apple.com