idnits 2.17.1 draft-ietf-dnsop-ipv6-dns-issues-08.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.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1372. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1349. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1356. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1362. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1378), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 29 longer pages, the longest (page 24) being 69 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 30 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 977 has weird spacing: '...records to lo...' -- 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 (July 18, 2004) is 7222 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: 'RFC2766' is defined on line 1229, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-dnsop-ipv6-dns-configuration-01 ** Downref: Normative reference to an Informational draft: draft-ietf-dnsop-ipv6-dns-configuration (ref. 'I-D.ietf-dnsop-ipv6-dns-configuration') == Outdated reference: A later version (-02) exists of draft-ietf-dnsop-misbehavior-against-aaaa-01 ** Downref: Normative reference to an Informational draft: draft-ietf-dnsop-misbehavior-against-aaaa (ref. 'I-D.ietf-dnsop-misbehavior-against-aaaa') ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-application-transition (ref. 'I-D.ietf-v6ops-application-transition') == Outdated reference: A later version (-05) exists of draft-ietf-v6ops-renumbering-procedure-01 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-renumbering-procedure (ref. 'I-D.ietf-v6ops-renumbering-procedure') ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** 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) == Outdated reference: A later version (-05) exists of draft-huitema-v6ops-teredo-02 == Outdated reference: A later version (-07) exists of draft-huston-6to4-reverse-dns-02 == Outdated reference: A later version (-12) exists of draft-ietf-dhc-ddns-resolution-06 == Outdated reference: A later version (-13) exists of draft-ietf-dhc-fqdn-option-06 == Outdated reference: A later version (-13) exists of draft-ietf-dnsext-dhcid-rr-07 == Outdated reference: A later version (-06) exists of draft-ietf-dnsop-bad-dns-res-01 == Outdated reference: A later version (-07) exists of draft-ietf-dnsop-inaddr-required-05 == Outdated reference: A later version (-12) exists of draft-ietf-ipseckey-rr-10 == Outdated reference: A later version (-09) exists of draft-ietf-ipv6-unique-local-addr-05 == Outdated reference: A later version (-11) exists of draft-ietf-v6ops-3gpp-analysis-10 == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-mech-v2-03 == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-onlinkassumption-02 == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-v6onbydefault-02 == Outdated reference: A later version (-12) exists of draft-jeong-dnsop-ipv6-dns-discovery-01 -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) Summary: 20 errors (**), 0 flaws (~~), 23 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNS Operations WG A. Durand 2 Internet-Draft SUN Microsystems, Inc. 3 Expires: January 16, 2005 J. Ihren 4 Autonomica 5 P. Savola 6 CSC/FUNET 7 July 18, 2004 9 Operational Considerations and Issues with IPv6 DNS 10 draft-ietf-dnsop-ipv6-dns-issues-08.txt 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at http:// 32 www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on January 16, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). All Rights Reserved. 43 Abstract 45 This memo presents operational considerations and issues with IPv6 46 Domain Name System (DNS), including a summary of special IPv6 47 addresses, documentation of known DNS implementation misbehaviour, 48 recommendations and considerations on how to perform DNS naming for 49 service provisioning and for DNS resolver IPv6 support, 50 considerations for DNS updates for both the forward and reverse 51 trees, and miscellaneous issues. This memo is aimed to include a 52 summary of information about IPv6 DNS considerations for those who 53 have experience with IPv4 DNS. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . 4 59 1.2 Independence of DNS Transport and DNS Records . . . . . . 4 60 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . 5 61 1.4 Query Type '*' and A/AAAA Records . . . . . . . . . . . . 5 62 2. DNS Considerations about Special IPv6 Addresses . . . . . . . 5 63 2.1 Limited-scope Addresses . . . . . . . . . . . . . . . . . 6 64 2.2 Temporary Addresses . . . . . . . . . . . . . . . . . . . 6 65 2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 6 66 2.4 Other Transition Mechanisms . . . . . . . . . . . . . . . 6 67 3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 7 68 3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . 7 69 3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 7 70 4. Recommendations for Service Provisioning using DNS . . . . . . 8 71 4.1 Use of Service Names instead of Node Names . . . . . . . . 8 72 4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . 8 73 4.3 Adding the Records Only when Fully IPv6-enabled . . . . . 9 74 4.4 Behaviour of Additional Data in IPv4/IPv6 Environments . . 10 75 4.4.1 Description of Additional Data Scenarios . . . . . . . 10 76 4.4.2 Discussion of the Problems . . . . . . . . . . . . . . 11 77 4.5 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 12 78 4.6 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 13 79 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 14 80 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 14 81 5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 15 82 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 16 83 6. Considerations about Forward DNS Updating . . . . . . . . . . 16 84 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 17 85 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 17 86 7. Considerations about Reverse DNS Updating . . . . . . . . . . 18 87 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 18 88 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 19 89 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 19 90 7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 20 91 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 21 92 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 22 93 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 22 94 8.2 Renumbering Procedures and Applications' Use of DNS . . . 22 95 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 96 10. Security Considerations . . . . . . . . . . . . . . . . . . 22 97 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 98 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 99 11.2 Informative References . . . . . . . . . . . . . . . . . . . 25 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 101 A. Site-local Addressing Considerations for DNS . . . . . . . . . 28 102 B. Issues about Additional Data or TTL . . . . . . . . . . . . . 28 103 Intellectual Property and Copyright Statements . . . . . . . . 30 105 1. Introduction 107 This memo presents operational considerations and issues with IPv6 108 DNS; it is meant to be an extensive summary and a list of pointers 109 for more information about IPv6 DNS considerations for those with 110 experience with IPv4 DNS. 112 The purpose of this document is to give information about various 113 issues and considerations related to DNS operations with IPv6; it is 114 not meant to be a normative specification or standard for IPv6 DNS. 116 The first section gives a brief overview of how IPv6 addresses and 117 names are represented in the DNS, how transport protocols and 118 resource records (don't) relate, and what IPv4/IPv6 name space 119 fragmentation means and how to avoid it; all of these are described 120 at more length in other documents. 122 The second section summarizes the special IPv6 address types and how 123 they relate to DNS. The third section describes observed DNS 124 implementation misbehaviours which have a varying effect on the use 125 of IPv6 records with DNS. The fourth section lists recommendations 126 and considerations for provisioning services with DNS. The fifth 127 section in turn looks at recommendations and considerations about 128 providing IPv6 support in the resolvers. The sixth and seventh 129 sections describe considerations with forward and reverse DNS 130 updates, respectively. The eighth section introduces several 131 miscellaneous IPv6 issues relating to DNS for which no better place 132 has been found in this memo. Appendix A looks briefly at the 133 requirements for site-local addressing. 135 1.1 Representing IPv6 Addresses in DNS Records 137 In the forward zones, IPv6 addresses are represented using AAAA 138 records. In the reverse zones, IPv6 address are represented using 139 PTR records in the nibble format under the ip6.arpa. tree. See 140 [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152] 141 for background information. 143 In particular one should note that the use of A6 records in the 144 forward tree or Bitlabels in the reverse tree is not recommended 145 [RFC3363]. Using DNAME records is not recommended in the reverse 146 tree in conjunction with A6 records; the document did not mean to 147 take a stance on any other use of DNAME records [RFC3364]. 149 1.2 Independence of DNS Transport and DNS Records 151 DNS has been designed to present a single, globally unique name space 152 [RFC2826]. This property should be maintained, as described here and 153 in Section 1.3. 155 In DNS, the IP version used to transport the queries and responses is 156 independent of the records being queried: AAAA records can be queried 157 over IPv4, and A records over IPv6. The DNS servers must not make 158 any assumptions about what data to return for Answer and Authority 159 sections based on the underlying transport used in a query. 161 However, there is some debate whether the addresses in Additional 162 section could be selected or filtered using hints obtained from which 163 transport was being used; this has some obvious problems because in 164 many cases the transport protocol does not correlate with the 165 requests, and because a "bad" answer is in a way worse than no answer 166 at all (consider the case where the client is led to believe that a 167 name received in the additional record does not have any AAAA records 168 to begin with). 170 As stated in [RFC3596]: 172 The IP protocol version used for querying resource records is 173 independent of the protocol version of the resource records; e.g., 174 IPv4 transport can be used to query IPv6 records and vice versa. 176 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation 178 To avoid the DNS name space from fragmenting into parts where some 179 parts of DNS are only visible using IPv4 (or IPv6) transport, the 180 recommendation is to always keep at least one authoritative server 181 IPv4-enabled, and to ensure that recursive DNS servers support IPv4. 182 See DNS IPv6 transport guidelines 183 [I-D.ietf-dnsop-ipv6-transport-guidelines] for more information. 185 1.4 Query Type '*' and A/AAAA Records 187 QTYPE=* is typically only used for debugging or management purposes; 188 it is worth keeping in mind that QTYPE=* ("ANY" queries) only return 189 any available RRsets, not *all* the RRsets, because the caches do not 190 necessarily have all the RRsets and have no way of guaranteeing that 191 they have all the RRsets. Therefore, to get both A and AAAA records 192 reliably, two separate queries must be made. 194 2. DNS Considerations about Special IPv6 Addresses 196 There are a couple of IPv6 address types which are somewhat special; 197 these are considered here. 199 2.1 Limited-scope Addresses 201 The IPv6 addressing architecture [RFC3513] includes two kinds of 202 local-use addresses: link-local (fe80::/10) and site-local (fec0::/ 203 10). The site-local addresses are being deprecated 204 [I-D.ietf-ipv6-deprecate-site-local], and are only discussed in 205 Appendix A. 207 Link-local addresses should never be published in DNS (whether in 208 forward or reverse tree), because they have only local (to the 209 connected link) significance 210 [I-D.ietf-dnsop-dontpublish-unreachable]. 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 Publishing (useful) DNS records relating to such addresses would 217 defeat the purpose of the mechanism and is not recommended. However, 218 it would still be possible to return a non-identifiable name (e.g., 219 the IPv6 address in hexadecimal format), as described in [RFC3041]. 221 2.3 6to4 Addresses 223 6to4 [RFC3056] specifies an automatic tunneling mechanism which maps 224 a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. 225 Providing reverse DNS delegation path for such addresses is not 226 straightforward and practically impossible. 228 If the reverse DNS population would be desirable (see Section 7.1 for 229 applicability), there are a number of ways to tackle the delegation 230 path problem [I-D.moore-6to4-dns], some more applicable than the 231 others. 233 The main proposal [I-D.huston-6to4-reverse-dns] aims to design an 234 autonomous reverse-delegation system that anyone being capable of 235 communicating using a specific 6to4 address would be able to set up a 236 reverse delegation to the corresponding 6to4 prefix. This could be 237 deployed by e.g., RIRs. This is a more practical solution, but may 238 have some scalability concerns. 240 2.4 Other Transition Mechanisms 242 6to4, above, is mentioned as a case of an IPv6 transition mechanism 243 requiring special considerations. In general, mechanisms which 244 include a special prefix may need a custom solution; otherwise, for 245 example when IPv4 address is embedded as the suffix or not embedded 246 at all, special solutions are likely not needed. This is why only 247 6to4 and Teredo [I-D.huitema-v6ops-teredo] are described. 249 Note that it does not seem feasible to provide reverse DNS with 250 another automatic tunneling mechanism, Teredo; this is because the 251 IPv6 address is based on the IPv4 address and UDP port of the current 252 NAT mapping which is likely to be relatively short-lived. 254 3. Observed DNS Implementation Misbehaviour 256 Several classes of misbehaviour in DNS servers, load-balancers and 257 resolvers have been observed. Most of these are rather generic, not 258 only applicable to IPv6 -- but in some cases, the consequences of 259 this misbehaviour are extremely severe in IPv6 environments and 260 deserve to be mentioned. 262 3.1 Misbehaviour of DNS Servers and Load-balancers 264 There are several classes of misbehaviour in certain DNS servers and 265 load-balancers which have been noticed and documented 266 [I-D.ietf-dnsop-misbehavior-against-aaaa]: some implementations 267 silently drop queries for unimplemented DNS records types, or provide 268 wrong answers to such queries (instead of a proper negative reply). 269 While typically these issues are not limited to AAAA records, the 270 problems are aggravated by the fact that AAAA records are being 271 queried instead of (mainly) A records. 273 The problems are serious because when looking up a DNS name, typical 274 getaddrinfo() implementations, with AF_UNSPEC hint given, first try 275 to query the AAAA records of the name, and after receiving a 276 response, query the A records. This is done in a serial fashion -- 277 if the first query is never responded to (instead of properly 278 returning a negative answer), significant timeouts will occur. 280 In consequence, this is an enormous problem for IPv6 deployments, and 281 in some cases, IPv6 support in the software has even been disabled 282 due to these problems. 284 The solution is to fix or retire those misbehaving implementations, 285 but that is likely not going to be effective. There are some 286 possible ways to mitigate the problem, e.g. by performing the 287 lookups somewhat in parallel and reducing the timeout as long as at 288 least one answer has been received; but such methods remain to be 289 investigated; slightly more on this is included in Section 5. 291 3.2 Misbehaviour of DNS Resolvers 293 Several classes of misbehaviour have also been noticed in DNS 294 resolvers [I-D.ietf-dnsop-bad-dns-res]. However, these do not seem 295 to directly impair IPv6 use, and are only referred to for 296 completeness. 298 4. Recommendations for Service Provisioning using DNS 300 When names are added in the DNS to facilitate a service, there are 301 several general guidelines to consider to be able to do it as 302 smoothly as possible. 304 4.1 Use of Service Names instead of Node Names 306 When a node includes multiple services which should not be 307 fate-sharing, or might support different IP versions, one should keep 308 them logically separate in the DNS. Using SRV records would avoid 309 these problems. Unfortunately, they are not sufficiently widely used 310 to be applicable in most cases. Hence an operation technique is to 311 use service names instead of node names (or, "hostnames"). This 312 operational technique is not specific to IPv6, but required to 313 understand the considerations described in Section 4.2 and Section 314 4.3. 316 For example, assume a node named "pobox.example.com" provides both 317 SMTP and IMAP service. Instead of configuring the MX records to 318 point at "pobox.example.com", and configuring the mail clients to 319 look up the mail via IMAP from "pobox.example.com", one should use 320 e.g. "smtp.example.com" for SMTP (for both message submission and 321 mail relaying between SMTP servers) and "imap.example.com" for IMAP. 322 Note that in the specific case of SMTP relaying, the server itself 323 must typically also be configured to know all its names to ensure 324 loops do not occur. DNS can provide a layer of indirection between 325 service names and where the service actually is, and using which 326 addresses. (Obviously, when wanting to reach a specific node, one 327 should use the hostname rather than a service name.) 329 This is a good practice with IPv4 as well, because it provides more 330 flexibility and enables easier migration of services from one host to 331 another. A specific reason why this is relevant for IPv6 is that the 332 different services may have a different level of IPv6 support -- that 333 is, one node providing multiple services might want to enable just 334 one service to be IPv6-visible while keeping some others as 335 IPv4-only. Using service names enables more flexibility with 336 different IP versions as well. 338 4.2 Separate vs the Same Service Names for IPv4 and IPv6 340 The service naming can be achieved in basically two ways: when a 341 service is named "service.example.com" for IPv4, the IPv6-enabled 342 service could be either added to "service.example.com", or added 343 separately under a different name, e.g., in a sub-domain, like, 344 "service.ipv6.example.com". 346 These two methods have different characteristics. Using a different 347 name allows for easier service piloting, minimizing the disturbance 348 to the "regular" users of IPv4 service; however, the service would 349 not be used transparently, without the user/application explicitly 350 finding it and asking for it -- which would be a disadvantage in most 351 cases. If the different name is under a sub-domain, if the services 352 are deployed within a restricted network (e.g., inside an 353 enterprise), it's possible to prefer them transparently, at least to 354 a degree, by modifying the DNS search path; however, this is a 355 suboptimal solution. Using the same service name is the "long-term" 356 solution, but may degrade performance for those clients whose IPv6 357 performance is lower than IPv4, or does not work as well (see the 358 next subsection for more). 360 In most cases, it makes sense to pilot or test a service using 361 separate service names, and move to the use of the same name when 362 confident enough that the service level will not degrade for the 363 users unaware of IPv6. 365 4.3 Adding the Records Only when Fully IPv6-enabled 367 The recommendation is that AAAA records for a service should not be 368 added to the DNS until all of following are true: 370 1. The address is assigned to the interface on the node. 372 2. The address is configured on the interface. 374 3. The interface is on a link which is connected to the IPv6 375 infrastructure. 377 In addition, if the AAAA record is added for the node, instead of 378 service as recommended, all the services of the node should be 379 IPv6-enabled prior to adding the resource record. 381 For example, if an IPv6 node is isolated from an IPv6 perspective 382 (e.g., it is not connected to IPv6 Internet) constraint #3 would mean 383 that it should not have an address in the DNS. 385 Consider the case of two dual-stack nodes, which both have IPv6 386 enabled, but the server does not have (global) IPv6 connectivity. As 387 the client looks up the server's name, only A records are returned 388 (if the recommendations above are followed), and no IPv6 389 communication, which would have been unsuccessful, is even attempted. 391 The issues are not always so black-and-white. Usually it's important 392 if the service offered using both protocols is of roughly equal 393 quality, using the appropriate metrics for the service (e.g., 394 latency, throughput, low packet loss, general reliability, etc.) -- 395 this is typically very important especially for interactive or 396 real-time services. In many cases, the quality of IPv6 connectivity 397 is not yet equal to that of IPv4, at least globally -- this has to be 398 taken into consideration when enabling services 399 [I-D.savola-v6ops-6bone-mess]. 401 4.4 Behaviour of Additional Data in IPv4/IPv6 Environments 403 4.4.1 Description of Additional Data Scenarios 405 Consider the case where the query name is so long, the number of the 406 additional records is so high, or for other reasons that the entire 407 response would not fit in a single UDP packet. In some cases, the 408 responder truncates the response with the TC bit being set (leading 409 to a retry with TCP), in order for the querier to get the entire 410 response later. 412 However, note that if too much additional information that is not 413 strictly necessary would be added, one should remove unnecessary 414 information instead of setting TC bit for this "courtesy" information 415 [RFC2181]. 417 Also notice that there are two kinds of additional data: 419 1. glue, i.e., "critical" additional data; this must be included in 420 all scenarios, with all the RRsets as possible, and 422 2. "courtesy" additional data; this could be sent in full, with only 423 a few RRsets, or with no RRsets, and can be fetched separately as 424 well, but at the cost of additional queries. This data should 425 never cause setting of the TC bit. 427 3. The responding server can algorithmically determine which type 428 the additional data is by checking whether it's at or below a 429 zone cut. 431 Meanwhile, resource record sets (RRsets) are never "broken up", so if 432 a name has 4 A records and 5 AAAA records, you can either return all 433 9, all 4 A records, all 5 AAAA records or nothing. Notice that for 434 the "critical" additional data getting all the RRsets can be 435 critical. 437 An example of the "courtesy" additional data is A/AAAA records in 438 conjunction of MX records as shown in Section 4.5; an example of the 439 "critical" additional data is shown below (where getting both the A 440 and AAAA RRsets is critical): 442 child.example.com. IN NS ns.child.example.com. 443 ns.child.example.com. IN A 192.0.2.1 444 ns.child.example.com. IN AAAA 2001:db8::1 446 When there is too much courtesy additional data, some or all of it 447 need to be removed; if some is left in the response, the issue is 448 which data should be retained. When there is too much critical 449 additional data, TC bit will have to be set, and some or all of it 450 need to be removed; if some is left in the response, the issue is 451 which data should be retained. 453 If the implementation decides to keep as much data as possible, it 454 might be tempting to use the transport of the DNS query as a hint in 455 either of these cases: return the AAAA records if the query was done 456 over IPv6, or return the A records, if the query was done over IPv4. 457 However, this breaks the model of independence of DNS transport and 458 resource records, as noted in Section 1.2. 460 It is worth remembering that often an end host which will be using 461 the records is not the same one as the node requesting them from the 462 authoritative DNS server (or even a caching resolver). So, whichever 463 version the requestor (e.g., a recursive server in the middle) uses 464 makes no difference to the ultimate user of the records, whose 465 transport capabilities might differ from those of the DNS server. 466 This might result in e.g., inappropriately returning A records to an 467 IPv6-only node, going through a translation, or opening up another 468 IP-level session (e.g., a PDP context 469 [I-D.ietf-v6ops-3gpp-analysis]). Therefore, at least in many 470 scenarios, it would be very useful if the information returned would 471 be consistent and complete -- or if that is not feasible, return no 472 misleading information but rather leave it to the client to query 473 again. 475 4.4.2 Discussion of the Problems 477 As noted above, the temptation for omitting additional data based on 478 the transport of the query would be problematic. In particular, 479 there appears to be little justification for that in the case of 480 "courtesy" data. However, with critical additional data, the 481 alternatives are either returning nothing (and requiring a retry with 482 TCP) or returning something (possibly obviating the need for a retry 483 with TCP). If the process for selecting "something" from the 484 critical data would otherwise be practically "flipping the coin" 485 between A and AAAA records, it could be argued that if one looked at 486 the transport of the query, it would have a larger possibility of 487 being right than just 50/50. In other words, if the returned 488 critical additional data would have to be selected somehow, using 489 something more sophisticated than a random process would seem 490 justifiable. 492 The problem of too much additional data seems to be an operational 493 one: the zone administrator entering too many records which will be 494 returned either truncated or missing some RRsets to the users. A 495 protocol fix for this is using EDNS0 [RFC2671] to signal the capacity 496 for larger UDP packet sizes, pushing up the relevant threshold. 497 Further, DNS server implementations should rather omit courtesy 498 additional data completely rather than including only some RRsets 499 [RFC2181]. An operational fix for this is having the DNS server 500 implementations return a warning when the administrators create the 501 zones which would result in too much additional data being returned. 502 Further, DNS server implementations should warn of or disallow such 503 zone configurations which are recursive or otherwise difficult to 504 manage by the protocol. 506 Additionally, to avoid the case where an application would not get an 507 address at all due to "courtesy" additional data being omitted, the 508 applications should be able to query the specific records of the 509 desired protocol, not just rely on getting all the required RRsets in 510 the additional section. 512 4.5 The Use of TTL for IPv4 and IPv6 RRs 514 In the previous section, we discussed a danger with queries, 515 potentially leading to omitting RRsets from the additional section; 516 this could happen to both critical and "courtesy" additional data. 517 This section discusses another problem with the latter, leading to 518 omitting RRsets in cached data, highlighted in the IPv4/IPv6 519 environment. 521 The behaviour of DNS caching when different TTL values are used for 522 different RRsets of the same name requires explicit discussion. For 523 example, let's consider a part of a zone: 525 example.com. 300 IN MX foo.example.com. 526 foo.example.com. 300 IN A 192.0.2.1 527 foo.example.com. 100 IN AAAA 2001:db8::1 529 When a caching resolver asks for the MX record of example.com, it 530 gets back "foo.example.com". It may also get back either one or both 531 of the A and AAAA records in the additional section. So, there are 532 three cases about returning records for the MX in the additional 533 section: 535 1. We get back no A or AAAA RRsets: this is the simplest case, 536 because then we have to query which information is required 537 explicitly, guaranteeing that we get all the information we're 538 interested in. 540 2. We get back all the RRsets: this is an optimization as there is 541 no need to perform more queries, causing lower latency. However, 542 it is impossible to guarantee that in fact we would always get 543 back all the records (the only way to ensure that is to send a 544 AAAA query for the name after getting the cached reply with A 545 records or vice versa); however, one could try to work in the 546 direction to try to ensure it as far as possible. 548 3. We only get back A or AAAA RRsets even if both existed: this is 549 indistinguishable from the previous case, and problematic as 550 described in the previous section. 552 As the third case was considered in the previous section, we assume 553 we get back both A and AAAA records of foo.example.com, or the stub 554 resolver explicitly asks, in two separate queries, both A and AAAA 555 records. 557 After 100 seconds, the AAAA record is removed from the cache(s) 558 because its TTL expired. It would be useful for the caching 559 resolvers to discard the A record when the shorter TTL (in this case, 560 for the AAAA record) expires; this would avoid the situation where 561 there would be a window of 200 seconds when incomplete information is 562 returned from the cache. However, this is not mandated or mentioned 563 by the specification(s). 565 To simplify the situation, it might help to use the same TTL for all 566 the resource record sets referring to the same name, unless there is 567 a particular reason for not doing so. However, there are some 568 scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where 569 a different strategy is preferable. 571 Thus, applications that use the response should not rely on a 572 particular TTL configuration. For example, even if an application 573 gets a response that only has the A record in the example described 574 above, it should be still aware that there could be a AAAA record for 575 "foo.example.com". That is, the application should try to fetch the 576 missing records itself if it needs the record. 578 4.6 IPv6 Transport Guidelines for DNS Servers 580 As described in Section 1.3 and 581 [I-D.ietf-dnsop-ipv6-transport-guidelines], there should continue to 582 be at least one authoritative IPv4 DNS server for every zone, even if 583 the zone has only IPv6 records. (Note that obviously, having more 584 servers with robust connectivity would be preferable, but this is the 585 minimum recommendation; also see [RFC2182].) 587 5. Recommendations for DNS Resolver IPv6 Support 589 When IPv6 is enabled on a node, there are several things to consider 590 to ensure that the process is as smooth as possible. 592 5.1 DNS Lookups May Query IPv6 Records Prematurely 594 The system library that implements the getaddrinfo() function for 595 looking up names is a critical piece when considering the robustness 596 of enabling IPv6; it may come in basically three flavours: 598 1. The system library does not know whether IPv6 has been enabled in 599 the kernel of the operating system: it may start looking up AAAA 600 records with getaddrinfo() and AF_UNSPEC hint when the system is 601 upgraded to a system library version which supports IPv6. 603 2. The system library might start to perform IPv6 queries with 604 getaddrinfo() only when IPv6 has been enabled in the kernel. 605 However, this does not guarantee that there exists any useful 606 IPv6 connectivity (e.g., the node could be isolated from the 607 other IPv6 networks, only having link-local addresses). 609 3. The system library might implement a toggle which would apply 610 some heuristics to the "IPv6-readiness" of the node before 611 starting to perform queries; for example, it could check whether 612 only link-local IPv6 address(es) exists, or if at least one 613 global IPv6 address exists. 615 First, let us consider generic implications of unnecessary queries 616 for AAAA records: when looking up all the records in the DNS, AAAA 617 records are typically tried first, and then A records. These are 618 done in serial, and the A query is not performed until a response is 619 received to the AAAA query. Considering the misbehaviour of DNS 620 servers and load-balancers, as described in Section 3.1, the look-up 621 delay for AAAA may incur additional unnecessary latency, and 622 introduce a component of unreliability. 624 One option here could be to do the queries partially in parallel; for 625 example, if the final response to the AAAA query is not received in 626 0.5 seconds, start performing the A query while waiting for the 627 result (immediate parallelism might be unoptimal without information 628 sharing between the look-up threads, as that would probably lead to 629 duplicate non-cached delegation chain lookups). 631 An additional concern is the address selection, which may, in some 632 circumstances, prefer AAAA records over A records, even when the node 633 does not have any IPv6 connectivity [I-D.ietf-v6ops-v6onbydefault]. 634 In some cases, the implementation may attempt to connect or send a 635 datagram on a physical link [I-D.ietf-v6ops-onlinkassumption], 636 incurring very long protocol timeouts, instead of quickly failing 637 back to IPv4. 639 Now, we can consider the issues specific to each of the three 640 possibilities: 642 In the first case, the node performs a number of completely useless 643 DNS lookups as it will not be able to use the returned AAAA records 644 anyway. (The only exception is where the application desires to know 645 what's in the DNS, but not use the result for communication.) One 646 should be able to disable these unnecessary queries, for both latency 647 and reliability reasons. However, as IPv6 has not been enabled, the 648 connections to IPv6 addresses fail immediately, and if the 649 application is programmed properly, the application can fall 650 gracefully back to IPv4 [I-D.ietf-v6ops-application-transition]. 652 The second case is similar to the first, except it happens to a 653 smaller set of nodes when IPv6 has been enabled but connectivity has 654 not been provided yet; similar considerations apply, with the 655 exception that IPv6 records, when returned, will be actually tried 656 first which may typically lead to long timeouts. 658 The third case is a bit more complex: optimizing away the DNS lookups 659 with only link-locals is probably safe (but may be desirable with 660 different lookup services which getaddrinfo() may support), as the 661 link-locals are typically automatically generated when IPv6 is 662 enabled, and do not indicate any form of IPv6 connectivity. That is, 663 performing DNS lookups only when a non-link-local address has been 664 configured on any interface could be beneficial -- this would be an 665 indication that either the address has been configured either from a 666 router advertisement, DHCPv6 [RFC3315], or manually. Each would 667 indicate at least some form of IPv6 connectivity, even though there 668 would not be guarantees of it. 670 These issues should be analyzed at more depth, and the fixes found 671 consensus on, perhaps in a separate document. 673 5.2 Obtaining a List of DNS Recursive Resolvers 675 In scenarios where DHCPv6 is available, a host can discover a list of 676 DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server" 677 option [RFC3646]. This option can be passed to a host through a 678 subset of DHCPv6 [RFC3736]. 680 The IETF is considering the development of alternative mechanisms for 681 obtaining the list of DNS recursive name servers when DHCPv6 is 682 unavailable or inappropriate. No decision about taking on this 683 development work has been reached as of this writing (Jul 2004) 684 [I-D.ietf-dnsop-ipv6-dns-configuration] 686 In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms 687 under consideration for development of dnsop WG include the use of 688 well-known addresses [I-D.ohta-preconfigured-dns], the use of Router 689 Advertisements to convey the information 690 [I-D.jeong-dnsop-ipv6-dns-discovery]. 692 Note that even though IPv6 DNS resolver discovery is a recommended 693 procedure, it is not required for dual-stack nodes in dual-stack 694 networks as IPv6 DNS records can be queried over IPv4 as well as 695 IPv6. Obviously, nodes which are meant to function without manual 696 configuration in IPv6-only networks must implement DNS resolver 697 discovery function. 699 5.3 IPv6 Transport Guidelines for Resolvers 701 As described in Section 1.3 and 702 [I-D.ietf-dnsop-ipv6-transport-guidelines], the recursive resolvers 703 should be IPv4-only or dual-stack to be able to reach any IPv4-only 704 DNS server. Note that this requirement is also fulfilled by an 705 IPv6-only stub resolver pointing to a dual-stack recursive DNS 706 resolver. 708 6. Considerations about Forward DNS Updating 710 While the topic how to enable updating the forward DNS, i.e., the 711 mapping from names to the correct new addresses, is not specific to 712 IPv6, it bears thinking about especially due to adding Stateless 713 Address Autoconfiguration [RFC2462] to the mix. 715 Typically forward DNS updates are more manageable than doing them in 716 the reverse DNS, because the updater can, typically, be assumed to 717 "own" a certain DNS name -- and we can create a form of security 718 relationship with the DNS name and the node allowed to update it to 719 point to a new address. 721 A more complex form of DNS updates -- adding a whole new name into a 722 DNS zone, instead of updating an existing name -- is considered out 723 of scope for this memo. Adding a new name in the forward zone is a 724 problem which is still being explored with IPv4, and IPv6 does not 725 seem to add much new in that area. 727 6.1 Manual or Custom DNS Updates 729 The DNS mappings can be maintained by hand, in a semi-automatic 730 fashion or by running non-standardized protocols. These are not 731 considered at more length in this memo. 733 6.2 Dynamic DNS 735 Dynamic DNS updates (DDNS) [RFC2136][RFC3007] is a standardized 736 mechanism for dynamically updating the DNS. It works equally well 737 with stateless address autoconfiguration (SLAAC), DHCPv6 or manual 738 address configuration. It is important to consider how each of these 739 behave if IP address-based authentication, instead of stronger 740 mechanisms [RFC3007], was used in the updates; manual addresses are 741 static and can be configured; DHCPv6 addresses could be reasonably 742 static or dynamic, depending on the deployment, and could or could 743 not be configured on the DNS server for the long term; SLAAC 744 addresses are typically stable for a long time, but could require 745 work to be configured and maintained. As relying on IP addresses for 746 Dynamic DNS is rather insecure at best, stronger authentication 747 should always be used; however, this requires that the authorization 748 keying will be explicitly configured using unspecified operational 749 methods. 751 Note that with DHCP it is also possible that the DHCP server updates 752 the DNS, not the host. The host might only indicate in the DHCP 753 exchange which hostname it would prefer, and the DHCP server would 754 make the appropriate updates. Nonetheless, while this makes setting 755 up a secure channel between the updater and the DNS server easier, it 756 does not help much with "content" security, i.e., whether the 757 hostname was acceptable -- if the DNS server does not include 758 policies, they must be included in the DHCP server (e.g., a regular 759 host should not be able to state that its name is "www.example.com"). 760 DHCP-initiated DDNS updates have been extensively described in 761 [I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and 762 [I-D.ietf-dnsext-dhcid-rr]. 764 The nodes must somehow be configured with the information about the 765 servers where they will attempt to update their addresses, sufficient 766 security material for authenticating themselves to the server, and 767 the hostname they will be updating. Unless otherwise configured, the 768 first could be obtained by looking up the authoritative name servers 769 for the hostname; the second must be configured explicitly unless one 770 chooses to trust the IP address-based authentication (not a good 771 idea); and lastly, the nodename is typically pre-configured somehow 772 on the node, e.g. at install time. 774 Care should be observed when updating the addresses not to use longer 775 TTLs for addresses than are preferred lifetimes for the 776 autoconfigured addresses, so that if the node is renumbered in a 777 managed fashion, the amount of stale DNS information is kept to the 778 minimum. That is, if the preferred lifetime of an address expires, 779 the TTL of the record needs be modified unless it was already done 780 before the expiration. For better flexibility, the DNS TTL should be 781 much shorter (e.g., a half or a third) than the lifetime of an 782 address; that way, the node can start lowering the DNS TTL if it 783 seems like the address has not been renewed/refreshed in a while. 784 Some discussion on how an administrator could manage the DNS TTL is 785 included in [I-D.ietf-v6ops-renumbering-procedure]; this could be 786 applied to (smart) hosts as well. 788 7. Considerations about Reverse DNS Updating 790 Updating the reverse DNS zone may be difficult because of the split 791 authority over an address. However, first we have to consider the 792 applicability of reverse DNS in the first place. 794 7.1 Applicability of Reverse DNS 796 Today, some applications use reverse DNS to either look up some hints 797 about the topological information associated with an address (e.g. 798 resolving web server access logs), or as a weak form of a security 799 check, to get a feel whether the user's network administrator has 800 "authorized" the use of the address (on the premises that adding a 801 reverse record for an address would signal some form of 802 authorization). 804 One additional, maybe slightly more useful usage is ensuring the 805 reverse and forward DNS contents match (by looking up the pointer to 806 the name by the IP address from the reverse tree, and ensuring that 807 the records under the name in the forward tree also include the IP 808 address) and correspond to a configured name or domain. As a 809 security check, it is typically accompanied by other mechanisms, such 810 as a user/password login; the main purpose of the reverse+forward DNS 811 check is to weed out the majority of unauthorized users, and if 812 someone managed to bypass the checks, he would still need to 813 authenticate "properly". 815 It may also be desirable to store IPsec keying material corresponding 816 to an IP address to the reverse DNS, as justified and described in 817 [I-D.ietf-ipseckey-rr]. 819 It is not clear whether it makes sense to require or recommend that 820 reverse DNS records be updated. In many cases, it would just make 821 more sense to use proper mechanisms for security (or topological 822 information lookup) in the first place. At minimum, the applications 823 which use it as a generic authorization (in the sense that a record 824 exists at all) should be modified as soon as possible to avoid such 825 lookups completely. 827 The applicability is discussed at more length in 828 [I-D.ietf-dnsop-inaddr-required]. 830 7.2 Manual or Custom DNS Updates 832 Reverse DNS can of course be updated using manual or custom methods. 833 These are not further described here, except for one special case. 835 One way to deploy reverse DNS would be to use wildcard records, for 836 example, by configuring one name for a subnet (/64) or a site (/48). 837 As a concrete example, a site (or the site's ISP) could configure the 838 reverses of the prefix 2001:db8:f00::/48 to point to one name using a 839 wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR 840 site.example.com." Naturally, such a name could not be verified from 841 the forward DNS, but would at least provide some form of "topological 842 information" or "weak authorization" if that is really considered to 843 be useful. Note that this is not actually updating the DNS as such, 844 as the whole point is to avoid DNS updates completely by manually 845 configuring a generic name. 847 7.3 DDNS with Stateless Address Autoconfiguration 849 Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in 850 some regard, while being more difficult in another, as described 851 below. 853 The address space administrator decides whether the hosts are trusted 854 to update their reverse DNS records or not. If they are, a simple 855 address-based authorization is typically sufficient (i.e., check that 856 the DNS update is done from the same IP address as the record being 857 updated); stronger security can also be used [RFC3007]. If they 858 aren't allowed to update the reverses, no update can occur. (Such 859 address-based update authorization operationally requires that 860 ingress filtering [RFC3704] has been set up at the border of the site 861 where the updates occur, and as close to the updater as possible.) 863 Address-based authorization is simpler with reverse DNS (as there is 864 a connection between the record and the address) than with forward 865 DNS. However, when a stronger form of security is used, forward DNS 866 updates are simpler to manage because the host knows the record it's 867 updating, and can be assumed to have an association with the domain. 868 Note that the user may roam to different networks, and does not 869 necessarily have any association with the owner of that address space 870 -- so, assuming stronger form of authorization for reverse DNS 871 updates than an address association is generally unfeasible. 873 Moreover, the reverse zones must be cleaned up by an unspecified 874 janitorial process: the node does not typically know a priori that it 875 will be disconnected, and cannot send a DNS update using the correct 876 source address to remove a record. 878 A problem with defining the clean-up process is that it is difficult 879 to ensure that a specific IP address and the corresponding record are 880 no longer being used. Considering the huge address space, and the 881 unlikelihood of collision within 64 bits of the interface 882 identifiers, a process which would remove the record after no traffic 883 has been seen from a node in a long period of time (e.g., a month or 884 year) might be one possible approach. 886 To insert or update the record, the node must discover the DNS server 887 to send the update to somehow, similar to as discussed in Section 888 6.2. One way to automate this is looking up the DNS server 889 authoritative (e.g., through SOA record) for the IP address being 890 updated, but the security material (unless the IP address-based 891 authorization is trusted) must also be established by some other 892 means. 894 One should note that Cryptographically Generated Addresses 895 [I-D.ietf-send-cga] (CGAs) may require a slightly different kind of 896 treatment. CGAs are addresses where the interface identifier is 897 calculated from a public key, a modifier (used as a nonce), the 898 subnet prefix, and other data. Depending on the usage profile, CGAs 899 might or might not be changed periodically due to e.g., privacy 900 reasons. As the CGA address is not predicatable, a reverse record 901 can only reasonably be inserted in the DNS by the node which 902 generates the address. 904 7.4 DDNS with DHCP 906 With DHCPv4, the reverse DNS name is typically already inserted to 907 the DNS that reflects to the name (e.g., "dhcp-67.example.com"). One 908 can assume similar practice may become commonplace with DHCPv6 as 909 well; all such mappings would be pre-configured, and would require no 910 updating. 912 If a more explicit control is required, similar considerations as 913 with SLAAC apply, except for the fact that typically one must update 914 a reverse DNS record instead of inserting one (if an address 915 assignment policy that reassigns disused addresses is adopted) and 916 updating a record seems like a slightly more difficult thing to 917 secure. However, it is yet uncertain how DHCPv6 is going to be used 918 for address assignment. 920 Note that when using DHCP, either the host or the DHCP server could 921 perform the DNS updates; see the implications in Section 6.2. 923 If disused addresses were to be reassigned, host-based DDNS reverse 924 updates would need policy considerations for DNS record modification, 925 as noted above. On the other hand, if disused address were not to be 926 assigned, host-based DNS reverse updates would have similar 927 considerations as SLAAC in Section 7.3. Server-based updates have 928 similar properties except that the janitorial process could be 929 integrated with DHCP address assignment. 931 7.5 DDNS with Dynamic Prefix Delegation 933 In cases where a prefix, instead of an address, is being used and 934 updated, one should consider what is the location of the server where 935 DDNS updates are made. That is, where the DNS server is located: 937 1. At the same organization as the prefix delegator. 939 2. At the site where the prefixes are delegated to. In this case, 940 the authority of the DNS reverse zone corresponding to the 941 delegated prefix is also delegated to the site. 943 3. Elsewhere; this implies a relationship between the site and where 944 DNS server is located, and such a relationship should be rather 945 straightforward to secure as well. Like in the previous case, 946 the authority of the DNS reverse zone is also delegated. 948 In the first case, managing the reverse DNS (delegation) is simpler 949 as the DNS server and the prefix delegator are in the same 950 administrative domain (as there is no need to delegate anything at 951 all); alternatively, the prefix delegator might forgo DDNS reverse 952 capability altogether, and use e.g., wildcard records (as described 953 in Section 7.2). In the other cases, it can be slighly more 954 difficult, particularly as the site will have to configure the DNS 955 server to be authoritative for the delegated reverse zone, implying 956 automatic configuration of the DNS server -- as the prefix may be 957 dynamic. 959 Managing the DDNS reverse updates is typically simple in the second 960 case, as the updated server is located at the local site, and 961 arguably IP address-based authentication could be sufficient (or if 962 not, setting up security relationships would be simpler). As there 963 is an explicit (security) relationship between the parties in the 964 third case, setting up the security relationships to allow reverse 965 DDNS updates should be rather straightforward as well. In the first 966 case, however, setting up and managing such relationships might be a 967 lot more difficult. 969 8. Miscellaneous DNS Considerations 971 This section describes miscellaneous considerations about DNS which 972 seem related to IPv6, for which no better place has been found in 973 this document. 975 8.1 NAT-PT with DNS-ALG 977 The DNS-ALG component of NAT-PT mangles A records to look like AAAA 978 records to the IPv6-only nodes. Numerous problems have been 979 identified with DNS-ALG [I-D.durand-v6ops-natpt-dns-alg-issues]. 980 This is a strong reason not to use NAT-PT in the first place. 982 8.2 Renumbering Procedures and Applications' Use of DNS 984 One of the most difficult problems of systematic IP address 985 renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that 986 an application which looks up a DNS name disregards information such 987 as TTL, and uses the result obtained from DNS as long as it happens 988 to be stored in the memory of the application. For applications 989 which run for a long time, this could be days, weeks or even months; 990 some applications may be clever enough to organize the data 991 structures and functions in such a manner that look-ups get refreshed 992 now and then. 994 While the issue appears to have a clear solution, "fix the 995 applications", practically this is not reasonable immediate advice; 996 the TTL information is not typically available in the APIs and 997 libraries (so, the advice becomes "fix the applications, APIs and 998 libraries"), and a lot more analysis is needed on how to practically 999 go about to achieve the ultimate goal of avoiding using the names 1000 longer than expected. 1002 9. Acknowledgements 1004 Some recommendations (Section 4.3, Section 5.1) about IPv6 service 1005 provisioning were moved here from [I-D.ietf-v6ops-mech-v2] by Erik 1006 Nordmark and Bob Gilligan. Havard Eidnes and Michael Patton provided 1007 useful feedback and improvements. Scott Rose, Rob Austein, Masataka 1008 Ohta, and Mark Andrews helped in clarifying the issues regarding 1009 additional data and the use of TTL. Jefsey Morfin, Ralph Droms, 1010 Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and 1011 Rob Austein provided useful feedback during the WG last call. Thomas 1012 Narten provided extensive feedback during the IESG evaluation. 1014 10. Security Considerations 1016 This document reviews the operational procedures for IPv6 DNS 1017 operations and does not have security considerations in itself. 1019 However, it is worth noting that in particular with Dynamic DNS 1020 Updates, security models based on the source address validation are 1021 very weak and cannot be recommended -- they could only be considered 1022 in the environments where ingress filtering [RFC3704] has been 1023 deployed. On the other hand, it should be noted that setting up an 1024 authorization mechanism (e.g., a shared secret, or public-private 1025 keys) between a node and the DNS server has to be done manually, and 1026 may require quite a bit of time and expertise. 1028 To re-emphasize which was already stated, the reverse+forward DNS 1029 check provides very weak security at best, and the only 1030 (questionable) security-related use for them may be in conjunction 1031 with other mechanisms when authenticating a user. 1033 11. References 1035 11.1 Normative References 1037 [I-D.ietf-dnsop-ipv6-dns-configuration] 1038 Jeong, J., "IPv6 Host Configuration of DNS Server 1039 Information Approaches", 1040 draft-ietf-dnsop-ipv6-dns-configuration-01 (work in 1041 progress), June 2004. 1043 [I-D.ietf-dnsop-ipv6-transport-guidelines] 1044 Durand, A. and J. Ihren, "DNS IPv6 transport operational 1045 guidelines", draft-ietf-dnsop-ipv6-transport-guidelines-02 1046 (work in progress), March 2004. 1048 [I-D.ietf-dnsop-misbehavior-against-aaaa] 1049 Morishita, Y. and T. Jinmei, "Common Misbehavior against 1050 DNS Queries for IPv6 Addresses", 1051 draft-ietf-dnsop-misbehavior-against-aaaa-01 (work in 1052 progress), April 2004. 1054 [I-D.ietf-ipv6-deprecate-site-local] 1055 Huitema, C. and B. Carpenter, "Deprecating Site Local 1056 Addresses", draft-ietf-ipv6-deprecate-site-local-03 (work 1057 in progress), March 2004. 1059 [I-D.ietf-v6ops-application-transition] 1060 Shin, M., "Application Aspects of IPv6 Transition", 1061 draft-ietf-v6ops-application-transition-03 (work in 1062 progress), June 2004. 1064 [I-D.ietf-v6ops-renumbering-procedure] 1065 Baker, F., Lear, E. and R. Droms, "Procedures for 1066 Renumbering an IPv6 Network without a Flag Day", 1067 draft-ietf-v6ops-renumbering-procedure-01 (work in 1068 progress), July 2004. 1070 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 1071 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 1072 April 1997. 1074 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1075 Specification", RFC 2181, July 1997. 1077 [RFC2182] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection 1078 and Operation of Secondary DNS Servers", BCP 16, RFC 2182, 1079 July 1997. 1081 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 1082 Autoconfiguration", RFC 2462, December 1998. 1084 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 1085 2671, August 1999. 1087 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1088 Update", RFC 3007, November 2000. 1090 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 1091 Stateless Address Autoconfiguration in IPv6", RFC 3041, 1092 January 2001. 1094 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1095 via IPv4 Clouds", RFC 3056, February 2001. 1097 [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, 1098 August 2001. 1100 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 1101 M. Carney, "Dynamic Host Configuration Protocol for IPv6 1102 (DHCPv6)", RFC 3315, July 2003. 1104 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O. and T. 1105 Hain, "Representing Internet Protocol version 6 (IPv6) 1106 Addresses in the Domain Name System (DNS)", RFC 3363, 1107 August 2002. 1109 [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) 1110 Support for Internet Protocol version 6 (IPv6)", RFC 3364, 1111 August 2002. 1113 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 1114 (IPv6) Addressing Architecture", RFC 3513, April 2003. 1116 [RFC3596] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS 1117 Extensions to Support IP Version 6", RFC 3596, October 1118 2003. 1120 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 1121 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1122 December 2003. 1124 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1125 (DHCP) Service for IPv6", RFC 3736, April 2004. 1127 11.2 Informative References 1129 [I-D.durand-v6ops-natpt-dns-alg-issues] 1130 Durand, A., "Issues with NAT-PT DNS ALG in RFC2766", 1131 draft-durand-v6ops-natpt-dns-alg-issues-00 (work in 1132 progress), February 2003. 1134 [I-D.huitema-v6ops-teredo] 1135 Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1136 NATs", draft-huitema-v6ops-teredo-02 (work in progress), 1137 June 2004. 1139 [I-D.huston-6to4-reverse-dns] 1140 Huston, G., "6to4 Reverse DNS", 1141 draft-huston-6to4-reverse-dns-02 (work in progress), April 1142 2004. 1144 [I-D.ietf-dhc-ddns-resolution] 1145 Stapp, M., "Resolution of DNS Name Conflicts Among DHCP 1146 Clients", draft-ietf-dhc-ddns-resolution-06 (work in 1147 progress), October 2003. 1149 [I-D.ietf-dhc-fqdn-option] 1150 Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option", 1151 draft-ietf-dhc-fqdn-option-06 (work in progress), October 1152 2003. 1154 [I-D.ietf-dnsext-dhcid-rr] 1155 Stapp, M., Lemon, T. and A. Gustafsson, "A DNS RR for 1156 encoding DHCP information (DHCID RR)", 1157 draft-ietf-dnsext-dhcid-rr-07 (work in progress), October 1158 2003. 1160 [I-D.ietf-dnsop-bad-dns-res] 1161 Larson, M. and P. Barber, "Observed DNS Resolution 1162 Misbehavior", draft-ietf-dnsop-bad-dns-res-01 (work in 1163 progress), June 2003. 1165 [I-D.ietf-dnsop-dontpublish-unreachable] 1166 Hazel, P., "IP Addresses that should never appear in the 1167 public DNS", draft-ietf-dnsop-dontpublish-unreachable-03 1168 (work in progress), February 2002. 1170 [I-D.ietf-dnsop-inaddr-required] 1171 Senie, D., "Requiring DNS IN-ADDR Mapping", 1172 draft-ietf-dnsop-inaddr-required-05 (work in progress), 1173 April 2004. 1175 [I-D.ietf-ipseckey-rr] 1176 Richardson, M., "A method for storing IPsec keying 1177 material in DNS", draft-ietf-ipseckey-rr-10 (work in 1178 progress), April 2004. 1180 [I-D.ietf-ipv6-unique-local-addr] 1181 Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1182 Addresses", draft-ietf-ipv6-unique-local-addr-05 (work in 1183 progress), June 2004. 1185 [I-D.ietf-send-cga] 1186 Aura, T., "Cryptographically Generated Addresses (CGA)", 1187 draft-ietf-send-cga-06 (work in progress), April 2004. 1189 [I-D.ietf-v6ops-3gpp-analysis] 1190 Wiljakka, J., "Analysis on IPv6 Transition in 3GPP 1191 Networks", draft-ietf-v6ops-3gpp-analysis-10 (work in 1192 progress), May 2004. 1194 [I-D.ietf-v6ops-mech-v2] 1195 Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1196 for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-03 1197 (work in progress), June 2004. 1199 [I-D.ietf-v6ops-onlinkassumption] 1200 Roy, S., Durand, A. and J. Paugh, "IPv6 Neighbor Discovery 1201 On-Link Assumption Considered Harmful", 1202 draft-ietf-v6ops-onlinkassumption-02 (work in progress), 1203 May 2004. 1205 [I-D.ietf-v6ops-v6onbydefault] 1206 Roy, S., Durand, A. and J. Paugh, "Issues with Dual Stack 1207 IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-02 1208 (work in progress), May 2004. 1210 [I-D.jeong-dnsop-ipv6-dns-discovery] 1211 Jeong, J., "IPv6 DNS Discovery based on Router 1212 Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-01 1213 (work in progress), February 2004. 1215 [I-D.moore-6to4-dns] 1216 Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work 1217 in progress), October 2002. 1219 [I-D.ohta-preconfigured-dns] 1220 Ohta, M., "Preconfigured DNS Server Addresses", 1221 draft-ohta-preconfigured-dns-01 (work in progress), 1222 February 2004. 1224 [I-D.savola-v6ops-6bone-mess] 1225 Savola, P., "Moving from 6bone to IPv6 Internet", 1226 draft-savola-v6ops-6bone-mess-01 (work in progress), 1227 November 2002. 1229 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 1230 Translation - Protocol Translation (NAT-PT)", RFC 2766, 1231 February 2000. 1233 [RFC2826] Internet Architecture Board, "IAB Technical Comment on the 1234 Unique DNS Root", RFC 2826, May 2000. 1236 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1237 Networks", BCP 84, RFC 3704, March 2004. 1239 Authors' Addresses 1241 Alain Durand 1242 SUN Microsystems, Inc. 1243 17 Network circle UMPL17-202 1244 Menlo Park, CA 94025 1245 USA 1247 EMail: Alain.Durand@sun.com 1249 Johan Ihren 1250 Autonomica 1251 Bellmansgatan 30 1252 SE-118 47 Stockholm 1253 Sweden 1255 EMail: johani@autonomica.se 1256 Pekka Savola 1257 CSC/FUNET 1258 Espoo 1259 Finland 1261 EMail: psavola@funet.fi 1263 Appendix A. Site-local Addressing Considerations for DNS 1265 As site-local addressing is being deprecated, the considerations for 1266 site-local addressing are discussed briefly here. Unique local 1267 addressing format [I-D.ietf-ipv6-unique-local-addr] has been proposed 1268 as a replacement, but being work-in-progress, it is not considered 1269 further. 1271 The interactions with DNS come in two flavors: forward and reverse 1272 DNS. 1274 To actually use site-local addresses within a site, this implies the 1275 deployment of a "split-faced" or a fragmented DNS name space, for the 1276 zones internal to the site, and the outsiders' view to it. The 1277 procedures to achieve this are not elaborated here. The implication 1278 is that site-local addresses must not be published in the public DNS. 1280 To faciliate reverse DNS (if desired) with site-local addresses, the 1281 stub resolvers must look for DNS information from the local DNS 1282 servers, not e.g. starting from the root servers, so that the 1283 site-local information may be provided locally. Note that the 1284 experience of private addresses in IPv4 has shown that the root 1285 servers get loaded for requests for private address lookups in any 1286 case. 1288 Appendix B. Issues about Additional Data or TTL 1290 [[ note to the RFC-editor: remove this section upon publication. ]] 1292 This appendix tries to describe the apparent rought consensus about 1293 additional data and TTL issues (sections 4.4 and 4.5), and present 1294 questions when there appears to be no consensus. The point of 1295 recording them here is to focus the discussio and get feedback. 1297 Resolved: 1299 a. If some critical additional data RRsets wouldn't fit, you set the 1300 TC bit even if some RRsets did fit. 1302 b. If some courtesy additional data RRsets wouldn't fit, you never 1303 set the TC bit, but rather remove (at least some of) the courtesy 1304 RRsets. 1306 c. DNS servers should implement sanity checks on the resulting glue, 1307 e.g., to disable circular dependencies. Then the responding 1308 servers can use at-or-below-a-zone-cut criterion to determine 1309 whether the additional data is critical or not. 1311 Open issues (at least): 1313 1. if some critical additional data RRsets would fit, but some 1314 wouldn't, and TC has to be set (see above), should one rather 1315 remove the additional data that did fit, keep it, or leave 1316 unspecified? 1318 2. if some courtesy additional data RRsets would fit, but some 1319 wouldn't, and some will have to be removed from the response (no 1320 TC is set, see above), what to do -- remove all courtesy RRsets, 1321 keep all that fit, or leave unspecified? 1323 3. is it acceptable to use the transport used in the DNS query as a 1324 hint which records to keep if not removing all the RRsets, if: a) 1325 having to decide which critical additional data to keep, or b) 1326 having to decide which courtesy additional data to keep? 1328 4. (this issue was discussed in section 4.5) if one RRset has TTL of 1329 100 seconds, and another the TTL of 300 seconds, what should the 1330 caching server do after 100 seconds? Keep returning just one 1331 RRset when returning additional data, or discard the other RRset 1332 from the cache? 1334 5. how do we move forward from here? If we manage to get to some 1335 form of consensus, how do we record it: a) just in 1336 draft-ietf-dnsop-ipv6-dns-issues (note that it's Informational 1337 category only!), b) a separate BCP or similar by DNSEXT WG(?), 1338 clarifying and giving recommendations, c) something else, what? 1340 Intellectual Property Statement 1342 The IETF takes no position regarding the validity or scope of any 1343 Intellectual Property Rights or other rights that might be claimed to 1344 pertain to the implementation or use of the technology described in 1345 this document or the extent to which any license under such rights 1346 might or might not be available; nor does it represent that it has 1347 made any independent effort to identify any such rights. Information 1348 on the procedures with respect to rights in RFC documents can be 1349 found in BCP 78 and BCP 79. 1351 Copies of IPR disclosures made to the IETF Secretariat and any 1352 assurances of licenses to be made available, or the result of an 1353 attempt made to obtain a general license or permission for the use of 1354 such proprietary rights by implementers or users of this 1355 specification can be obtained from the IETF on-line IPR repository at 1356 http://www.ietf.org/ipr. 1358 The IETF invites any interested party to bring to its attention any 1359 copyrights, patents or patent applications, or other proprietary 1360 rights that may cover technology that may be required to implement 1361 this standard. Please address the information to the IETF at 1362 ietf-ipr@ietf.org. 1364 Disclaimer of Validity 1366 This document and the information contained herein are provided on an 1367 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1368 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1369 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1370 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1371 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1372 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1374 Copyright Statement 1376 Copyright (C) The Internet Society (2004). This document is subject 1377 to the rights, licenses and restrictions contained in BCP 78, and 1378 except as set forth therein, the authors retain all their rights. 1380 Acknowledgment 1382 Funding for the RFC Editor function is currently provided by the 1383 Internet Society.