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