idnits 2.17.1 draft-ietf-dnsop-ipv6-dns-issues-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1331. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1342. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1349. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1355. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 19, 2005) is 6757 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) == Unused Reference: 'I-D.huitema-v6ops-teredo' is defined on line 1011, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dnsop-inaddr-required' is defined on line 1041, but no explicit reference was found in the text == Unused Reference: 'I-D.jeong-dnsop-ipv6-dns-discovery' is defined on line 1061, but no explicit reference was found in the text == Unused Reference: 'RFC2766' is defined on line 1071, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-dnsop-ipv6-dns-configuration (ref. 'I-D.ietf-dnsop-ipv6-dns-configuration') ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 3152 (Obsoleted by RFC 3596) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 3363 ** Downref: Normative reference to an Informational RFC: RFC 3364 ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 4038 ** Downref: Normative reference to an Informational RFC: RFC 4074 ** Downref: Normative reference to an Informational RFC: RFC 4192 == Outdated reference: A later version (-01) exists of draft-durand-dnsop-dont-publish-00 == Outdated reference: A later version (-07) exists of draft-huston-6to4-reverse-dns-03 == Outdated reference: A later version (-12) exists of draft-ietf-dhc-ddns-resolution-10 == Outdated reference: A later version (-13) exists of draft-ietf-dhc-fqdn-option-11 == Outdated reference: A later version (-13) exists of draft-ietf-dnsext-dhcid-rr-10 == Outdated reference: A later version (-06) exists of draft-ietf-dnsop-bad-dns-res-04 == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-natpt-to-exprmntl-02 == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-onlinkassumption-03 == Outdated reference: A later version (-12) exists of draft-jeong-dnsop-ipv6-dns-discovery-05 -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) -- Duplicate reference: RFC2181, mentioned in 'TC-TEST', was also mentioned in 'RFC2181'. Summary: 17 errors (**), 0 flaws (~~), 15 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Operations WG A. Durand 3 Internet-Draft Comcast 4 Expires: April 22, 2006 J. Ihren 5 Autonomica 6 P. Savola 7 CSC/FUNET 8 October 19, 2005 10 Operational Considerations and Issues with IPv6 DNS 11 draft-ietf-dnsop-ipv6-dns-issues-12.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 22, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This memo presents operational considerations and issues with IPv6 45 Domain Name System (DNS), including a summary of special IPv6 46 addresses, documentation of known DNS implementation misbehaviour, 47 recommendations and considerations on how to perform DNS naming for 48 service provisioning and for DNS resolver IPv6 support, 49 considerations for DNS updates for both the forward and reverse 50 trees, and miscellaneous issues. This memo is aimed to include a 51 summary of information about IPv6 DNS considerations for those who 52 have experience with IPv4 DNS. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1. Representing IPv6 Addresses in DNS Records . . . . . . . . 4 58 1.2. Independence of DNS Transport and DNS Records . . . . . . 4 59 1.3. Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . 5 60 1.4. Query Type '*' and A/AAAA Records . . . . . . . . . . . . 5 61 2. DNS Considerations about Special IPv6 Addresses . . . . . . . 5 62 2.1. Limited-scope Addresses . . . . . . . . . . . . . . . . . 6 63 2.2. Temporary Addresses . . . . . . . . . . . . . . . . . . . 6 64 2.3. 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 6 65 2.4. Other Transition Mechanisms . . . . . . . . . . . . . . . 6 66 3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 7 67 3.1. Misbehaviour of DNS Servers and Load-balancers . . . . . . 7 68 3.2. Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 7 69 4. Recommendations for Service Provisioning using DNS . . . . . . 8 70 4.1. Use of Service Names instead of Node Names . . . . . . . . 8 71 4.2. Separate vs the Same Service Names for IPv4 and IPv6 . . . 8 72 4.3. Adding the Records Only when Fully IPv6-enabled . . . . . 9 73 4.4. The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 10 74 4.4.1. TTL With Courtesy Additional Data . . . . . . . . . . 10 75 4.4.2. TTL With Critical Additional Data . . . . . . . . . . 11 76 4.5. IPv6 Transport Guidelines for DNS Servers . . . . . . . . 11 77 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 11 78 5.1. DNS Lookups May Query IPv6 Records Prematurely . . . . . . 11 79 5.2. Obtaining a List of DNS Recursive Resolvers . . . . . . . 13 80 5.3. IPv6 Transport Guidelines for Resolvers . . . . . . . . . 13 81 6. Considerations about Forward DNS Updating . . . . . . . . . . 14 82 6.1. Manual or Custom DNS Updates . . . . . . . . . . . . . . . 14 83 6.2. Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 14 84 7. Considerations about Reverse DNS Updating . . . . . . . . . . 15 85 7.1. Applicability of Reverse DNS . . . . . . . . . . . . . . . 15 86 7.2. Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16 87 7.3. DDNS with Stateless Address Autoconfiguration . . . . . . 17 88 7.4. DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 18 89 7.5. DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 18 90 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 19 91 8.1. NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 19 92 8.2. Renumbering Procedures and Applications' Use of DNS . . . 19 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 94 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 95 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 96 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 97 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21 98 12.2. Informative References . . . . . . . . . . . . . . . . . . 23 99 Appendix A. Unique Local Addressing Considerations for DNS . . . 25 100 Appendix B. Behaviour of Additional Data in IPv4/IPv6 101 Environments . . . . . . . . . . . . . . . . . . . . 25 102 B.1. Description of Additional Data Scenarios . . . . . . . . . 25 103 B.2. Which Additional Data to Keep, If Any? . . . . . . . . . . 27 104 B.3. Discussion of the Potential Problems . . . . . . . . . . . 28 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 106 Intellectual Property and Copyright Statements . . . . . . . . . . 29 108 1. Introduction 110 This memo presents operational considerations and issues with IPv6 111 DNS; it is meant to be an extensive summary and a list of pointers 112 for more information about IPv6 DNS considerations for those with 113 experience with IPv4 DNS. 115 The purpose of this document is to give information about various 116 issues and considerations related to DNS operations with IPv6; it is 117 not meant to be a normative specification or standard for IPv6 DNS. 119 The first section gives a brief overview of how IPv6 addresses and 120 names are represented in the DNS, how transport protocols and 121 resource records (don't) relate, and what IPv4/IPv6 name space 122 fragmentation means and how to avoid it; all of these are described 123 at more length in other documents. 125 The second section summarizes the special IPv6 address types and how 126 they relate to DNS. The third section describes observed DNS 127 implementation misbehaviours which have a varying effect on the use 128 of IPv6 records with DNS. The fourth section lists recommendations 129 and considerations for provisioning services with DNS. The fifth 130 section in turn looks at recommendations and considerations about 131 providing IPv6 support in the resolvers. The sixth and seventh 132 sections describe considerations with forward and reverse DNS 133 updates, respectively. The eighth section introduces several 134 miscellaneous IPv6 issues relating to DNS for which no better place 135 has been found in this memo. Appendix A looks briefly at the 136 requirements for unique local addressing. 138 1.1. Representing IPv6 Addresses in DNS Records 140 In the forward zones, IPv6 addresses are represented using AAAA 141 records. In the reverse zones, IPv6 address are represented using 142 PTR records in the nibble format under the ip6.arpa. tree. See 143 [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152] 144 for background information. 146 In particular one should note that the use of A6 records in the 147 forward tree or Bitlabels in the reverse tree is not recommended 148 [RFC3363]. Using DNAME records is not recommended in the reverse 149 tree in conjunction with A6 records; the document did not mean to 150 take a stance on any other use of DNAME records [RFC3364]. 152 1.2. Independence of DNS Transport and DNS Records 154 DNS has been designed to present a single, globally unique name space 155 [RFC2826]. This property should be maintained, as described here and 156 in Section 1.3. 158 The IP version used to transport the DNS queries and responses is 159 independent of the records being queried: AAAA records can be queried 160 over IPv4, and A records over IPv6. The DNS servers must not make 161 any assumptions about what data to return for Answer and Authority 162 sections based on the underlying transport used in a query. 164 However, there is some debate whether the addresses in Additional 165 section could be selected or filtered using hints obtained from which 166 transport was being used; this has some obvious problems because in 167 many cases the transport protocol does not correlate with the 168 requests, and because a "bad" answer is in a way worse than no answer 169 at all (consider the case where the client is led to believe that a 170 name received in the additional record does not have any AAAA records 171 at all). 173 As stated in [RFC3596]: 175 The IP protocol version used for querying resource records is 176 independent of the protocol version of the resource records; e.g., 177 IPv4 transport can be used to query IPv6 records and vice versa. 179 1.3. Avoiding IPv4/IPv6 Name Space Fragmentation 181 To avoid the DNS name space from fragmenting into parts where some 182 parts of DNS are only visible using IPv4 (or IPv6) transport, the 183 recommendation is to always keep at least one authoritative server 184 IPv4-enabled, and to ensure that recursive DNS servers support IPv4. 185 See DNS IPv6 transport guidelines [RFC3901] for more information. 187 1.4. Query Type '*' and A/AAAA Records 189 QTYPE=* is typically only used for debugging or management purposes; 190 it is worth keeping in mind that QTYPE=* ("ANY" queries) only return 191 any available RRsets, not *all* the RRsets, because the caches do not 192 necessarily have all the RRsets and have no way of guaranteeing that 193 they have all the RRsets. Therefore, to get both A and AAAA records 194 reliably, two separate queries must be made. 196 2. DNS Considerations about Special IPv6 Addresses 198 There are a couple of IPv6 address types which are somewhat special; 199 these are considered here. 201 2.1. Limited-scope Addresses 203 The IPv6 addressing architecture [RFC3513] includes two kinds of 204 local-use addresses: link-local (fe80::/10) and site-local 205 (fec0::/10). The site-local addresses have been deprecated [RFC3879] 206 but are discussed with unique local addresses in Appendix A. 208 Link-local addresses should never be published in DNS (whether in 209 forward or reverse tree), because they have only local (to the 210 connected link) significance [I-D.durand-dnsop-dont-publish]. 212 2.2. Temporary Addresses 214 Temporary addresses defined in RFC3041 [RFC3041] (sometimes called 215 "privacy addresses") use a random number as the interface identifier. 216 Having DNS AAAA records that are updated to always contain the 217 current value of a node's temporary address would defeat the purpose 218 of the mechanism and is not recommended. However, it would still be 219 possible to return a non-identifiable name (e.g., the IPv6 address in 220 hexadecimal format), as described in [RFC3041]. 222 2.3. 6to4 Addresses 224 6to4 [RFC3056] specifies an automatic tunneling mechanism which maps 225 a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. 227 If the reverse DNS population would be desirable (see Section 7.1 for 228 applicability), there are a number of possible ways to do so. 230 The main proposal [I-D.huston-6to4-reverse-dns] aims to design an 231 autonomous reverse-delegation system that anyone being capable of 232 communicating using a specific 6to4 address would be able to set up a 233 reverse delegation to the corresponding 6to4 prefix. This could be 234 deployed by e.g., Regional Internet Registries (RIRs). This is a 235 practical solution, but may have some scalability concerns. 237 2.4. Other Transition Mechanisms 239 6to4 is mentioned as a case of an IPv6 transition mechanism requiring 240 special considerations. In general, mechanisms which include a 241 special prefix may need a custom solution; otherwise, for example 242 when IPv4 address is embedded as the suffix or not embedded at all, 243 special solutions are likely not needed. 245 Note that it does not seem feasible to provide reverse DNS with 246 another automatic tunneling mechanism, Teredo [I-D.huitema-v6ops- 247 teredo]; this is because the IPv6 address is based on the IPv4 248 address and UDP port of the current NAT mapping which is likely to be 249 relatively short-lived. 251 3. Observed DNS Implementation Misbehaviour 253 Several classes of misbehaviour in DNS servers, load-balancers and 254 resolvers have been observed. Most of these are rather generic, not 255 only applicable to IPv6 -- but in some cases, the consequences of 256 this misbehaviour are extremely severe in IPv6 environments and 257 deserve to be mentioned. 259 3.1. Misbehaviour of DNS Servers and Load-balancers 261 There are several classes of misbehaviour in certain DNS servers and 262 load-balancers which have been noticed and documented [RFC4074]: some 263 implementations silently drop queries for unimplemented DNS records 264 types, or provide wrong answers to such queries (instead of a proper 265 negative reply). While typically these issues are not limited to 266 AAAA records, the problems are aggravated by the fact that AAAA 267 records are being queried instead of (mainly) A records. 269 The problems are serious because when looking up a DNS name, typical 270 getaddrinfo() implementations, with AF_UNSPEC hint given, first try 271 to query the AAAA records of the name, and after receiving a 272 response, query the A records. This is done in a serial fashion -- 273 if the first query is never responded to (instead of properly 274 returning a negative answer), significant timeouts will occur. 276 In consequence, this is an enormous problem for IPv6 deployments, and 277 in some cases, IPv6 support in the software has even been disabled 278 due to these problems. 280 The solution is to fix or retire those misbehaving implementations, 281 but that is likely not going to be effective. There are some 282 possible ways to mitigate the problem, e.g., by performing the 283 lookups somewhat in parallel and reducing the timeout as long as at 284 least one answer has been received; but such methods remain to be 285 investigated; slightly more on this is included in Section 5. 287 3.2. Misbehaviour of DNS Resolvers 289 Several classes of misbehaviour have also been noticed in DNS 290 resolvers [I-D.ietf-dnsop-bad-dns-res]. However, these do not seem 291 to directly impair IPv6 use, and are only referred to for 292 completeness. 294 4. Recommendations for Service Provisioning using DNS 296 When names are added in the DNS to facilitate a service, there are 297 several general guidelines to consider to be able to do it as 298 smoothly as possible. 300 4.1. Use of Service Names instead of Node Names 302 It makes sense to keep information about separate services logically 303 separate in the DNS by using a different DNS hostname for each 304 service. There are several reasons for doing this, for example: 306 o It allows more flexibility and ease for migration of (only a part 307 of) services from one node to another, 309 o It allows configuring different properties (e.g., TTL) for each 310 service, and 312 o It allows deciding separately for each service whether to publish 313 the IPv6 addresses or not (in cases where some services are more 314 IPv6-ready than others). 316 Using SRV records [RFC2782] would avoid these problems. 317 Unfortunately, those are not sufficiently widely used to be 318 applicable in most cases. Hence an operation technique is to use 319 service names instead of node names (or, "hostnames"). This 320 operational technique is not specific to IPv6, but required to 321 understand the considerations described in Section 4.2 and 322 Section 4.3. 324 For example, assume a node named "pobox.example.com" provides both 325 SMTP and IMAP service. Instead of configuring the MX records to 326 point at "pobox.example.com", and configuring the mail clients to 327 look up the mail via IMAP from "pobox.example.com", one could use 328 e.g., "smtp.example.com" for SMTP (for both message submission and 329 mail relaying between SMTP servers) and "imap.example.com" for IMAP. 330 Note that in the specific case of SMTP relaying, the server itself 331 must typically also be configured to know all its names to ensure 332 loops do not occur. DNS can provide a layer of indirection between 333 service names and where the service actually is, and using which 334 addresses. (Obviously, when wanting to reach a specific node, one 335 should use the hostname rather than a service name.) 337 4.2. Separate vs the Same Service Names for IPv4 and IPv6 339 The service naming can be achieved in basically two ways: when a 340 service is named "service.example.com" for IPv4, the IPv6-enabled 341 service could either be added to "service.example.com", or added 342 separately under a different name, e.g., in a sub-domain, like, 343 "service.ipv6.example.com". 345 These two methods have different characteristics. Using a different 346 name allows for easier service piloting, minimizing the disturbance 347 to the "regular" users of IPv4 service; however, the service would 348 not be used transparently, without the user/application explicitly 349 finding it and asking for it -- which would be a disadvantage in most 350 cases. When the different name is under a sub-domain, if the 351 services are deployed within a restricted network (e.g., inside an 352 enterprise), it's possible to prefer them transparently, at least to 353 a degree, by modifying the DNS search path; however, this is a 354 suboptimal solution. Using the same service name is the "long-term" 355 solution, but may degrade performance for those clients whose IPv6 356 performance is lower than IPv4, or does not work as well (see 357 Section 4.3 for more). 359 In most cases, it makes sense to pilot or test a service using 360 separate service names, and move to the use of the same name when 361 confident enough that the service level will not degrade for the 362 users unaware of IPv6. 364 4.3. Adding the Records Only when Fully IPv6-enabled 366 The recommendation is that AAAA records for a service should not be 367 added to the DNS until all of following are true: 369 1. The address is assigned to the interface on the node. 371 2. The address is configured on the interface. 373 3. The interface is on a link which is connected to the IPv6 374 infrastructure. 376 In addition, if the AAAA record is added for the node, instead of 377 service as recommended, all the services of the node should be IPv6- 378 enabled prior to adding the resource record. 380 For example, if an IPv6 node is isolated from an IPv6 perspective 381 (e.g., it is not connected to IPv6 Internet) constraint #3 would mean 382 that it should not have an address in the DNS. 384 Consider the case of two dual-stack nodes, which both have IPv6 385 enabled, but the server does not have (global) IPv6 connectivity. As 386 the client looks up the server's name, only A records are returned 387 (if the recommendations above are followed), and no IPv6 388 communication, which would have been unsuccessful, is even attempted. 390 The issues are not always so black-and-white. Usually it's important 391 that the service offered using both protocols is of roughly equal 392 quality, using the appropriate metrics for the service (e.g., 393 latency, throughput, low packet loss, general reliability, etc.) -- 394 this is typically very important especially for interactive or real- 395 time services. In many cases, the quality of IPv6 connectivity may 396 not yet be equal to that of IPv4, at least globally -- this has to be 397 taken into consideration when enabling services. 399 4.4. The Use of TTL for IPv4 and IPv6 RRs 401 The behaviour of DNS caching when different TTL values are used for 402 different RRsets of the same name calls for explicit discussion. For 403 example, let's consider two unrelated zone fragments: 405 example.com. 300 IN MX foo.example.com. 406 foo.example.com. 300 IN A 192.0.2.1 407 foo.example.com. 100 IN AAAA 2001:db8::1 409 ... 411 child.example.com. 300 IN NS ns.child.example.com. 412 ns.child.example.com. 300 IN A 192.0.2.1 413 ns.child.example.com. 100 IN AAAA 2001:db8::1 415 In the former case, we have "courtesy" additional data; in the 416 latter, we have "critical" additional data. See more extensive 417 background discussion of additional data handling in Appendix B. 419 4.4.1. TTL With Courtesy Additional Data 421 When a caching resolver asks for the MX record of example.com, it 422 gets back "foo.example.com". It may also get back either one or both 423 of the A and AAAA records in the additional section. The resolver 424 must explicitly query for both A and AAAA records [RFC2821]. 426 After 100 seconds, the AAAA record is removed from the cache(s) 427 because its TTL expired. It could be argued to be useful for the 428 caching resolvers to discard the A record when the shorter TTL (in 429 this case, for the AAAA record) expires; this would avoid the 430 situation where there would be a window of 200 seconds when 431 incomplete information is returned from the cache. Further argument 432 for discarding is that in the normal operation, the TTL values are so 433 high that very likely the incurred additional queries would not be 434 noticeable, compared to the obtained performance optimization. The 435 behaviour in this scenario is unspecified. 437 4.4.2. TTL With Critical Additional Data 439 The difference to courtesy additional data is that the A/AAAA records 440 served by the parent zone cannot be queried explicitly. Therefore 441 after 100 seconds the AAAA record is removed from the cache(s), but 442 the A record remains. Queries for the remaining 200 seconds 443 (provided that there are no further queries from the parent which 444 could refresh the caches) only return the A record, leading to a 445 potential opererational situation with unreachable servers. 447 Similar cache flushing strategies apply in this scenario; the 448 behaviour is likewise unspecified. 450 4.5. IPv6 Transport Guidelines for DNS Servers 452 As described in Section 1.3 and [RFC3901], there should continue to 453 be at least one authoritative IPv4 DNS server for every zone, even if 454 the zone has only IPv6 records. (Note that obviously, having more 455 servers with robust connectivity would be preferable, but this is the 456 minimum recommendation; also see [RFC2182].) 458 5. Recommendations for DNS Resolver IPv6 Support 460 When IPv6 is enabled on a node, there are several things to consider 461 to ensure that the process is as smooth as possible. 463 5.1. DNS Lookups May Query IPv6 Records Prematurely 465 The system library that implements the getaddrinfo() function for 466 looking up names is a critical piece when considering the robustness 467 of enabling IPv6; it may come in basically three flavours: 469 1. The system library does not know whether IPv6 has been enabled in 470 the kernel of the operating system: it may start looking up AAAA 471 records with getaddrinfo() and AF_UNSPEC hint when the system is 472 upgraded to a system library version which supports IPv6. 474 2. The system library might start to perform IPv6 queries with 475 getaddrinfo() only when IPv6 has been enabled in the kernel. 476 However, this does not guarantee that there exists any useful 477 IPv6 connectivity (e.g., the node could be isolated from the 478 other IPv6 networks, only having link-local addresses). 480 3. The system library might implement a toggle which would apply 481 some heuristics to the "IPv6-readiness" of the node before 482 starting to perform queries; for example, it could check whether 483 only link-local IPv6 address(es) exists, or if at least one 484 global IPv6 address exists. 486 First, let us consider generic implications of unnecessary queries 487 for AAAA records: when looking up all the records in the DNS, AAAA 488 records are typically tried first, and then A records. These are 489 done in serial, and the A query is not performed until a response is 490 received to the AAAA query. Considering the misbehaviour of DNS 491 servers and load-balancers, as described in Section 3.1, the look-up 492 delay for AAAA may incur additional unnecessary latency, and 493 introduce a component of unreliability. 495 One option here could be to do the queries partially in parallel; for 496 example, if the final response to the AAAA query is not received in 497 0.5 seconds, start performing the A query while waiting for the 498 result (immediate parallelism might be unoptimal, at least without 499 information sharing between the look-up threads, as that would 500 probably lead to duplicate non-cached delegation chain lookups). 502 An additional concern is the address selection, which may, in some 503 circumstances, prefer AAAA records over A records even when the node 504 does not have any IPv6 connectivity [I-D.ietf-v6ops-v6onbydefault]. 505 In some cases, the implementation may attempt to connect or send a 506 datagram on a physical link [I-D.ietf-v6ops-onlinkassumption], 507 incurring very long protocol timeouts, instead of quickly failing 508 back to IPv4. 510 Now, we can consider the issues specific to each of the three 511 possibilities: 513 In the first case, the node performs a number of completely useless 514 DNS lookups as it will not be able to use the returned AAAA records 515 anyway. (The only exception is where the application desires to know 516 what's in the DNS, but not use the result for communication.) One 517 should be able to disable these unnecessary queries, for both latency 518 and reliability reasons. However, as IPv6 has not been enabled, the 519 connections to IPv6 addresses fail immediately, and if the 520 application is programmed properly, the application can fall 521 gracefully back to IPv4 [RFC4038]. 523 The second case is similar to the first, except it happens to a 524 smaller set of nodes when IPv6 has been enabled but connectivity has 525 not been provided yet; similar considerations apply, with the 526 exception that IPv6 records, when returned, will be actually tried 527 first which may typically lead to long timeouts. 529 The third case is a bit more complex: optimizing away the DNS lookups 530 with only link-locals is probably safe (but may be desirable with 531 different lookup services which getaddrinfo() may support), as the 532 link-locals are typically automatically generated when IPv6 is 533 enabled, and do not indicate any form of IPv6 connectivity. That is, 534 performing DNS lookups only when a non-link-local address has been 535 configured on any interface could be beneficial -- this would be an 536 indication that either the address has been configured either from a 537 router advertisement, DHCPv6 [RFC3315], or manually. Each would 538 indicate at least some form of IPv6 connectivity, even though there 539 would not be guarantees of it. 541 These issues should be analyzed at more depth, and the fixes found 542 consensus on, perhaps in a separate document. 544 5.2. Obtaining a List of DNS Recursive Resolvers 546 In scenarios where DHCPv6 is available, a host can discover a list of 547 DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server" 548 option [RFC3646]. This option can be passed to a host through a 549 subset of DHCPv6 [RFC3736]. 551 The IETF is considering the development of alternative mechanisms for 552 obtaining the list of DNS recursive name servers when DHCPv6 is 553 unavailable or inappropriate. No decision about taking on this 554 development work has been reached as of this writing (Aug 2004) 555 [I-D.ietf-dnsop-ipv6-dns-configuration]. 557 In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms 558 under consideration for development include the use of well-known 559 addresses [I-D.ohta-preconfigured-dns] and the use of Router 560 Advertisements to convey the information [I-D.jeong-dnsop-ipv6-dns- 561 discovery]. 563 Note that even though IPv6 DNS resolver discovery is a recommended 564 procedure, it is not required for dual-stack nodes in dual-stack 565 networks as IPv6 DNS records can be queried over IPv4 as well as 566 IPv6. Obviously, nodes which are meant to function without manual 567 configuration in IPv6-only networks must implement the DNS resolver 568 discovery function. 570 5.3. IPv6 Transport Guidelines for Resolvers 572 As described in Section 1.3 and [RFC3901], the recursive resolvers 573 should be IPv4-only or dual-stack to be able to reach any IPv4-only 574 DNS server. Note that this requirement is also fulfilled by an IPv6- 575 only stub resolver pointing to a dual-stack recursive DNS resolver. 577 6. Considerations about Forward DNS Updating 579 While the topic of how to enable updating the forward DNS, i.e., the 580 mapping from names to the correct new addresses, is not specific to 581 IPv6, it should be considered especially due to the advent of 582 Stateless Address Autoconfiguration [RFC2462]. 584 Typically forward DNS updates are more manageable than doing them in 585 the reverse DNS, because the updater can often be assumed to "own" a 586 certain DNS name -- and we can create a form of security relationship 587 with the DNS name and the node which is allowed to update it to point 588 to a new address. 590 A more complex form of DNS updates -- adding a whole new name into a 591 DNS zone, instead of updating an existing name -- is considered out 592 of scope for this memo as it could require zone-wide authentication. 593 Adding a new name in the forward zone is a problem which is still 594 being explored with IPv4, and IPv6 does not seem to add much new in 595 that area. 597 6.1. Manual or Custom DNS Updates 599 The DNS mappings can also be maintained by hand, in a semi-automatic 600 fashion or by running non-standardized protocols. These are not 601 considered at more length in this memo. 603 6.2. Dynamic DNS 605 Dynamic DNS updates (DDNS) [RFC2136] [RFC3007] is a standardized 606 mechanism for dynamically updating the DNS. It works equally well 607 with stateless address autoconfiguration (SLAAC), DHCPv6 or manual 608 address configuration. It is important to consider how each of these 609 behave if IP address-based authentication, instead of stronger 610 mechanisms [RFC3007], was used in the updates. 612 1. manual addresses are static and can be configured 614 2. DHCPv6 addresses could be reasonably static or dynamic, depending 615 on the deployment, and could or could not be configured on the 616 DNS server for the long term 618 3. SLAAC addresses are typically stable for a long time, but could 619 require work to be configured and maintained. 621 As relying on IP addresses for Dynamic DNS is rather insecure at 622 best, stronger authentication should always be used; however, this 623 requires that the authorization keying will be explicitly configured 624 using unspecified operational methods. 626 Note that with DHCP it is also possible that the DHCP server updates 627 the DNS, not the host. The host might only indicate in the DHCP 628 exchange which hostname it would prefer, and the DHCP server would 629 make the appropriate updates. Nonetheless, while this makes setting 630 up a secure channel between the updater and the DNS server easier, it 631 does not help much with "content" security, i.e., whether the 632 hostname was acceptable -- if the DNS server does not include 633 policies, they must be included in the DHCP server (e.g., a regular 634 host should not be able to state that its name is "www.example.com"). 635 DHCP-initiated DDNS updates have been extensively described in 636 [I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and 637 [I-D.ietf-dnsext-dhcid-rr]. 639 The nodes must somehow be configured with the information about the 640 servers where they will attempt to update their addresses, sufficient 641 security material for authenticating themselves to the server, and 642 the hostname they will be updating. Unless otherwise configured, the 643 first could be obtained by looking up the authoritative name servers 644 for the hostname; the second must be configured explicitly unless one 645 chooses to trust the IP address-based authentication (not a good 646 idea); and lastly, the nodename is typically pre-configured somehow 647 on the node, e.g., at install time. 649 Care should be observed when updating the addresses not to use longer 650 TTLs for addresses than are preferred lifetimes for the addresses, so 651 that if the node is renumbered in a managed fashion, the amount of 652 stale DNS information is kept to the minimum. That is, if the 653 preferred lifetime of an address expires, the TTL of the record needs 654 be modified unless it was already done before the expiration. For 655 better flexibility, the DNS TTL should be much shorter (e.g., a half 656 or a third) than the lifetime of an address; that way, the node can 657 start lowering the DNS TTL if it seems like the address has not been 658 renewed/refreshed in a while. Some discussion on how an 659 administrator could manage the DNS TTL is included in [RFC4192]; this 660 could be applied to (smart) hosts as well. 662 7. Considerations about Reverse DNS Updating 664 Updating the reverse DNS zone may be difficult because of the split 665 authority over an address. However, first we have to consider the 666 applicability of reverse DNS in the first place. 668 7.1. Applicability of Reverse DNS 670 Today, some applications use reverse DNS to either look up some hints 671 about the topological information associated with an address (e.g. 672 resolving web server access logs), or as a weak form of a security 673 check, to get a feel whether the user's network administrator has 674 "authorized" the use of the address (on the premises that adding a 675 reverse record for an address would signal some form of 676 authorization). 678 One additional, maybe slightly more useful usage is ensuring that the 679 reverse and forward DNS contents match (by looking up the pointer to 680 the name by the IP address from the reverse tree, and ensuring that a 681 record under the name in the forward tree points to the IP address) 682 and correspond to a configured name or domain. As a security check, 683 it is typically accompanied by other mechanisms, such as a user/ 684 password login; the main purpose of the reverse+forward DNS check is 685 to weed out the majority of unauthorized users, and if someone 686 managed to bypass the checks, he would still need to authenticate 687 "properly". 689 It may also be desirable to store IPsec keying material corresponding 690 to an IP address in the reverse DNS, as justified and described in 691 [RFC4025]. 693 It is not clear whether it makes sense to require or recommend that 694 reverse DNS records be updated. In many cases, it would just make 695 more sense to use proper mechanisms for security (or topological 696 information lookup) in the first place. At minimum, the applications 697 which use it as a generic authorization (in the sense that a record 698 exists at all) should be modified as soon as possible to avoid such 699 lookups completely. 701 The applicability is discussed at more length in [I-D.ietf-dnsop- 702 inaddr-required]. 704 7.2. Manual or Custom DNS Updates 706 Reverse DNS can of course be updated using manual or custom methods. 707 These are not further described here, except for one special case. 709 One way to deploy reverse DNS would be to use wildcard records, for 710 example, by configuring one name for a subnet (/64) or a site (/48). 711 As a concrete example, a site (or the site's ISP) could configure the 712 reverses of the prefix 2001:db8:f00::/48 to point to one name using a 713 wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR 714 site.example.com." Naturally, such a name could not be verified from 715 the forward DNS, but would at least provide some form of "topological 716 information" or "weak authorization" if that is really considered to 717 be useful. Note that this is not actually updating the DNS as such, 718 as the whole point is to avoid DNS updates completely by manually 719 configuring a generic name. 721 7.3. DDNS with Stateless Address Autoconfiguration 723 Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in 724 some regard, while being more difficult in another, as described 725 below. 727 The address space administrator decides whether the hosts are trusted 728 to update their reverse DNS records or not. If they are trusted and 729 deployed at the same site (e.g., not across the Internet), a simple 730 address-based authorization is typically sufficient (i.e., check that 731 the DNS update is done from the same IP address as the record being 732 updated); stronger security can also be used [RFC3007]. If they 733 aren't allowed to update the reverses, no update can occur. However, 734 such address-based update authorization operationally requires that 735 ingress filtering [RFC3704] has been set up at the border of the site 736 where the updates occur, and as close to the updater as possible. 738 Address-based authorization is simpler with reverse DNS (as there is 739 a connection between the record and the address) than with forward 740 DNS. However, when a stronger form of security is used, forward DNS 741 updates are simpler to manage because the host can be assumed to have 742 an association with the domain. Note that the user may roam to 743 different networks, and does not necessarily have any association 744 with the owner of that address space -- so, assuming stronger form of 745 authorization for reverse DNS updates than an address association is 746 generally infeasible. 748 Moreover, the reverse zones must be cleaned up by an unspecified 749 janitorial process: the node does not typically know a priori that it 750 will be disconnected, and cannot send a DNS update using the correct 751 source address to remove a record. 753 A problem with defining the clean-up process is that it is difficult 754 to ensure that a specific IP address and the corresponding record are 755 no longer being used. Considering the huge address space, and the 756 unlikelihood of collision within 64 bits of the interface 757 identifiers, a process which would remove the record after no traffic 758 has been seen from a node in a long period of time (e.g., a month or 759 year) might be one possible approach. 761 To insert or update the record, the node must discover the DNS server 762 to send the update to somehow, similar to as discussed in 763 Section 6.2. One way to automate this is looking up the DNS server 764 authoritative (e.g., through SOA record) for the IP address being 765 updated, but the security material (unless the IP address-based 766 authorization is trusted) must also be established by some other 767 means. 769 One should note that Cryptographically Generated Addresses [RFC3972] 770 (CGAs) may require a slightly different kind of treatment. CGAs are 771 addresses where the interface identifier is calculated from a public 772 key, a modifier (used as a nonce), the subnet prefix, and other data. 773 Depending on the usage profile, CGAs might or might not be changed 774 periodically due to e.g., privacy reasons. As the CGA address is not 775 predicatable, a reverse record can only reasonably be inserted in the 776 DNS by the node which generates the address. 778 7.4. DDNS with DHCP 780 With DHCPv4, the reverse DNS name is typically already inserted to 781 the DNS that reflects to the name (e.g., "dhcp-67.example.com"). One 782 can assume similar practice may become commonplace with DHCPv6 as 783 well; all such mappings would be pre-configured, and would require no 784 updating. 786 If a more explicit control is required, similar considerations as 787 with SLAAC apply, except for the fact that typically one must update 788 a reverse DNS record instead of inserting one (if an address 789 assignment policy that reassigns disused addresses is adopted) and 790 updating a record seems like a slightly more difficult thing to 791 secure. However, it is yet uncertain how DHCPv6 is going to be used 792 for address assignment. 794 Note that when using DHCP, either the host or the DHCP server could 795 perform the DNS updates; see the implications in Section 6.2. 797 If disused addresses were to be reassigned, host-based DDNS reverse 798 updates would need policy considerations for DNS record modification, 799 as noted above. On the other hand, if disused address were not to be 800 assigned, host-based DNS reverse updates would have similar 801 considerations as SLAAC in Section 7.3. Server-based updates have 802 similar properties except that the janitorial process could be 803 integrated with DHCP address assignment. 805 7.5. DDNS with Dynamic Prefix Delegation 807 In cases where a prefix, instead of an address, is being used and 808 updated, one should consider what is the location of the server where 809 DDNS updates are made. That is, where the DNS server is located: 811 1. At the same organization as the prefix delegator. 813 2. At the site where the prefixes are delegated to. In this case, 814 the authority of the DNS reverse zone corresponding to the 815 delegated prefix is also delegated to the site. 817 3. Elsewhere; this implies a relationship between the site and where 818 DNS server is located, and such a relationship should be rather 819 straightforward to secure as well. Like in the previous case, 820 the authority of the DNS reverse zone is also delegated. 822 In the first case, managing the reverse DNS (delegation) is simpler 823 as the DNS server and the prefix delegator are in the same 824 administrative domain (as there is no need to delegate anything at 825 all); alternatively, the prefix delegator might forgo DDNS reverse 826 capability altogether, and use e.g., wildcard records (as described 827 in Section 7.2). In the other cases, it can be slighly more 828 difficult, particularly as the site will have to configure the DNS 829 server to be authoritative for the delegated reverse zone, implying 830 automatic configuration of the DNS server -- as the prefix may be 831 dynamic. 833 Managing the DDNS reverse updates is typically simple in the second 834 case, as the updated server is located at the local site, and 835 arguably IP address-based authentication could be sufficient (or if 836 not, setting up security relationships would be simpler). As there 837 is an explicit (security) relationship between the parties in the 838 third case, setting up the security relationships to allow reverse 839 DDNS updates should be rather straightforward as well (but IP 840 address-based authentication might not be acceptable). In the first 841 case, however, setting up and managing such relationships might be a 842 lot more difficult. 844 8. Miscellaneous DNS Considerations 846 This section describes miscellaneous considerations about DNS which 847 seem related to IPv6, for which no better place has been found in 848 this document. 850 8.1. NAT-PT with DNS-ALG 852 The DNS-ALG component of NAT-PT mangles A records to look like AAAA 853 records to the IPv6-only nodes. Numerous problems have been 854 identified with DNS-ALG [I-D.ietf-v6ops-natpt-to-exprmntl]. This is 855 a strong reason not to use NAT-PT in the first place. 857 8.2. Renumbering Procedures and Applications' Use of DNS 859 One of the most difficult problems of systematic IP address 860 renumbering procedures [RFC4192] is that an application which looks 861 up a DNS name disregards information such as TTL, and uses the result 862 obtained from DNS as long as it happens to be stored in the memory of 863 the application. For applications which run for a long time, this 864 could be days, weeks or even months; some applications may be clever 865 enough to organize the data structures and functions in such a manner 866 that look-ups get refreshed now and then. 868 While the issue appears to have a clear solution, "fix the 869 applications", practically this is not reasonable immediate advice; 870 the TTL information is not typically available in the APIs and 871 libraries (so, the advice becomes "fix the applications, APIs and 872 libraries"), and a lot more analysis is needed on how to practically 873 go about to achieve the ultimate goal of avoiding using the names 874 longer than expected. 876 9. Acknowledgements 878 Some recommendations (Section 4.3, Section 5.1) about IPv6 service 879 provisioning were moved here from [RFC4213] by Erik Nordmark and Bob 880 Gilligan. Havard Eidnes and Michael Patton provided useful feedback 881 and improvements. Scott Rose, Rob Austein, Masataka Ohta, and Mark 882 Andrews helped in clarifying the issues regarding additional data and 883 the use of TTL. Jefsey Morfin, Ralph Droms, Peter Koch, Jinmei 884 Tatuya, Iljitsch van Beijnum, Edward Lewis, and Rob Austein provided 885 useful feedback during the WG last call. Thomas Narten provided 886 extensive feedback during the IESG evaluation. 888 10. IANA Considerations 890 This memo includes no request to IANA. 892 11. Security Considerations 894 This document reviews the operational procedures for IPv6 DNS 895 operations and does not have security considerations in itself. 897 However, it is worth noting that in particular with Dynamic DNS 898 Updates, security models based on the source address validation are 899 very weak and cannot be recommended -- they could only be considered 900 in the environments where ingress filtering [RFC3704] has been 901 deployed. On the other hand, it should be noted that setting up an 902 authorization mechanism (e.g., a shared secret, or public-private 903 keys) between a node and the DNS server has to be done manually, and 904 may require quite a bit of time and expertise. 906 To re-emphasize what was already stated, the reverse+forward DNS 907 check provides very weak security at best, and the only 908 (questionable) security-related use for them may be in conjunction 909 with other mechanisms when authenticating a user. 911 12. References 913 12.1. Normative References 915 [I-D.ietf-dnsop-ipv6-dns-configuration] 916 Jeong, J., "IPv6 Host Configuration of DNS Server 917 Information Approaches", 918 draft-ietf-dnsop-ipv6-dns-configuration-06 (work in 919 progress), May 2005. 921 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 922 STD 13, RFC 1034, November 1987. 924 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 925 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 926 RFC 2136, April 1997. 928 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 929 Specification", RFC 2181, July 1997. 931 [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection 932 and Operation of Secondary DNS Servers", BCP 16, RFC 2182, 933 July 1997. 935 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 936 Autoconfiguration", RFC 2462, December 1998. 938 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 939 RFC 2671, August 1999. 941 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 942 April 2001. 944 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 945 Update", RFC 3007, November 2000. 947 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 948 Stateless Address Autoconfiguration in IPv6", RFC 3041, 949 January 2001. 951 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 952 via IPv4 Clouds", RFC 3056, February 2001. 954 [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, 955 August 2001. 957 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 958 and M. Carney, "Dynamic Host Configuration Protocol for 959 IPv6 (DHCPv6)", RFC 3315, July 2003. 961 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. 962 Hain, "Representing Internet Protocol version 6 (IPv6) 963 Addresses in the Domain Name System (DNS)", RFC 3363, 964 August 2002. 966 [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) 967 Support for Internet Protocol version 6 (IPv6)", RFC 3364, 968 August 2002. 970 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 971 (IPv6) Addressing Architecture", RFC 3513, April 2003. 973 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 974 "DNS Extensions to Support IP Version 6", RFC 3596, 975 October 2003. 977 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 978 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 979 December 2003. 981 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 982 (DHCP) Service for IPv6", RFC 3736, April 2004. 984 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 985 Addresses", RFC 3879, September 2004. 987 [RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational 988 Guidelines", BCP 91, RFC 3901, September 2004. 990 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. 991 Castro, "Application Aspects of IPv6 Transition", 992 RFC 4038, March 2005. 994 [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against 995 DNS Queries for IPv6 Addresses", RFC 4074, May 2005. 997 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 998 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 999 September 2005. 1001 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1002 Addresses", RFC 4193, October 2005. 1004 12.2. Informative References 1006 [I-D.durand-dnsop-dont-publish] 1007 Durand, A. and T. Chown, "To publish, or not to publish, 1008 that is the question.", draft-durand-dnsop-dont-publish-00 1009 (work in progress), February 2005. 1011 [I-D.huitema-v6ops-teredo] 1012 Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1013 NATs", draft-huitema-v6ops-teredo-05 (work in progress), 1014 April 2005. 1016 [I-D.huston-6to4-reverse-dns] 1017 Huston, G., "6to4 Reverse DNS Delegation", 1018 draft-huston-6to4-reverse-dns-03 (work in progress), 1019 October 2004. 1021 [I-D.ietf-dhc-ddns-resolution] 1022 Stapp, M. and B. Volz, "Resolution of FQDN Conflicts among 1023 DHCP Clients", draft-ietf-dhc-ddns-resolution-10 (work in 1024 progress), September 2005. 1026 [I-D.ietf-dhc-fqdn-option] 1027 Stapp, M., "The DHCP Client FQDN Option", 1028 draft-ietf-dhc-fqdn-option-11 (work in progress), 1029 September 2005. 1031 [I-D.ietf-dnsext-dhcid-rr] 1032 Stapp, M., "A DNS RR for Encoding DHCP Information (DHCID 1033 RR)", draft-ietf-dnsext-dhcid-rr-10 (work in progress), 1034 September 2005. 1036 [I-D.ietf-dnsop-bad-dns-res] 1037 Larson, M. and P. Barber, "Observed DNS Resolution 1038 Misbehavior", draft-ietf-dnsop-bad-dns-res-04 (work in 1039 progress), July 2005. 1041 [I-D.ietf-dnsop-inaddr-required] 1042 Senie, D., "Encouraging the use of DNS IN-ADDR Mapping", 1043 draft-ietf-dnsop-inaddr-required-07 (work in progress), 1044 August 2005. 1046 [I-D.ietf-v6ops-natpt-to-exprmntl] 1047 Aoun, C. and E. Davies, "Reasons to Move NAT-PT to 1048 Experimental", draft-ietf-v6ops-natpt-to-exprmntl-02 (work 1049 in progress), October 2005. 1051 [I-D.ietf-v6ops-onlinkassumption] 1052 Roy, S., "IPv6 Neighbor Discovery On-Link Assumption 1053 Considered Harmful", draft-ietf-v6ops-onlinkassumption-03 1054 (work in progress), May 2005. 1056 [I-D.ietf-v6ops-v6onbydefault] 1057 Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack 1058 IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 1059 (work in progress), July 2004. 1061 [I-D.jeong-dnsop-ipv6-dns-discovery] 1062 Jeong, J., "IPv6 Router Advertisement Option for DNS 1063 Configuration", draft-jeong-dnsop-ipv6-dns-discovery-05 1064 (work in progress), July 2005. 1066 [I-D.ohta-preconfigured-dns] 1067 Ohta, M., "Preconfigured DNS Server Addresses", 1068 draft-ohta-preconfigured-dns-01 (work in progress), 1069 February 2004. 1071 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 1072 Translation - Protocol Translation (NAT-PT)", RFC 2766, 1073 February 2000. 1075 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1076 specifying the location of services (DNS SRV)", RFC 2782, 1077 February 2000. 1079 [RFC2826] Internet Architecture Board, "IAB Technical Comment on the 1080 Unique DNS Root", RFC 2826, May 2000. 1082 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1083 Networks", BCP 84, RFC 3704, March 2004. 1085 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1086 RFC 3972, March 2005. 1088 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 1089 Material in DNS", RFC 4025, March 2005. 1091 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1092 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1094 [RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third 1095 Generation Partnership Project (3GPP) Networks", RFC 4215, 1096 October 2005. 1098 [TC-TEST] Jinmei, T., "Thread "RFC2181 section 9.1: TC bit handling 1099 and additional data" on DNSEXT mailing list, Message-Id: 1101 y7vek9j9hyo.wl%jinmei@isl.rdc.toshiba.co.jp", August 1102 1st 2005, . 1105 Appendix A. Unique Local Addressing Considerations for DNS 1107 Unique local addresses [RFC4193] have replaced the now-deprecated 1108 site-local addresses [RFC3879]. From the perspective of the DNS, the 1109 locally generated unique local addresses (LUL) and site-local 1110 addresses have similar properties. 1112 The interactions with DNS come in two flavors: forward and reverse 1113 DNS. 1115 To actually use local addresses within a site, this implies the 1116 deployment of a "split-faced" or a fragmented DNS name space, for the 1117 zones internal to the site, and the outsiders' view to it. The 1118 procedures to achieve this are not elaborated here. The implication 1119 is that local addresses must not be published in the public DNS. 1121 To faciliate reverse DNS (if desired) with local addresses, the stub 1122 resolvers must look for DNS information from the local DNS servers, 1123 not e.g. starting from the root servers, so that the local 1124 information may be provided locally. Note that the experience of 1125 private addresses in IPv4 has shown that the root servers get loaded 1126 for requests for private address lookups in any case. This 1127 requirement is discussed in [RFC4193]. 1129 Appendix B. Behaviour of Additional Data in IPv4/IPv6 Environments 1131 DNS responses do not always fit in a single UDP packet. We'll 1132 examine the cases which happen when this is due to too much data in 1133 the Additional Section. 1135 B.1. Description of Additional Data Scenarios 1137 There are two kinds of additional data: 1139 1. "critical" additional data; this must be included in all 1140 scenarios, with all the RRsets, and 1142 2. "courtesy" additional data; this could be sent in full, with only 1143 a few RRsets, or with no RRsets, and can be fetched separately as 1144 well, but at the cost of additional queries. 1146 The responding server can algorithmically determine which type the 1147 additional data is by checking whether it's at or below a zone cut. 1149 Only those additional data records (even if sometimes carelessly 1150 termed "glue") are considered "critical" or real "glue" if and only 1151 if they meet the abovementioned condition, as specified in Section 1152 4.2.1 of [RFC1034]. 1154 Remember that resource record sets (RRsets) are never "broken up", so 1155 if a name has 4 A records and 5 AAAA records, you can either return 1156 all 9, all 4 A records, all 5 AAAA records or nothing. In 1157 particular, notice that for the "critical" additional data getting 1158 all the RRsets can be critical. 1160 In particular, [RFC2181] specifies (in Section 9) that: 1162 a. if all the "critical" RRsets do not fit, the sender should set 1163 the TC bit, and the recipient should discard the whole response 1164 and retry using mechanism allowing larger responses such as TCP. 1166 b. "courtesy" additional data should not cause the setting of TC 1167 bit, but instead all the non-fitting additional data RRsets 1168 should be removed. 1170 An example of the "courtesy" additional data is A/AAAA records in 1171 conjunction with MX records as shown in Section 4.4; an example of 1172 the "critical" additional data is shown below (where getting both the 1173 A and AAAA RRsets is critical w.r.t. to the NS RR): 1175 child.example.com. IN NS ns.child.example.com. 1176 ns.child.example.com. IN A 192.0.2.1 1177 ns.child.example.com. IN AAAA 2001:db8::1 1179 When there is too much "courtesy" additional data, at least the non- 1180 fitting RRsets should be removed [RFC2181]; however, as the 1181 additional data is not critical, even all of it could be safely 1182 removed. 1184 When there is too much "critical" additional data, TC bit will have 1185 to be set, and the recipient should ignore the response and retry 1186 using TCP; if some data were to be left in the UDP response, the 1187 issue is which data could be retained. 1189 However, the practise may differ from the specification. Testing and 1190 code analysis of 3 recent implementations [TC-TEST] confirm this. 1191 None of the tested implementations have a strict separation of 1192 critical and courtesy additional data, while some forms of additional 1193 data may be treated preferably. All the implementations remove some 1194 (critical or courtesy) additional data RRsets without setting TC bit 1195 if the response would not otherwise fit. 1197 Failing to discard the response with TC bit or omitting critical 1198 information but not setting TC bit lead to an unrecoverable problem. 1199 Omitting only some of the RRsets if all would not fit (but not 1200 setting TC bit) leads to a performance problem. These are discussed 1201 in the next two subsections. 1203 B.2. Which Additional Data to Keep, If Any? 1205 If the implementation decides to keep as much data (whether 1206 "critical" or "courtesy") as possible in the UDP responses, it might 1207 be tempting to use the transport of the DNS query as a hint in either 1208 of these cases: return the AAAA records if the query was done over 1209 IPv6, or return the A records if the query was done over IPv4. 1210 However, this breaks the model of independence of DNS transport and 1211 resource records, as noted in Section 1.2. 1213 With courtesy additional data, as long as enough RRsets will be 1214 removed so that TC will not be set, it is allowed to send as many 1215 complete RRsets as the implementations prefers. However, the 1216 implementations are also free to omit all such RRsets, even if 1217 complete. Omitting all the RRsets (when removing only some would 1218 suffice) may create a performance penalty, whereby the client may 1219 need to issue one or more additional queries to obtain necessary 1220 and/or consistent information. 1222 With critical additional data, the alternatives are either returning 1223 nothing (and absolutely requiring a retry with TCP) or returning 1224 something (working also in the case if the recipient does not discard 1225 the response and retry using TCP) in addition to setting the TC bit. 1226 If the process for selecting "something" from the critical data would 1227 otherwise be practically "flipping the coin" between A and AAAA 1228 records, it could be argued that if one looked at the transport of 1229 the query, it would have a larger possibility of being right than 1230 just 50/50. In other words, if the returned critical additional data 1231 would have to be selected somehow, using something more sophisticated 1232 than a random process would seem justifiable. 1234 That is, leaving in some intelligently selected critical additional 1235 data is a tradeoff between creating an optimization for those 1236 resolvers which ignore the "should discard" recommendation, and 1237 causing a protocol problem by propagating inconsistent information 1238 about "critical" records in the caches. 1240 Similarly, leaving in the complete courtesy additional data RRsets 1241 instead of removing all the RRsets is a performance tradeoff as 1242 described in the next section. 1244 B.3. Discussion of the Potential Problems 1246 As noted above, the temptation for omitting only some of the 1247 additional data could be problematic. This is discussed more below. 1249 For courtesy additional data, this causes a potential performance 1250 problem as this requires that the clients issue re-queries for the 1251 potentially omitted RRsets. For critical additional data, this 1252 causes a potential unrecoverable problem if the response is not 1253 discarded and the query not re-tried with TCP, as the nameservers 1254 might be reachable only through the omitted RRsets. 1256 If an implementation would look at the transport used for the query, 1257 it is worth remembering that often the host using the records is 1258 different from the node requesting them from the authoritative DNS 1259 server (or even a caching resolver). So, whichever version the 1260 requestor (e.g., a recursive server in the middle) uses makes no 1261 difference to the ultimate user of the records, whose transport 1262 capabilities might differ from those of the requestor. This might 1263 result in e.g., inappropriately returning A records to an IPv6-only 1264 node, going through a translation, or opening up another IP-level 1265 session (e.g., a PDP context [RFC4215]). Therefore, at least in many 1266 scenarios, it would be very useful if the information returned would 1267 be consistent and complete -- or if that is not feasible, return no 1268 misleading information but rather leave it to the client to query 1269 again. 1271 The problem of too much additional data seems to be an operational 1272 one: the zone administrator entering too many records which will be 1273 returned either truncated (or missing some RRsets, depending on 1274 implementations) to the users. A protocol fix for this is using 1275 EDNS0 [RFC2671] to signal the capacity for larger UDP packet sizes, 1276 pushing up the relevant threshold. Further, DNS server 1277 implementations should rather omit courtesy additional data 1278 completely rather than including only some RRsets [RFC2181]. An 1279 operational fix for this is having the DNS server implementations 1280 return a warning when the administrators create zones which would 1281 result in too much additional data being returned. Further, DNS 1282 server implementations should warn of or disallow such zone 1283 configurations which are recursive or otherwise difficult to manage 1284 by the protocol. 1286 Additionally, to avoid the case where an application would not get an 1287 address at all due to some of courtesy additional data being omitted, 1288 the resolvers should be able to query the specific records of the 1289 desired protocol, not just rely on getting all the required RRsets in 1290 the additional section. 1292 Authors' Addresses 1294 Alain Durand 1295 Comcast 1296 150 Market st 1297 Philadelphia, PA 19102 1298 USA 1300 Email: Alain_Durand@cable.comcast.com 1302 Johan Ihren 1303 Autonomica 1304 Bellmansgatan 30 1305 SE-118 47 Stockholm 1306 Sweden 1308 Email: johani@autonomica.se 1310 Pekka Savola 1311 CSC/FUNET 1312 Espoo 1313 Finland 1315 Email: psavola@funet.fi 1317 Full Copyright Statement 1319 Copyright (C) The Internet Society (2005). 1321 This document is subject to the rights, licenses and restrictions 1322 contained in BCP 78, and except as set forth therein, the authors 1323 retain all their rights. 1325 This document and the information contained herein are provided on an 1326 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1327 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1328 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1329 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1330 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1331 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1333 Intellectual Property 1335 The IETF takes no position regarding the validity or scope of any 1336 Intellectual Property Rights or other rights that might be claimed to 1337 pertain to the implementation or use of the technology described in 1338 this document or the extent to which any license under such rights 1339 might or might not be available; nor does it represent that it has 1340 made any independent effort to identify any such rights. Information 1341 on the procedures with respect to rights in RFC documents can be 1342 found in BCP 78 and BCP 79. 1344 Copies of IPR disclosures made to the IETF Secretariat and any 1345 assurances of licenses to be made available, or the result of an 1346 attempt made to obtain a general license or permission for the use of 1347 such proprietary rights by implementers or users of this 1348 specification can be obtained from the IETF on-line IPR repository at 1349 http://www.ietf.org/ipr. 1351 The IETF invites any interested party to bring to its attention any 1352 copyrights, patents or patent applications, or other proprietary 1353 rights that may cover technology that may be required to implement 1354 this standard. Please address the information to the IETF at 1355 ietf-ipr@ietf.org. 1357 Acknowledgment 1359 Funding for the RFC Editor function is currently provided by the 1360 Internet Society.