idnits 2.17.1 draft-ietf-dnsop-ipv6-dns-issues-10.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 1374. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1351. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1358. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1364. ** 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 25) being 70 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 1028 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 (October 24, 2004) is 7096 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 1279, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-dnsop-ipv6-dns-configuration-04 ** 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-03 == Outdated reference: A later version (-12) exists of draft-ietf-dhc-ddns-resolution-08 == 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-06 == 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-06 == 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: 19 errors (**), 0 flaws (~~), 22 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: April 24, 2005 J. Ihren 4 Autonomica 5 P. Savola 6 CSC/FUNET 7 October 24, 2004 9 Operational Considerations and Issues with IPv6 DNS 10 draft-ietf-dnsop-ipv6-dns-issues-10.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 32 http://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 April 24, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). 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 Which Additional Data to Keep, If Any? . . . . . . . . 11 77 4.4.3 Discussion of the Problems . . . . . . . . . . . . . . 12 78 4.5 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 13 79 4.6 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 14 80 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 15 81 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 15 82 5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 16 83 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 17 84 6. Considerations about Forward DNS Updating . . . . . . . . . . 17 85 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 17 86 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 18 87 7. Considerations about Reverse DNS Updating . . . . . . . . . . 19 88 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 19 89 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 20 90 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 20 91 7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 21 92 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 22 93 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 23 94 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 23 95 8.2 Renumbering Procedures and Applications' Use of DNS . . . 23 96 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 97 10. Security Considerations . . . . . . . . . . . . . . . . . . 24 98 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 99 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 24 100 11.2 Informative References . . . . . . . . . . . . . . . . . . . 26 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28 102 A. Site-local Addressing Considerations for DNS . . . . . . . . . 29 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 The IP version used to transport the DNS 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 at all). 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 [RFC3901] for more information. 184 1.4 Query Type '*' and A/AAAA Records 186 QTYPE=* is typically only used for debugging or management purposes; 187 it is worth keeping in mind that QTYPE=* ("ANY" queries) only return 188 any available RRsets, not *all* the RRsets, because the caches do not 189 necessarily have all the RRsets and have no way of guaranteeing that 190 they have all the RRsets. Therefore, to get both A and AAAA records 191 reliably, two separate queries must be made. 193 2. DNS Considerations about Special IPv6 Addresses 195 There are a couple of IPv6 address types which are somewhat special; 196 these are considered here. 198 2.1 Limited-scope Addresses 200 The IPv6 addressing architecture [RFC3513] includes two kinds of 201 local-use addresses: link-local (fe80::/10) and site-local 202 (fec0::/10). The site-local addresses have been deprecated 203 [RFC3879], and are only discussed in Appendix A. 205 Link-local addresses should never be published in DNS (whether in 206 forward or reverse tree), because they have only local (to the 207 connected link) significance 208 [I-D.ietf-dnsop-dontpublish-unreachable]. 210 2.2 Temporary Addresses 212 Temporary addresses defined in RFC3041 [RFC3041] (sometimes called 213 "privacy addresses") use a random number as the interface identifier. 214 Having DNS AAAA records that are updated to always contain the 215 current value of a node's temporary address would defeat the purpose 216 of the mechanism and is not recommended. However, it would still be 217 possible to return a non-identifiable name (e.g., the IPv6 address in 218 hexadecimal format), as described in [RFC3041]. 220 2.3 6to4 Addresses 222 6to4 [RFC3056] specifies an automatic tunneling mechanism which maps 223 a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. 225 If the reverse DNS population would be desirable (see Section 7.1 for 226 applicability), there are a number of possible ways to do so 227 [I-D.moore-6to4-dns], some more applicable than the others. 229 The main proposal [I-D.huston-6to4-reverse-dns] aims to design an 230 autonomous reverse-delegation system that anyone being capable of 231 communicating using a specific 6to4 address would be able to set up a 232 reverse delegation to the corresponding 6to4 prefix. This could be 233 deployed by e.g., Regional Internet Registries (RIRs). This is a 234 practical solution, but may have some scalability concerns. 236 2.4 Other Transition Mechanisms 238 6to4, above, is mentioned as a case of an IPv6 transition mechanism 239 requiring special considerations. In general, mechanisms which 240 include a special prefix may need a custom solution; otherwise, for 241 example when IPv4 address is embedded as the suffix or not embedded 242 at all, special solutions are likely not needed. This is why only 243 6to4 and Teredo [I-D.huitema-v6ops-teredo] are described. 245 Note that it does not seem feasible to provide reverse DNS with 246 another automatic tunneling mechanism, Teredo; this is because the 247 IPv6 address is based on the IPv4 address and UDP port of the current 248 NAT mapping which is likely to be relatively short-lived. 250 3. Observed DNS Implementation Misbehaviour 252 Several classes of misbehaviour in DNS servers, load-balancers and 253 resolvers have been observed. Most of these are rather generic, not 254 only applicable to IPv6 -- but in some cases, the consequences of 255 this misbehaviour are extremely severe in IPv6 environments and 256 deserve to be mentioned. 258 3.1 Misbehaviour of DNS Servers and Load-balancers 260 There are several classes of misbehaviour in certain DNS servers and 261 load-balancers which have been noticed and documented 262 [I-D.ietf-dnsop-misbehavior-against-aaaa]: some implementations 263 silently drop queries for unimplemented DNS records types, or provide 264 wrong answers to such queries (instead of a proper negative reply). 265 While typically these issues are not limited to AAAA records, the 266 problems are aggravated by the fact that AAAA records are being 267 queried instead of (mainly) A records. 269 The problems are serious because when looking up a DNS name, typical 270 getaddrinfo() implementations, with AF_UNSPEC hint given, first try 271 to query the AAAA records of the name, and after receiving a 272 response, query the A records. This is done in a serial fashion -- 273 if the first query is never responded to (instead of properly 274 returning a negative answer), significant timeouts will occur. 276 In consequence, this is an enormous problem for IPv6 deployments, and 277 in some cases, IPv6 support in the software has even been disabled 278 due to these problems. 280 The solution is to fix or retire those misbehaving implementations, 281 but that is likely not going to be effective. There are some 282 possible ways to mitigate the problem, e.g., by performing the 283 lookups somewhat in parallel and reducing the timeout as long as at 284 least one answer has been received; but such methods remain to be 285 investigated; slightly more on this is included in Section 5. 287 3.2 Misbehaviour of DNS Resolvers 289 Several classes of misbehaviour have also been noticed in DNS 290 resolvers [I-D.ietf-dnsop-bad-dns-res]. However, these do not seem 291 to directly impair IPv6 use, and are only referred to for 292 completeness. 294 4. Recommendations for Service Provisioning using DNS 296 When names are added in the DNS to facilitate a service, there are 297 several general guidelines to consider to be able to do it as 298 smoothly as possible. 300 4.1 Use of Service Names instead of Node Names 302 It makes sense to keep logically separate services by a node separate 303 in the DNS, due to a number of reasons, for example: 305 o It allows more flexibility and ease for migration of (only a part 306 of) services from one node to another, 308 o It allows configuring different properties (e.g., TTL) for each 309 service, and 311 o It allows deciding separately for each service whether to publish 312 the IPv6 addresses or not (in cases if some services are more 313 IPv6-ready than others). 315 Using SRV records [RFC2782] would avoid these problems. 316 Unfortunately, those are not sufficiently widely used to be 317 applicable in most cases. Hence an operation technique is to use 318 service names instead of node names (or, "hostnames"). This 319 operational technique is not specific to IPv6, but required to 320 understand the considerations described in Section 4.2 and Section 321 4.3. 323 For example, assume a node named "pobox.example.com" provides both 324 SMTP and IMAP service. Instead of configuring the MX records to 325 point at "pobox.example.com", and configuring the mail clients to 326 look up the mail via IMAP from "pobox.example.com", one could use 327 e.g., "smtp.example.com" for SMTP (for both message submission and 328 mail relaying between SMTP servers) and "imap.example.com" for IMAP. 329 Note that in the specific case of SMTP relaying, the server itself 330 must typically also be configured to know all its names to ensure 331 loops do not occur. DNS can provide a layer of indirection between 332 service names and where the service actually is, and using which 333 addresses. (Obviously, when wanting to reach a specific node, one 334 should use the hostname rather than a service name.) 336 4.2 Separate vs the Same Service Names for IPv4 and IPv6 338 The service naming can be achieved in basically two ways: when a 339 service is named "service.example.com" for IPv4, the IPv6-enabled 340 service could be either added to "service.example.com", or added 341 separately under a different name, e.g., in a sub-domain, like, 342 "service.ipv6.example.com". 344 These two methods have different characteristics. Using a different 345 name allows for easier service piloting, minimizing the disturbance 346 to the "regular" users of IPv4 service; however, the service would 347 not be used transparently, without the user/application explicitly 348 finding it and asking for it -- which would be a disadvantage in most 349 cases. When the different name is under a sub-domain, if the 350 services are deployed within a restricted network (e.g., inside an 351 enterprise), it's possible to prefer them transparently, at least to 352 a degree, by modifying the DNS search path; however, this is a 353 suboptimal solution. Using the same service name is the "long-term" 354 solution, but may degrade performance for those clients whose IPv6 355 performance is lower than IPv4, or does not work as well (see Section 356 4.3 for more). 358 In most cases, it makes sense to pilot or test a service using 359 separate service names, and move to the use of the same name when 360 confident enough that the service level will not degrade for the 361 users unaware of IPv6. 363 4.3 Adding the Records Only when Fully IPv6-enabled 365 The recommendation is that AAAA records for a service should not be 366 added to the DNS until all of following are true: 368 1. The address is assigned to the interface on the node. 370 2. The address is configured on the interface. 372 3. The interface is on a link which is connected to the IPv6 373 infrastructure. 375 In addition, if the AAAA record is added for the node, instead of 376 service as recommended, all the services of the node should be 377 IPv6-enabled prior to adding the resource record. 379 For example, if an IPv6 node is isolated from an IPv6 perspective 380 (e.g., it is not connected to IPv6 Internet) constraint #3 would mean 381 that it should not have an address in the DNS. 383 Consider the case of two dual-stack nodes, which both have IPv6 384 enabled, but the server does not have (global) IPv6 connectivity. As 385 the client looks up the server's name, only A records are returned 386 (if the recommendations above are followed), and no IPv6 387 communication, which would have been unsuccessful, is even attempted. 389 The issues are not always so black-and-white. Usually it's important 390 if the service offered using both protocols is of roughly equal 391 quality, using the appropriate metrics for the service (e.g., 392 latency, throughput, low packet loss, general reliability, etc.) -- 393 this is typically very important especially for interactive or 394 real-time services. In many cases, the quality of IPv6 connectivity 395 may not yet be equal to that of IPv4, at least globally -- this has 396 to be taken into consideration when enabling services 397 [I-D.savola-v6ops-6bone-mess]. 399 4.4 Behaviour of Additional Data in IPv4/IPv6 Environments 401 DNS responses do not always fit in a single UDP packet. We'll 402 examine the cases which happen when this is due to too much data in 403 the Additional Section. 405 4.4.1 Description of Additional Data Scenarios 407 There are two kinds of additional data: 409 1. "critical" additional data; this must be included in all 410 scenarios, with all the RRsets, and 412 2. "courtesy" additional data; this could be sent in full, with only 413 a few RRsets, or with no RRsets, and can be fetched separately as 414 well, but at the cost of additional queries. 416 The responding server can algorithmically determine which type the 417 additional data is by checking whether it's at or below a zone cut. 419 Only those additional data records (even if sometimes carelessly 420 termed "glue") are considered "critical" or real "glue" if and only 421 if they meet the abovementioned condition, as specified in Section 422 4.2.1 of [RFC1034]. 424 Remember that resource record sets (RRsets) are never "broken up", so 425 if a name has 4 A records and 5 AAAA records, you can either return 426 all 9, all 4 A records, all 5 AAAA records or nothing. In 427 particular, notice that for the "critical" additional data getting 428 all the RRsets can be critical. 430 In particular, [RFC2181] specifies (in Section 9) that: 432 a. if all the "critical" RRsets do not fit, the sender should set 433 the TC bit, and the recipient should discard the whole response 434 and retry using mechanism allowing larger responses such as TCP. 436 b. "courtesy" additional data should not cause the setting of TC 437 bit, but instead all the non-fitting additional data RRsets 438 should be removed. 440 An example of the "courtesy" additional data is A/AAAA records in 441 conjunction of MX records is shown in Section 4.5; an example of the 442 "critical" additional data is shown below (where getting both the A 443 and AAAA RRsets is critical): 445 child.example.com. IN NS ns.child.example.com. 446 ns.child.example.com. IN A 192.0.2.1 447 ns.child.example.com. IN AAAA 2001:db8::1 449 When there is too much courtesy additional data, at least the 450 non-fitting RRsets should be removed [RFC2181]; however, as the 451 additional data is not critical, even all of it could be safely 452 removed. 454 When there is too much critical additional data, TC bit will have to 455 be set, and the recipient should ignore the response and retry using 456 TCP; if some data were to be left in the UDP response, the issue is 457 which data could be retained. 459 Failing to discard the response with TC bit set leads to a protocol 460 problem. Omitting only some of the RRsets if all would not fit leads 461 to a performance problem. These are discussed in Section 4.4.3. 463 4.4.2 Which Additional Data to Keep, If Any? 465 If the implementation decides to keep as much data (whether 466 "critical" or "courtesy") as possible in the UDP responses, it might 467 be tempting to use the transport of the DNS query as a hint in either 468 of these cases: return the AAAA records if the query was done over 469 IPv6, or return the A records if the query was done over IPv4. 470 However, this breaks the model of independence of DNS transport and 471 resource records, as noted in Section 1.2. 473 With courtesy additional data, as long as enough RRsets will be 474 removed so that TC will not be set, it is allowed to send as many 475 complete RRsets as the implementations prefers. However, the 476 implementations are also free to omit all such RRsets, even if 477 complete. Removing all the RRsets if some would not fit obviates a 478 performance problem, which would require the users to issue second 479 queries to obtain consistent information. 481 With critical additional data, the alternatives are either returning 482 nothing (and absolutely requiring a retry with TCP) or returning 483 something (working also in the case if the recipient does not discard 484 the response and retry using TCP) in addition to setting the TC bit. 485 If the process for selecting "something" from the critical data would 486 otherwise be practically "flipping the coin" between A and AAAA 487 records, it could be argued that if one looked at the transport of 488 the query, it would have a larger possibility of being right than 489 just 50/50. In other words, if the returned critical additional data 490 would have to be selected somehow, using something more sophisticated 491 than a random process would seem justifiable. 493 That is, leaving in some intelligently selected critical additional 494 data is a tradeoff between creating an optimization for those 495 resolvers which ignore the "should discard" recommendation, and a 496 causing a protocol problem by propagating inconsistent information 497 about "critical" records in the caches. 499 Similarly, leaving in the complete courtesy additional data RRsets 500 instead of removing all the RRsets is a performance tradeoff as 501 described in the next section. 503 4.4.3 Discussion of the Problems 505 As noted above, the temptation for omitting only some of the 506 additional data based on the transport of the query could be 507 problematic. In particular, there appears to be little justification 508 for doing so in the case of "courtesy" data. 510 For courtesy additional data, this causes a performance problem as 511 this requires that the clients issue re-query for the potentially 512 omitted RRsets. For critical additional data, this causes a 513 potential protocol problem if the response is not discarded and the 514 query not re-tried with TCP, as the nameservers might be reachable 515 only through the omitted RRsets. 517 If an implementation would look at the transport used for the query, 518 it is worth remembering that often the host using the records is 519 different from the node requesting them from the authoritative DNS 520 server (or even a caching resolver). So, whichever version the 521 requestor (e.g., a recursive server in the middle) uses makes no 522 difference to the ultimate user of the records, whose transport 523 capabilities might differ from those of the requestor. This might 524 result in e.g., inappropriately returning A records to an IPv6-only 525 node, going through a translation, or opening up another IP-level 526 session (e.g., a PDP context [I-D.ietf-v6ops-3gpp-analysis]). 527 Therefore, at least in many scenarios, it would be very useful if the 528 information returned would be consistent and complete -- or if that 529 is not feasible, return no misleading information but rather leave it 530 to the client to query again. 532 The problem of too much additional data seems to be an operational 533 one: the zone administrator entering too many records which will be 534 returned either truncated (or missing some RRsets, depending on 535 implementations) to the users. A protocol fix for this is using 536 EDNS0 [RFC2671] to signal the capacity for larger UDP packet sizes, 537 pushing up the relevant threshold. Further, DNS server 538 implementations should rather omit courtesy additional data 539 completely rather than including only some RRsets [RFC2181]. An 540 operational fix for this is having the DNS server implementations 541 return a warning when the administrators create zones which would 542 result in too much additional data being returned. Further, DNS 543 server implementations should warn of or disallow such zone 544 configurations which are recursive or otherwise difficult to manage 545 by the protocol. 547 Additionally, to avoid the case where an application would not get an 548 address at all due to some of "courtesy" additional data being 549 omitted, the resolvers should be able to query the specific records 550 of the desired protocol, not just rely on getting all the required 551 RRsets in the additional section. 553 4.5 The Use of TTL for IPv4 and IPv6 RRs 555 In the previous section, we discussed a danger with queries, 556 potentially leading to omitting RRsets from the additional section; 557 this could happen to both critical and "courtesy" additional data 558 (however, both of these are recommended against in [RFC2181]). This 559 section discusses another problem with courtesy additional data, 560 leading to omitting RRsets in cached data, highlighted in the 561 IPv4/IPv6 environment. 563 The behaviour of DNS caching when different TTL values are used for 564 different RRsets of the same name requires explicit discussion. For 565 example, let's consider a part of a zone: 567 example.com. 300 IN MX foo.example.com. 568 foo.example.com. 300 IN A 192.0.2.1 569 foo.example.com. 100 IN AAAA 2001:db8::1 571 When a caching resolver asks for the MX record of example.com, it 572 gets back "foo.example.com". It may also get back either one or both 573 of the A and AAAA records in the additional section. So, there are 574 three cases about returning records for the MX in the additional 575 section: 577 1. We get back no A or AAAA RRsets: this is the simplest case, 578 because then we have to query which information is required 579 explicitly, guaranteeing that we get all the information we're 580 interested in. 582 2. We get back all the RRsets: this is an optimization as there is 583 no need to perform more queries, causing lower latency. However, 584 it is impossible to guarantee that in fact we would always get 585 back all the records (the only way to ensure that is to send a 586 AAAA query for the name after getting the cached reply with A 587 records or vice versa). 589 3. We only get back A or AAAA RRsets even if both existed: this is 590 indistinguishable from the previous case, and may have 591 performance problems at least in certain environments as 592 described in the previous section. 594 As the third case was considered in the previous section, we assume 595 we get back both A and AAAA records of foo.example.com, or the stub 596 resolver explicitly asks, in two separate queries, both A and AAAA 597 records. 599 After 100 seconds, the AAAA record is removed from the cache(s) 600 because its TTL expired. It could be argued to be useful for the 601 caching resolvers to discard the A record when the shorter TTL (in 602 this case, for the AAAA record) expires; this would avoid the 603 situation where there would be a window of 200 seconds when 604 incomplete information is returned from the cache. Further argument 605 for discarding is that in the normal operation, the TTL values are so 606 high that very likely the incurred additional queries would not be 607 noticeable, compared to the obtained performance optimization. The 608 behaviour in this scenario is unspecified. 610 To simplify the situation, it might help to use the same TTL for all 611 the resource record sets referring to the same name, unless there is 612 a particular reason for not doing so. However, there are some 613 scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where 614 a different strategy is preferable. 616 Thus, applications that use the response should not rely on a 617 particular TTL configuration. For example, even if an application 618 gets a response that only has the A record in the example described 619 above, it should be still aware that there could be a AAAA record for 620 "foo.example.com". That is, the application should try to fetch the 621 missing records itself if it needs the record. 623 4.6 IPv6 Transport Guidelines for DNS Servers 625 As described in Section 1.3 and [RFC3901], there should continue to 626 be at least one authoritative IPv4 DNS server for every zone, even if 627 the zone has only IPv6 records. (Note that obviously, having more 628 servers with robust connectivity would be preferable, but this is the 629 minimum recommendation; also see [RFC2182].) 631 5. Recommendations for DNS Resolver IPv6 Support 633 When IPv6 is enabled on a node, there are several things to consider 634 to ensure that the process is as smooth as possible. 636 5.1 DNS Lookups May Query IPv6 Records Prematurely 638 The system library that implements the getaddrinfo() function for 639 looking up names is a critical piece when considering the robustness 640 of enabling IPv6; it may come in basically three flavours: 642 1. The system library does not know whether IPv6 has been enabled in 643 the kernel of the operating system: it may start looking up AAAA 644 records with getaddrinfo() and AF_UNSPEC hint when the system is 645 upgraded to a system library version which supports IPv6. 647 2. The system library might start to perform IPv6 queries with 648 getaddrinfo() only when IPv6 has been enabled in the kernel. 649 However, this does not guarantee that there exists any useful 650 IPv6 connectivity (e.g., the node could be isolated from the 651 other IPv6 networks, only having link-local addresses). 653 3. The system library might implement a toggle which would apply 654 some heuristics to the "IPv6-readiness" of the node before 655 starting to perform queries; for example, it could check whether 656 only link-local IPv6 address(es) exists, or if at least one 657 global IPv6 address exists. 659 First, let us consider generic implications of unnecessary queries 660 for AAAA records: when looking up all the records in the DNS, AAAA 661 records are typically tried first, and then A records. These are 662 done in serial, and the A query is not performed until a response is 663 received to the AAAA query. Considering the misbehaviour of DNS 664 servers and load-balancers, as described in Section 3.1, the look-up 665 delay for AAAA may incur additional unnecessary latency, and 666 introduce a component of unreliability. 668 One option here could be to do the queries partially in parallel; for 669 example, if the final response to the AAAA query is not received in 670 0.5 seconds, start performing the A query while waiting for the 671 result (immediate parallelism might be unoptimal, at least without 672 information sharing between the look-up threads, as that would 673 probably lead to duplicate non-cached delegation chain lookups). 675 An additional concern is the address selection, which may, in some 676 circumstances, prefer AAAA records over A records even when the node 677 does not have any IPv6 connectivity [I-D.ietf-v6ops-v6onbydefault]. 678 In some cases, the implementation may attempt to connect or send a 679 datagram on a physical link [I-D.ietf-v6ops-onlinkassumption], 680 incurring very long protocol timeouts, instead of quickly failing 681 back to IPv4. 683 Now, we can consider the issues specific to each of the three 684 possibilities: 686 In the first case, the node performs a number of completely useless 687 DNS lookups as it will not be able to use the returned AAAA records 688 anyway. (The only exception is where the application desires to know 689 what's in the DNS, but not use the result for communication.) One 690 should be able to disable these unnecessary queries, for both latency 691 and reliability reasons. However, as IPv6 has not been enabled, the 692 connections to IPv6 addresses fail immediately, and if the 693 application is programmed properly, the application can fall 694 gracefully back to IPv4 [I-D.ietf-v6ops-application-transition]. 696 The second case is similar to the first, except it happens to a 697 smaller set of nodes when IPv6 has been enabled but connectivity has 698 not been provided yet; similar considerations apply, with the 699 exception that IPv6 records, when returned, will be actually tried 700 first which may typically lead to long timeouts. 702 The third case is a bit more complex: optimizing away the DNS lookups 703 with only link-locals is probably safe (but may be desirable with 704 different lookup services which getaddrinfo() may support), as the 705 link-locals are typically automatically generated when IPv6 is 706 enabled, and do not indicate any form of IPv6 connectivity. That is, 707 performing DNS lookups only when a non-link-local address has been 708 configured on any interface could be beneficial -- this would be an 709 indication that either the address has been configured either from a 710 router advertisement, DHCPv6 [RFC3315], or manually. Each would 711 indicate at least some form of IPv6 connectivity, even though there 712 would not be guarantees of it. 714 These issues should be analyzed at more depth, and the fixes found 715 consensus on, perhaps in a separate document. 717 5.2 Obtaining a List of DNS Recursive Resolvers 719 In scenarios where DHCPv6 is available, a host can discover a list of 720 DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server" 721 option [RFC3646]. This option can be passed to a host through a 722 subset of DHCPv6 [RFC3736]. 724 The IETF is considering the development of alternative mechanisms for 725 obtaining the list of DNS recursive name servers when DHCPv6 is 726 unavailable or inappropriate. No decision about taking on this 727 development work has been reached as of this writing (Aug 2004) 728 [I-D.ietf-dnsop-ipv6-dns-configuration]. 730 In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms 731 under consideration for development include the use of well-known 732 addresses [I-D.ohta-preconfigured-dns] and the use of Router 733 Advertisements to convey the information 734 [I-D.jeong-dnsop-ipv6-dns-discovery]. 736 Note that even though IPv6 DNS resolver discovery is a recommended 737 procedure, it is not required for dual-stack nodes in dual-stack 738 networks as IPv6 DNS records can be queried over IPv4 as well as 739 IPv6. Obviously, nodes which are meant to function without manual 740 configuration in IPv6-only networks must implement the DNS resolver 741 discovery function. 743 5.3 IPv6 Transport Guidelines for Resolvers 745 As described in Section 1.3 and [RFC3901], the recursive resolvers 746 should be IPv4-only or dual-stack to be able to reach any IPv4-only 747 DNS server. Note that this requirement is also fulfilled by an 748 IPv6-only stub resolver pointing to a dual-stack recursive DNS 749 resolver. 751 6. Considerations about Forward DNS Updating 753 While the topic how to enable updating the forward DNS, i.e., the 754 mapping from names to the correct new addresses, is not specific to 755 IPv6, it should be considered especially due to the advent of 756 Stateless Address Autoconfiguration [RFC2462]. 758 Typically forward DNS updates are more manageable than doing them in 759 the reverse DNS, because the updater can often be assumed to "own" a 760 certain DNS name -- and we can create a form of security relationship 761 with the DNS name and the node which is allowed to update it to point 762 to a new address. 764 A more complex form of DNS updates -- adding a whole new name into a 765 DNS zone, instead of updating an existing name -- is considered out 766 of scope for this memo as it could require zone-wide authentication. 767 Adding a new name in the forward zone is a problem which is still 768 being explored with IPv4, and IPv6 does not seem to add much new in 769 that area. 771 6.1 Manual or Custom DNS Updates 773 The DNS mappings can also be maintained by hand, in a semi-automatic 774 fashion or by running non-standardized protocols. These are not 775 considered at more length in this memo. 777 6.2 Dynamic DNS 779 Dynamic DNS updates (DDNS) [RFC2136][RFC3007] is a standardized 780 mechanism for dynamically updating the DNS. It works equally well 781 with stateless address autoconfiguration (SLAAC), DHCPv6 or manual 782 address configuration. It is important to consider how each of these 783 behave if IP address-based authentication, instead of stronger 784 mechanisms [RFC3007], was used in the updates. 786 1. manual addresses are static and can be configured 788 2. DHCPv6 addresses could be reasonably static or dynamic, depending 789 on the deployment, and could or could not be configured on the 790 DNS server for the long term 792 3. SLAAC addresses are typically stable for a long time, but could 793 require work to be configured and maintained. 795 As relying on IP addresses for Dynamic DNS is rather insecure at 796 best, stronger authentication should always be used; however, this 797 requires that the authorization keying will be explicitly configured 798 using unspecified operational methods. 800 Note that with DHCP it is also possible that the DHCP server updates 801 the DNS, not the host. The host might only indicate in the DHCP 802 exchange which hostname it would prefer, and the DHCP server would 803 make the appropriate updates. Nonetheless, while this makes setting 804 up a secure channel between the updater and the DNS server easier, it 805 does not help much with "content" security, i.e., whether the 806 hostname was acceptable -- if the DNS server does not include 807 policies, they must be included in the DHCP server (e.g., a regular 808 host should not be able to state that its name is "www.example.com"). 809 DHCP-initiated DDNS updates have been extensively described in 810 [I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and 811 [I-D.ietf-dnsext-dhcid-rr]. 813 The nodes must somehow be configured with the information about the 814 servers where they will attempt to update their addresses, sufficient 815 security material for authenticating themselves to the server, and 816 the hostname they will be updating. Unless otherwise configured, the 817 first could be obtained by looking up the authoritative name servers 818 for the hostname; the second must be configured explicitly unless one 819 chooses to trust the IP address-based authentication (not a good 820 idea); and lastly, the nodename is typically pre-configured somehow 821 on the node, e.g., at install time. 823 Care should be observed when updating the addresses not to use longer 824 TTLs for addresses than are preferred lifetimes for the addresses, so 825 that if the node is renumbered in a managed fashion, the amount of 826 stale DNS information is kept to the minimum. That is, if the 827 preferred lifetime of an address expires, the TTL of the record needs 828 be modified unless it was already done before the expiration. For 829 better flexibility, the DNS TTL should be much shorter (e.g., a half 830 or a third) than the lifetime of an address; that way, the node can 831 start lowering the DNS TTL if it seems like the address has not been 832 renewed/refreshed in a while. Some discussion on how an 833 administrator could manage the DNS TTL is included in 834 [I-D.ietf-v6ops-renumbering-procedure]; this could be applied to 835 (smart) hosts as well. 837 7. Considerations about Reverse DNS Updating 839 Updating the reverse DNS zone may be difficult because of the split 840 authority over an address. However, first we have to consider the 841 applicability of reverse DNS in the first place. 843 7.1 Applicability of Reverse DNS 845 Today, some applications use reverse DNS to either look up some hints 846 about the topological information associated with an address (e.g. 847 resolving web server access logs), or as a weak form of a security 848 check, to get a feel whether the user's network administrator has 849 "authorized" the use of the address (on the premises that adding a 850 reverse record for an address would signal some form of 851 authorization). 853 One additional, maybe slightly more useful usage is ensuring that the 854 reverse and forward DNS contents match (by looking up the pointer to 855 the name by the IP address from the reverse tree, and ensuring that a 856 record under the name in the forward tree points to the IP address) 857 and correspond to a configured name or domain. As a security check, 858 it is typically accompanied by other mechanisms, such as a 859 user/password login; the main purpose of the reverse+forward DNS 860 check is to weed out the majority of unauthorized users, and if 861 someone managed to bypass the checks, he would still need to 862 authenticate "properly". 864 It may also be desirable to store IPsec keying material corresponding 865 to an IP address to the reverse DNS, as justified and described in 866 [I-D.ietf-ipseckey-rr]. 868 It is not clear whether it makes sense to require or recommend that 869 reverse DNS records be updated. In many cases, it would just make 870 more sense to use proper mechanisms for security (or topological 871 information lookup) in the first place. At minimum, the applications 872 which use it as a generic authorization (in the sense that a record 873 exists at all) should be modified as soon as possible to avoid such 874 lookups completely. 876 The applicability is discussed at more length in 877 [I-D.ietf-dnsop-inaddr-required]. 879 7.2 Manual or Custom DNS Updates 881 Reverse DNS can of course be updated using manual or custom methods. 882 These are not further described here, except for one special case. 884 One way to deploy reverse DNS would be to use wildcard records, for 885 example, by configuring one name for a subnet (/64) or a site (/48). 886 As a concrete example, a site (or the site's ISP) could configure the 887 reverses of the prefix 2001:db8:f00::/48 to point to one name using a 888 wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR 889 site.example.com." Naturally, such a name could not be verified from 890 the forward DNS, but would at least provide some form of "topological 891 information" or "weak authorization" if that is really considered to 892 be useful. Note that this is not actually updating the DNS as such, 893 as the whole point is to avoid DNS updates completely by manually 894 configuring a generic name. 896 7.3 DDNS with Stateless Address Autoconfiguration 898 Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in 899 some regard, while being more difficult in another, as described 900 below. 902 The address space administrator decides whether the hosts are trusted 903 to update their reverse DNS records or not. If they are trusted and 904 deployed at the same site (e.g., not across the Internet), a simple 905 address-based authorization is typically sufficient (i.e., check that 906 the DNS update is done from the same IP address as the record being 907 updated); stronger security can also be used [RFC3007]. If they 908 aren't allowed to update the reverses, no update can occur. However, 909 such address-based update authorization operationally requires that 910 ingress filtering [RFC3704] has been set up at the border of the site 911 where the updates occur, and as close to the updater as possible. 913 Address-based authorization is simpler with reverse DNS (as there is 914 a connection between the record and the address) than with forward 915 DNS. However, when a stronger form of security is used, forward DNS 916 updates are simpler to manage because the host can be assumed to have 917 an association with the domain. Note that the user may roam to 918 different networks, and does not necessarily have any association 919 with the owner of that address space -- so, assuming stronger form of 920 authorization for reverse DNS updates than an address association is 921 generally unfeasible. 923 Moreover, the reverse zones must be cleaned up by an unspecified 924 janitorial process: the node does not typically know a priori that it 925 will be disconnected, and cannot send a DNS update using the correct 926 source address to remove a record. 928 A problem with defining the clean-up process is that it is difficult 929 to ensure that a specific IP address and the corresponding record are 930 no longer being used. Considering the huge address space, and the 931 unlikelihood of collision within 64 bits of the interface 932 identifiers, a process which would remove the record after no traffic 933 has been seen from a node in a long period of time (e.g., a month or 934 year) might be one possible approach. 936 To insert or update the record, the node must discover the DNS server 937 to send the update to somehow, similar to as discussed in Section 938 6.2. One way to automate this is looking up the DNS server 939 authoritative (e.g., through SOA record) for the IP address being 940 updated, but the security material (unless the IP address-based 941 authorization is trusted) must also be established by some other 942 means. 944 One should note that Cryptographically Generated Addresses 945 [I-D.ietf-send-cga] (CGAs) may require a slightly different kind of 946 treatment. CGAs are addresses where the interface identifier is 947 calculated from a public key, a modifier (used as a nonce), the 948 subnet prefix, and other data. Depending on the usage profile, CGAs 949 might or might not be changed periodically due to e.g., privacy 950 reasons. As the CGA address is not predicatable, a reverse record 951 can only reasonably be inserted in the DNS by the node which 952 generates the address. 954 7.4 DDNS with DHCP 956 With DHCPv4, the reverse DNS name is typically already inserted to 957 the DNS that reflects to the name (e.g., "dhcp-67.example.com"). One 958 can assume similar practice may become commonplace with DHCPv6 as 959 well; all such mappings would be pre-configured, and would require no 960 updating. 962 If a more explicit control is required, similar considerations as 963 with SLAAC apply, except for the fact that typically one must update 964 a reverse DNS record instead of inserting one (if an address 965 assignment policy that reassigns disused addresses is adopted) and 966 updating a record seems like a slightly more difficult thing to 967 secure. However, it is yet uncertain how DHCPv6 is going to be used 968 for address assignment. 970 Note that when using DHCP, either the host or the DHCP server could 971 perform the DNS updates; see the implications in Section 6.2. 973 If disused addresses were to be reassigned, host-based DDNS reverse 974 updates would need policy considerations for DNS record modification, 975 as noted above. On the other hand, if disused address were not to be 976 assigned, host-based DNS reverse updates would have similar 977 considerations as SLAAC in Section 7.3. Server-based updates have 978 similar properties except that the janitorial process could be 979 integrated with DHCP address assignment. 981 7.5 DDNS with Dynamic Prefix Delegation 983 In cases where a prefix, instead of an address, is being used and 984 updated, one should consider what is the location of the server where 985 DDNS updates are made. That is, where the DNS server is located: 987 1. At the same organization as the prefix delegator. 989 2. At the site where the prefixes are delegated to. In this case, 990 the authority of the DNS reverse zone corresponding to the 991 delegated prefix is also delegated to the site. 993 3. Elsewhere; this implies a relationship between the site and where 994 DNS server is located, and such a relationship should be rather 995 straightforward to secure as well. Like in the previous case, 996 the authority of the DNS reverse zone is also delegated. 998 In the first case, managing the reverse DNS (delegation) is simpler 999 as the DNS server and the prefix delegator are in the same 1000 administrative domain (as there is no need to delegate anything at 1001 all); alternatively, the prefix delegator might forgo DDNS reverse 1002 capability altogether, and use e.g., wildcard records (as described 1003 in Section 7.2). In the other cases, it can be slighly more 1004 difficult, particularly as the site will have to configure the DNS 1005 server to be authoritative for the delegated reverse zone, implying 1006 automatic configuration of the DNS server -- as the prefix may be 1007 dynamic. 1009 Managing the DDNS reverse updates is typically simple in the second 1010 case, as the updated server is located at the local site, and 1011 arguably IP address-based authentication could be sufficient (or if 1012 not, setting up security relationships would be simpler). As there 1013 is an explicit (security) relationship between the parties in the 1014 third case, setting up the security relationships to allow reverse 1015 DDNS updates should be rather straightforward as well (but IP 1016 address-based authentication might not be acceptable). In the first 1017 case, however, setting up and managing such relationships might be a 1018 lot more difficult. 1020 8. Miscellaneous DNS Considerations 1022 This section describes miscellaneous considerations about DNS which 1023 seem related to IPv6, for which no better place has been found in 1024 this document. 1026 8.1 NAT-PT with DNS-ALG 1028 The DNS-ALG component of NAT-PT mangles A records to look like AAAA 1029 records to the IPv6-only nodes. Numerous problems have been 1030 identified with DNS-ALG [I-D.durand-v6ops-natpt-dns-alg-issues]. 1031 This is a strong reason not to use NAT-PT in the first place. 1033 8.2 Renumbering Procedures and Applications' Use of DNS 1035 One of the most difficult problems of systematic IP address 1036 renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that 1037 an application which looks up a DNS name disregards information such 1038 as TTL, and uses the result obtained from DNS as long as it happens 1039 to be stored in the memory of the application. For applications 1040 which run for a long time, this could be days, weeks or even months; 1041 some applications may be clever enough to organize the data 1042 structures and functions in such a manner that look-ups get refreshed 1043 now and then. 1045 While the issue appears to have a clear solution, "fix the 1046 applications", practically this is not reasonable immediate advice; 1047 the TTL information is not typically available in the APIs and 1048 libraries (so, the advice becomes "fix the applications, APIs and 1049 libraries"), and a lot more analysis is needed on how to practically 1050 go about to achieve the ultimate goal of avoiding using the names 1051 longer than expected. 1053 9. Acknowledgements 1055 Some recommendations (Section 4.3, Section 5.1) about IPv6 service 1056 provisioning were moved here from [I-D.ietf-v6ops-mech-v2] by Erik 1057 Nordmark and Bob Gilligan. Havard Eidnes and Michael Patton provided 1058 useful feedback and improvements. Scott Rose, Rob Austein, Masataka 1059 Ohta, and Mark Andrews helped in clarifying the issues regarding 1060 additional data and the use of TTL. Jefsey Morfin, Ralph Droms, 1061 Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and 1062 Rob Austein provided useful feedback during the WG last call. Thomas 1063 Narten provided extensive feedback during the IESG evaluation. 1065 10. Security Considerations 1067 This document reviews the operational procedures for IPv6 DNS 1068 operations and does not have security considerations in itself. 1070 However, it is worth noting that in particular with Dynamic DNS 1071 Updates, security models based on the source address validation are 1072 very weak and cannot be recommended -- they could only be considered 1073 in the environments where ingress filtering [RFC3704] has been 1074 deployed. On the other hand, it should be noted that setting up an 1075 authorization mechanism (e.g., a shared secret, or public-private 1076 keys) between a node and the DNS server has to be done manually, and 1077 may require quite a bit of time and expertise. 1079 To re-emphasize which was already stated, the reverse+forward DNS 1080 check provides very weak security at best, and the only 1081 (questionable) security-related use for them may be in conjunction 1082 with other mechanisms when authenticating a user. 1084 11. References 1086 11.1 Normative References 1088 [I-D.ietf-dnsop-ipv6-dns-configuration] 1089 Jeong, J., "IPv6 Host Configuration of DNS Server 1090 Information Approaches", 1091 draft-ietf-dnsop-ipv6-dns-configuration-04 (work in 1092 progress), September 2004. 1094 [I-D.ietf-dnsop-misbehavior-against-aaaa] 1095 Morishita, Y. and T. Jinmei, "Common Misbehavior against 1096 DNS Queries for IPv6 Addresses", 1097 draft-ietf-dnsop-misbehavior-against-aaaa-01 (work in 1098 progress), April 2004. 1100 [I-D.ietf-v6ops-application-transition] 1101 Shin, M., "Application Aspects of IPv6 Transition", 1102 draft-ietf-v6ops-application-transition-03 (work in 1103 progress), June 2004. 1105 [I-D.ietf-v6ops-renumbering-procedure] 1106 Baker, F., Lear, E. and R. Droms, "Procedures for 1107 Renumbering an IPv6 Network without a Flag Day", 1108 draft-ietf-v6ops-renumbering-procedure-01 (work in 1109 progress), July 2004. 1111 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1112 STD 13, RFC 1034, November 1987. 1114 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 1115 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 1116 April 1997. 1118 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1119 Specification", RFC 2181, July 1997. 1121 [RFC2182] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection 1122 and Operation of Secondary DNS Servers", BCP 16, RFC 2182, 1123 July 1997. 1125 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 1126 Autoconfiguration", RFC 2462, December 1998. 1128 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 1129 2671, August 1999. 1131 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1132 Update", RFC 3007, November 2000. 1134 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 1135 Stateless Address Autoconfiguration in IPv6", RFC 3041, 1136 January 2001. 1138 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1139 via IPv4 Clouds", RFC 3056, February 2001. 1141 [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, 1142 August 2001. 1144 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 1145 M. Carney, "Dynamic Host Configuration Protocol for IPv6 1146 (DHCPv6)", RFC 3315, July 2003. 1148 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O. and T. 1149 Hain, "Representing Internet Protocol version 6 (IPv6) 1150 Addresses in the Domain Name System (DNS)", RFC 3363, 1151 August 2002. 1153 [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) 1154 Support for Internet Protocol version 6 (IPv6)", RFC 3364, 1155 August 2002. 1157 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 1158 (IPv6) Addressing Architecture", RFC 3513, April 2003. 1160 [RFC3596] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS 1161 Extensions to Support IP Version 6", RFC 3596, October 1162 2003. 1164 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 1165 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1166 December 2003. 1168 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1169 (DHCP) Service for IPv6", RFC 3736, April 2004. 1171 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 1172 Addresses", RFC 3879, September 2004. 1174 [RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational 1175 Guidelines", BCP 91, RFC 3901, September 2004. 1177 11.2 Informative References 1179 [I-D.durand-v6ops-natpt-dns-alg-issues] 1180 Durand, A., "Issues with NAT-PT DNS ALG in RFC2766", 1181 draft-durand-v6ops-natpt-dns-alg-issues-00 (work in 1182 progress), February 2003. 1184 [I-D.huitema-v6ops-teredo] 1185 Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1186 NATs", draft-huitema-v6ops-teredo-02 (work in progress), 1187 June 2004. 1189 [I-D.huston-6to4-reverse-dns] 1190 Huston, G., "6to4 Reverse DNS Delegation", 1191 draft-huston-6to4-reverse-dns-03 (work in progress), 1192 October 2004. 1194 [I-D.ietf-dhc-ddns-resolution] 1195 Stapp, M., "Resolution of DNS Name Conflicts Among DHCP 1196 Clients", draft-ietf-dhc-ddns-resolution-08 (work in 1197 progress), October 2004. 1199 [I-D.ietf-dhc-fqdn-option] 1200 Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option", 1201 draft-ietf-dhc-fqdn-option-07 (work in progress), July 1202 2004. 1204 [I-D.ietf-dnsext-dhcid-rr] 1205 Stapp, M., Lemon, T. and A. Gustafsson, "A DNS RR for 1206 encoding DHCP information (DHCID RR)", 1207 draft-ietf-dnsext-dhcid-rr-08 (work in progress), July 1208 2004. 1210 [I-D.ietf-dnsop-bad-dns-res] 1211 Larson, M. and P. Barber, "Observed DNS Resolution 1212 Misbehavior", draft-ietf-dnsop-bad-dns-res-02 (work in 1213 progress), July 2004. 1215 [I-D.ietf-dnsop-dontpublish-unreachable] 1216 Hazel, P., "IP Addresses that should never appear in the 1217 public DNS", draft-ietf-dnsop-dontpublish-unreachable-03 1218 (work in progress), February 2002. 1220 [I-D.ietf-dnsop-inaddr-required] 1221 Senie, D., "Requiring DNS IN-ADDR Mapping", 1222 draft-ietf-dnsop-inaddr-required-05 (work in progress), 1223 April 2004. 1225 [I-D.ietf-ipseckey-rr] 1226 Richardson, M., "A method for storing IPsec keying 1227 material in DNS", draft-ietf-ipseckey-rr-11 (work in 1228 progress), July 2004. 1230 [I-D.ietf-ipv6-unique-local-addr] 1231 Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1232 Addresses", draft-ietf-ipv6-unique-local-addr-06 (work in 1233 progress), September 2004. 1235 [I-D.ietf-send-cga] 1236 Aura, T., "Cryptographically Generated Addresses (CGA)", 1237 draft-ietf-send-cga-06 (work in progress), April 2004. 1239 [I-D.ietf-v6ops-3gpp-analysis] 1240 Wiljakka, J., "Analysis on IPv6 Transition in 3GPP 1241 Networks", draft-ietf-v6ops-3gpp-analysis-10 (work in 1242 progress), May 2004. 1244 [I-D.ietf-v6ops-mech-v2] 1245 Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1246 for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-06 1247 (work in progress), September 2004. 1249 [I-D.ietf-v6ops-onlinkassumption] 1250 Roy, S., Durand, A. and J. Paugh, "IPv6 Neighbor Discovery 1251 On-Link Assumption Considered Harmful", 1252 draft-ietf-v6ops-onlinkassumption-02 (work in progress), 1253 May 2004. 1255 [I-D.ietf-v6ops-v6onbydefault] 1256 Roy, S., Durand, A. and J. Paugh, "Issues with Dual Stack 1257 IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 1258 (work in progress), July 2004. 1260 [I-D.jeong-dnsop-ipv6-dns-discovery] 1261 Jeong, J., "IPv6 DNS Discovery based on Router 1262 Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-02 1263 (work in progress), July 2004. 1265 [I-D.moore-6to4-dns] 1266 Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work 1267 in progress), October 2002. 1269 [I-D.ohta-preconfigured-dns] 1270 Ohta, M., "Preconfigured DNS Server Addresses", 1271 draft-ohta-preconfigured-dns-01 (work in progress), 1272 February 2004. 1274 [I-D.savola-v6ops-6bone-mess] 1275 Savola, P., "Moving from 6bone to IPv6 Internet", 1276 draft-savola-v6ops-6bone-mess-01 (work in progress), 1277 November 2002. 1279 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 1280 Translation - Protocol Translation (NAT-PT)", RFC 2766, 1281 February 2000. 1283 [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 1284 specifying the location of services (DNS SRV)", RFC 2782, 1285 February 2000. 1287 [RFC2826] Internet Architecture Board, "IAB Technical Comment on the 1288 Unique DNS Root", RFC 2826, May 2000. 1290 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1291 Networks", BCP 84, RFC 3704, March 2004. 1293 Authors' Addresses 1295 Alain Durand 1296 SUN Microsystems, Inc. 1297 17 Network circle UMPL17-202 1298 Menlo Park, CA 94025 1299 USA 1301 EMail: Alain.Durand@sun.com 1302 Johan Ihren 1303 Autonomica 1304 Bellmansgatan 30 1305 SE-118 47 Stockholm 1306 Sweden 1308 EMail: johani@autonomica.se 1310 Pekka Savola 1311 CSC/FUNET 1312 Espoo 1313 Finland 1315 EMail: psavola@funet.fi 1317 Appendix A. Site-local Addressing Considerations for DNS 1319 As site-local addressing has been deprecated, the considerations for 1320 site-local addressing are discussed briefly here. Unique local 1321 addressing format [I-D.ietf-ipv6-unique-local-addr] has been proposed 1322 as a replacement, but being work-in-progress, it is not considered 1323 further. 1325 The interactions with DNS come in two flavors: forward and reverse 1326 DNS. 1328 To actually use site-local addresses within a site, this implies the 1329 deployment of a "split-faced" or a fragmented DNS name space, for the 1330 zones internal to the site, and the outsiders' view to it. The 1331 procedures to achieve this are not elaborated here. The implication 1332 is that site-local addresses must not be published in the public DNS. 1334 To faciliate reverse DNS (if desired) with site-local addresses, the 1335 stub resolvers must look for DNS information from the local DNS 1336 servers, not e.g. starting from the root servers, so that the 1337 site-local information may be provided locally. Note that the 1338 experience of private addresses in IPv4 has shown that the root 1339 servers get loaded for requests for private address lookups in any 1340 case. 1342 Intellectual Property Statement 1344 The IETF takes no position regarding the validity or scope of any 1345 Intellectual Property Rights or other rights that might be claimed to 1346 pertain to the implementation or use of the technology described in 1347 this document or the extent to which any license under such rights 1348 might or might not be available; nor does it represent that it has 1349 made any independent effort to identify any such rights. Information 1350 on the procedures with respect to rights in RFC documents can be 1351 found in BCP 78 and BCP 79. 1353 Copies of IPR disclosures made to the IETF Secretariat and any 1354 assurances of licenses to be made available, or the result of an 1355 attempt made to obtain a general license or permission for the use of 1356 such proprietary rights by implementers or users of this 1357 specification can be obtained from the IETF on-line IPR repository at 1358 http://www.ietf.org/ipr. 1360 The IETF invites any interested party to bring to its attention any 1361 copyrights, patents or patent applications, or other proprietary 1362 rights that may cover technology that may be required to implement 1363 this standard. Please address the information to the IETF at 1364 ietf-ipr@ietf.org. 1366 Disclaimer of Validity 1368 This document and the information contained herein are provided on an 1369 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1370 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1371 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1372 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1373 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1374 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1376 Copyright Statement 1378 Copyright (C) The Internet Society (2004). This document is subject 1379 to the rights, licenses and restrictions contained in BCP 78, and 1380 except as set forth therein, the authors retain all their rights. 1382 Acknowledgment 1384 Funding for the RFC Editor function is currently provided by the 1385 Internet Society.