idnits 2.17.1 draft-ietf-dnsop-ipv6-dns-issues-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Nov 2003) is 7469 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) ** Downref: Normative reference to an Informational RFC: RFC 3363 (ref. '2') == Outdated reference: A later version (-02) exists of draft-ietf-dnsop-ipv6-transport-guidelines-01 -- Obsolete informational reference (is this intentional?): RFC 3152 (ref. '4') (Obsoleted by RFC 3596) -- Obsolete informational reference (is this intentional?): RFC 3513 (ref. '5') (Obsoleted by RFC 4291) == Outdated reference: A later version (-03) exists of draft-ietf-ipv6-deprecate-site-local-02 -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '8') (Obsoleted by RFC 4941) == Outdated reference: A later version (-06) exists of draft-ietf-dnsop-bad-dns-res-01 == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-v6onbydefault-00 == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-onlinkassumption-00 == Outdated reference: A later version (-01) exists of draft-ohta-preconfigured-dns-00 == Outdated reference: A later version (-12) exists of draft-jeong-dnsop-ipv6-dns-discovery-00 == Outdated reference: A later version (-04) exists of draft-ietf-dhc-dhcpv6-stateless-01 -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. '21') (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 2766 (ref. '24') (Obsoleted by RFC 4966) == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-mech-v2-01 Summary: 3 errors (**), 0 flaws (~~), 12 warnings (==), 7 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: May 1, 2004 J. Ihren 4 Autonomica 5 P. Savola 6 CSC/FUNET 7 Nov 2003 9 Operational Considerations and Issues with IPv6 DNS 10 draft-ietf-dnsop-ipv6-dns-issues-03.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on May 1, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 This memo presents operational considerations and issues with IPv6 41 Domain Name System (DNS), including a summary of special IPv6 42 addresses, documentation of known DNS implementation misbehaviour, 43 recommendations and considerations on how to perform DNS naming for 44 service provisioning and for DNS resolver IPv6 support, 45 considerations for DNS updates for both the forward and reverse 46 trees, and miscellaneous issues. This memo is aimed to include a 47 summary of information about IPv6 DNS considerations for those who 48 have experience with IPv4 DNS. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . . . 3 54 1.2 Difference of DNS Transport and DNS Records . . . . . . . . . 3 55 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . . . 4 56 2. DNS Considerations about Special IPv6 Addresses . . . . . . . 4 57 2.1 Limited-scope Addresses . . . . . . . . . . . . . . . . . . . 4 58 2.2 Privacy (RFC3041) Address . . . . . . . . . . . . . . . . . . 4 59 2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 5 61 3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . . . 5 62 3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . . . 6 63 4. Recommendations for Service Provisioning using DNS . . . . . . 6 64 4.1 Use of Service Names instead of Node Names . . . . . . . . . . 6 65 4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . . . 7 66 4.3 Adding the Records Only when Fully IPv6-enabled . . . . . . . 7 67 4.4 IPv6 Transport Guidelines for DNS Servers . . . . . . . . . . 8 68 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 8 69 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . . . 8 70 5.2 Recursive DNS Server Discovery . . . . . . . . . . . . . . . . 10 71 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . . . 10 72 6. Considerations about Forward DNS Updating . . . . . . . . . . 10 73 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . . . 10 74 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 7. Considerations about Reverse DNS Updating . . . . . . . . . . 11 76 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . . . 11 77 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . . . 12 78 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . . . 12 79 7.4 DDNS With DHCP . . . . . . . . . . . . . . . . . . . . . . . . 12 80 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . . . 13 81 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 13 82 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . . . 13 83 8.2 Renumbering Procedures and Applications' Use of DNS . . . . . 13 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 85 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 86 Normative References . . . . . . . . . . . . . . . . . . . . . 14 87 Informative References . . . . . . . . . . . . . . . . . . . . 14 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 89 A. Site-local Addressing Considerations for DNS . . . . . . . . . 17 90 Intellectual Property and Copyright Statements . . . . . . . . 18 92 1. Introduction 94 This memo presents operational considerations and issues with IPv6 95 DNS; it is meant to be an extensive summary and a list of pointers 96 for more information about IPv6 DNS considerations for those with 97 experience of IPv4 DNS. 99 The first section gives a brief overview of how IPv6 addresses and 100 names are represented in the DNS, how transport protocols and 101 resource records (don't) relate, and what IPv4/IPv6 name space 102 fragmentation means and how to avoid it; all of these are described 103 at more length in other documents. 105 The second section summarizes the special IPv6 address types and how 106 they relate to DNS. The third section describes observed DNS 107 implementation misbehaviour which have a varying effect on the use of 108 IPv6 records with DNS. The fourth section lists recommendations and 109 considerations for provisioning services with DNS. The fifth section 110 in turn looks at recommendations and considerations about providing 111 IPv6 support in the resolvers. The sixth and seveth sections 112 describe considerations with forward and reverse DNS updates, 113 respectively. The eighth section introduces several miscellaneous 114 IPv6 issues relating to DNS for which no better place has been found 115 in this memo. Appendix A looks briefly at the requirements for 116 site-local addressing. 118 1.1 Representing IPv6 Addresses in DNS Records 120 In the forward zones, IPv6 addresses are represented using AAAA 121 records. In the reverse zones, IPv6 address are represented using 122 PTR records in the nibble format under the ip6.arpa. -tree. See [1] 123 for more about IPv6 DNS usage, and [2] or [4] for background 124 information. 126 In particular one should note that the use of A6 records, DNAME 127 records in the reverse tree, or Bitlabels in the reverse tree is not 128 recommended [2]. 130 1.2 Difference of DNS Transport and DNS Records 132 In DNS, the IP version used to transport the queries and responses is 133 independent of the records being queried: AAAA records can be queried 134 over IPv4, and A records over IPv6. The DNS servers must not make any 135 assumptions about what data to return for Answer and Authority 136 sections. 138 However, there is some debate whether the addresses in Additional 139 section could be selected or filtered using hints obtained from which 140 transport was being used; this has some obvious problems because in 141 many cases the transport protocol does not correlate with the 142 requests, and because a "bad" answer is in a way worse than no answer 143 at all (consider the case where the client is led to believe that a 144 name received in the additional record does not have any AAAA records 145 to begin with). 147 As stated in [1]: 149 The IP protocol version used for querying resource records is 150 independent of the protocol version of the resource records; e.g., 151 IPv4 transport can be used to query IPv6 records and vice versa. 153 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation 155 To avoid the DNS name space from fragmenting into parts where some 156 parts of DNS are only visible using IPv4 (or IPv6) transport, the 157 recommendation is to always keep at least one authoritative server 158 IPv4-enabled, and to ensure that recursive DNS servers support IPv4. 159 See DNS IPv6 transport guidelines [3] for more information. 161 2. DNS Considerations about Special IPv6 Addresses 163 There are a couple of IPv6 address types which are somewhat special; 164 these are considered here. 166 2.1 Limited-scope Addresses 168 The IPv6 addressing architecture [5] includes two kinds of local-use 169 addresses: link-local (fe80::/10) and site-local (fec0::/10). The 170 site-local addresses are being deprecated [6], and are only discussed 171 in Appendix A. 173 Link-local addresses should never be published in DNS, because they 174 have only local (to the connected link) significance [7]. 176 2.2 Privacy (RFC3041) Address 178 Privacy addresses (RFC3041 [8]) use a random number as the interface 179 identifier. Publishing DNS records relating to such addresses would 180 defeat the purpose of the mechanism and is not recommended. If 181 absolutely necessary, a mapping could be made to some 182 non-identifiable name, as described in [8]. 184 2.3 6to4 Addresses 186 6to4 [9] specifies an automatic tunneling mechanism which maps a 187 public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. 188 Providing reverse DNS delegation path for such addresses is a 189 challenge. Note that similar difficulties don't surface with the 190 other automatic tunneling mechanisms (in parcicular, providing 191 reverse DNS information for Teredo hosts whose address includes the 192 UDP port of the NAT binding does not seem reasonable). 194 If the reverse DNS population would be desirable (see Section 7.1 for 195 applicability), there are a number of ways to tackle the delegation 196 path problem [10], some more applicable than the others. 198 The main proposal [11] has been to allocate 2.0.0.2.ip6.arpa. to RIRs 199 and let them do subdelegations in accordance to the delegations of 200 the respective IPv4 address space. This has a major practical 201 drawback: those ISPs and IPv4 address space holders where 6to4 is 202 being used do not, in general, provide any IPv6 services -- as 203 otherwise, most people would not use 6to4 to begin with -- and it is 204 improbable that the reverse delegation chain would be completed 205 either. In most cases, creating such delegation chains might just 206 lead to latencies caused by lookups for (almost always) non-existant 207 DNS records. 209 3. Observed DNS Implementation Misbehaviour 211 Several classes of misbehaviour in DNS servers, load-balancers and 212 resolvers has been observed. Most of these are rather generic, not 213 only applicable to IPv6 -- but in some cases, the consequences of 214 this misbehaviour are extremely severe in IPv6 environments and 215 deserve to be mentioned. 217 3.1 Misbehaviour of DNS Servers and Load-balancers 219 There are several classes of misbehaviour in certain DNS servers and 220 load-balancers which have been noticed and documented [12]: some 221 implementations silently drop queries for unimplemented DNS records 222 types, or provide wrong answers to such queries (instead of a proper 223 negative reply). While typically these issues are not limited to 224 AAAA records, the problems are aggravated by the fact that AAAA 225 records are being queried instead of (mainly) A records. 227 The problems are serious because when looking up a DNS name, typical 228 getaddrinfo() implementations, with AF_UNSPEC hint given, first try 229 to query the AAAA records of the name, and after receiving a 230 response, query the A records. This is done in a serial fashion -- if 231 the first query is never responded (instead of properly returning a 232 negative answer), significant timeouts will occur. 234 In consequence, this is an enermous problem for IPv6 deployments, and 235 in some cases, IPv6 support in the software has even been disabled 236 due to these problems. 238 The solution is to fix or retire those misbehaving implementations, 239 but that is likely not going to be effective. There are some 240 possible ways to mitigate the problem, e.g. by performing the lookups 241 somewhat in parallel and reducing the timeout as long as at least one 242 answer has been received; but such methods remain to be investigated; 243 slightly more on this in Section 5. 245 3.2 Misbehaviour of DNS Resolvers 247 Several classes of misbehaviour have also been noticed in DNS 248 resolvers [13]. However, these do not seem to directly impair IPv6 249 use, and are only referred to for completeness. 251 4. Recommendations for Service Provisioning using DNS 253 When names are added in the DNS to facilitate a service, there are 254 several general guidelines to consider to be able to do it as 255 smoothly as possible. 257 4.1 Use of Service Names instead of Node Names 259 When a node includes multiple services, one should keep them 260 logically separate in the DNS. This can be done by the use of 261 service names instead of node names (or, "hostnames"). 263 For example, assume a node named "pobox.example.com" provides both 264 SMTP and IMAP service. Instead of configuring the MX records to 265 point at "pobox.example.com", and configuring the mail clients to 266 look up the mail via IMAP from "pobox.example.com", one should use 267 e.g. "smtp.example.com" for SMTP (for both message submission and 268 mail relaying between SMTP servers) and "imap.example.com" for IMAP. 269 Note that in the specific case of STMP relaying, the server itself 270 must typically also be configured to know all its names to ensure 271 loops do not occur. DNS can provide a layer of indirection between 272 service names and where the service actually is, and using which 273 addresses. 275 This is a good practice with IPv4 as well, because it provides more 276 flexibility and enables easier migration of services from one host to 277 another. A specific reason why this is relevant for IPv6 is that the 278 different services may have a different level of IPv6 support -- that 279 is, one node providing multiple services might want to enable just 280 one service to be IPv6-visible while keeping some others as 281 IPv4-only. Using service names enables more flexibility with 282 different IP versions as well. 284 4.2 Separate vs the Same Service Names for IPv4 and IPv6 286 The service naming can be achieved in basically two ways: when a 287 service is named "service.example.com" for IPv4, the IPv6-enabled 288 service could be either added to "service.example.com", or added 289 separately to a sub-domain, like, "service.ipv6.example.com". 291 Both methods have different characteristics. Using a sub-domain 292 allows for easier service piloting, probably not disturbing the 293 "regular" users of IPv4 service; however, the service would not be 294 used without explicitly asking for it (or, within a restricted 295 network, modifying the DNS search path) -- so it will not actually be 296 used that much. Using the same service name is the "long-term" 297 solution, but may degrade performance for those clients whose IPv6 298 performance is lower than IPv4, or does not work as well (see the 299 next subsection for more). 301 In most cases, it makes sense to pilot or test a service using 302 separate service names, and move to the use of the same name when 303 confident enough that the service level will not degrade for the 304 users unaware of IPv6. 306 4.3 Adding the Records Only when Fully IPv6-enabled 308 The recommendation is that AAAA records for a service should not be 309 added to the DNS until all of following are true: 311 1. The address is assigned to the interface on the node. 313 2. The address is configured on the interface. 315 3. The interface is on a link which is connected to the IPv6 316 infrastructure. 318 In addition, if the AAAA record is added for the node, instead of 319 service as recommended, all the services of the node should be 320 IPv6-enabled prior to adding the AAAA record. 322 For example, if an IPv6 node is isolated from an IPv6 perspective 323 (e.g., it is not connected to IPv6 Internet) constraint #3 would mean 324 that it should not have an address in the DNS. 326 Consider the case of two dual-stack nodes, which both have IPv6 327 enabled, but the server does not have (global) IPv6 connectivity. As 328 the client looks up the server's name, only A records are returned 329 (if the recommendations above are followed), and no IPv6 330 communication, which would be unsuccessful, is even attempted. 332 The issues are not always so black-and-white. Usually it's important 333 if the service offered using both protocols is of roughly equal 334 quality, using the appropriate metrics for the service (e.g., 335 latency, throughput, low packet loss, general reliability, etc.) -- 336 this is typically very important especially for interactive or 337 real-time services. In many cases, the quality of IPv6 connectivity 338 is not yet equal to that of IPv4, at least globally -- this has to be 339 taken into consideration when enabling services [14]. 341 4.4 IPv6 Transport Guidelines for DNS Servers 343 As described in Section 1.3 and [3], there should continue to be at 344 least one authorative IPv4 DNS server for every zone, even if the 345 zone has only IPv6 records. (Note that obviously, having more servers 346 with robust connectivity would be preferably, but this is the 347 recommendation.) 349 5. Recommendations for DNS Resolver IPv6 Support 351 When IPv6 is enabled on a node, there are several things to consider 352 to ensure that the process is as smooth as possible. 354 5.1 DNS Lookups May Query IPv6 Records Prematurely 356 The system library that implements the getaddrinfo() function for 357 looking up names is a critical piece when considering the robustness 358 of enabling IPv6; it may come in basically three flavours: 360 1. The system library does not know whether IPv6 has been enabled in 361 the kernel of the operating system: it may start looking up AAAA 362 records with getaddrinfo() and AF_UNSPEC hint when the system is 363 upgraded to a system library version which supports IPv6. 365 2. The system library might start to perform IPv6 queries with 366 getaddrinfo() only when IPv6 has been enabled in the kernel. 367 However, this does not guarantee that there exists any useful 368 IPv6 connectivity (e.g., the node could be isolated from the 369 other IPv6 networks, only having link-local addresses). 371 3. The system library might implement a toggle which would apply 372 some heuristics to the "IPv6-readiness" of the node before 373 starting to perform queries; for example, it could check that a 374 link-local IPv6 address exists, or a global IPv6 address exists. 376 First, let us consider generic implications of unnecessary queries 377 for AAAA records: when looking up all the records in the DNS, AAAA 378 records are typically tried first, and then A records. These are 379 done in serial, and the A query is not performed until a response is 380 received to the AAAA query. Considering the misbehaviour of DNS 381 servers and load-balancers, as described in Section 3.1, the look-up 382 delay for AAAA may incur additional unnecessary latency, and 383 introduce a component of unreliability. 385 One option here could be to do the queries partially in parallel; for 386 example, if the final response to the AAAA query is not received in 387 0.5 seconds, start performing the A query while waiting for the 388 result (immediate parallelism might be unoptimal without information 389 sharing between the look-up threads, as that would probably lead to 390 duplicate non-cached delegation chain lookups). 392 An additional concern is the address selection, which may, in some 393 circumstances, prefer AAAA records over A records, even when the node 394 does not have any IPv6 connectivity [15]. In some cases, the 395 implementation may attempt to connect or send a datagram on a 396 physical link [16], incurring very long protocol timeouts, instead of 397 quickly failing back to IPv4. 399 Now, we can consider the issues specific to each of the three 400 possibilities: 402 In the first case, the node performs a number of completely useless 403 DNS lookups as it will not be able to use the returned AAAA records 404 anyway. (The only exception is where the application desires to know 405 what's in the DNS, but not use the result for communication.) One 406 should be able to disable these unnecessary queries, for both latency 407 and reliability reasons. However, as IPv6 has not been enabled, the 408 connections to IPv6 addresses fail immediately, and if the 409 application is programmed properly, the application can fall 410 gracefully back to IPv4 [17]. 412 The second case is similar to the first, except it happens to a 413 smaller set of nodes when IPv6 has been enabled but connectivity has 414 not been provided yet; similar considerations apply, with the 415 exception that IPv6 records, when returned, will be actually tried 416 first which may typically lead to long timeouts. 418 The third case is a bit more complex: optimizing away the DNS lookups 419 with only link-locals is probably safe (but may be desirable with 420 different lookup services which getaddrinfo() may support), as the 421 link-locals are typically automatically generated when IPv6 is 422 enabled, and do not indicate any form of IPv6 connectivity. That 423 is, performing DNS lookups only when a non-link-local address has 424 been configured on any interface could be beneficial -- this would be 425 an indication that either the address has been configured either from 426 a router advertisement, DHCPv6, or manually. Each would indicate at 427 least some form of IPv6 connectivity, even though there would not be 428 guarantees of it. 430 XXXX: are there any actual recommendations in here?!? :-) 432 5.2 Recursive DNS Server Discovery 434 Recursive IPv6 DNS server discovery is a subject of active debate at 435 the moment: the main proposed mechanisms include the use of 436 well-known addresses [18], the use of Router Advertisements to convey 437 the information [19], and using DHCPv6 (or the stateless subset of it 438 [20]) for DNS server configuration. No consensus has been reached 439 yet. 441 Note that IPv6 DNS server discovery, while an important topic, is not 442 required for dual-stack nodes with dual-stack networks: IPv6 DNS 443 records can very well be queried over IPv4. 445 5.3 IPv6 Transport Guidelines for Resolvers 447 As described in Section 1.3 and [3], the recursive resolvers should 448 be IPv4-only or dual-stack to be able to reach any IPv4-only DNS 449 server. Note that this requirement is also fulfilled by an IPv6-only 450 stub resolver pointing to a dual-stack recursive DNS resolver. 452 6. Considerations about Forward DNS Updating 454 While the topic how to enable updating the forward DNS, i.e., the 455 mapping from names to the correct new addresses, is not specific to 456 IPv6, it bears thinking about especially due to adding Stateless 457 Address Autoconfiguration [21] to the mix. 459 Typically forward DNS updates are more manageable than doing them in 460 the reverse DNS, because the updater can, typically, be assumed to 461 "own" a certain DNS name -- and we can create a form of security 462 association with the DNS name and the node allowed to update it to 463 point to a new address. 465 A more complex form of DNS updates -- adding a whole new name to a 466 DNS zone, instead of updating an existing one -- is considered 467 out-of-scope (XXX: at least for now, send text/feedback!). 469 6.1 Manual or Custom DNS Updates 471 The DNS mappings can be maintained by hand, in a semi-automatic 472 fashion or by running non-standardized protocols. These are not 473 considered at more length in this memo. 475 6.2 Dynamic DNS 477 Dynamic DNS updates (DDNS) [22][23] is a standardized mechanism for 478 dynamically updating the DNS. It works equally well with stateless 479 address autoconfiguration (SLAAC), DHCPv6 or manual address 480 configuration. The only (minor) twist that with SLAAC, the DNS 481 server cannot tie the authentication of the user to the IP address, 482 and stronger mechanisms must be used. Actually, relying on IP 483 addresses for Dynamic DNS is rather insecure at best, so this is 484 probably not a significant problem (but requires that the 485 authorization keying will be explicitly configured). 487 Note that the nodes must somehow be configured with the information 488 about the servers where they will attempt to update their addresses, 489 sufficient security material for authenticating themselves to the 490 server, and the hostname they will be updating. Unless otherwise 491 configured, the first could be obtained by looking up the authorative 492 name servers for the hostname; the second must be configured 493 explicitly unless one chooses to trust the IP address -based 494 authentication (not a good idea); and lastly, the nodename is 495 typically pre-configured somehow on the node, e.g. at install time. 497 Care should be observed when updating the addresses not to use longer 498 TTLs for addresses than are preferred lifetimes for the 499 autoconfigured addresses, so that if the node is renumberedin a 500 managed fashion, the amount of stale DNS information is kept to the 501 minimum. 503 7. Considerations about Reverse DNS Updating 505 Forward DNS updating was rather straightforward; reverse DNS is 506 significantly trickier especially with certain mechanisms. However, 507 first it makes sense to look at the applicability of reverse DNS in 508 the first place. 510 7.1 Applicability of Reverse DNS 512 Today, some applications use reverse DNS to either look up some hints 513 about the topological information associated with an address (e.g. 514 resolving web server access logs), or as a weak form of a security 515 check, to get a feel whether the user's network administrator has 516 "authorized" the use of the address (on the premises that adding a 517 reverse record for an address would signal some form of 518 authorization). 520 One additional, maybe slightly more useful applicability is ensuring 521 the reverse and forward DNS contents match and correspond to a 522 configured name or domain. As a security check, it is typically 523 accompanied by other mechanisms, such as a user/password login; the 524 main purpose of the DNS check is to weed out the majority of 525 unauthorized users, and if someone managed to bypass the checks, he 526 would still need to authenticate "properly". 528 It is not clear whether it makes sense to require or recommend that 529 reverse DNS records be updated. In many cases, it would just make 530 more sense to use proper mechanisms for security (or topological 531 information lookup) in the first place. At minimum, the applications 532 which use it as a generic authorization (in the sense that a record 533 exists at all) should be modified as soon as possible to avoid such 534 lookups completely. 536 7.2 Manual or Custom DNS Updates 538 Reverse DNS can be updated using manual or custom methods, naturally. 539 These are not further described here, except for one special case. 541 One way to deploy reverse DNS would be to use wildcard records, for 542 example, by configuring one name for a subnet (/64) or a site (/48). 543 Naturally, such a name could not be verified from the forward DNS, 544 but would at least provide some form of "topological information" or 545 "weak authorization" if that is really considered to be useful. Note 546 that this is not actually updating the DNS as such, as the whole 547 point is to avoid DNS updates completely by manual configuration of a 548 generic name. 550 7.3 DDNS with Stateless Address Autoconfiguration 552 Dynamic DNS with SLAAC is a bit complicated, but manageable with a 553 rather low form of security with some implementation. 555 Every node on a link must then be allowed to insert its own reverse 556 DNS record in the reverse zone. However, in the typical case, there 557 can be no stronger form of authentication between the nodes and the 558 server than the source IP address (the user may roam to other 559 administrative domains as well, requiring updates to foreign DNS 560 servers), which might make attacks more lucrative. 562 Moreover, the reverse zones must be cleaned up by some janitorial 563 process: the node does not typically know a priori that it will be 564 disconnected, and cannot send a DNS update using the correct source 565 address to remove a record. 567 7.4 DDNS With DHCP 569 With DHCP, the reverse DNS name is typically already inserted to the 570 DNS that reflects to the name (e.g., "dhcp-67.example.com"). 572 If a more explicit control is required, similar considerations as 573 with SLAAC apply, except for the fact that typically one must update 574 a reverse DNS record instead of inserting one -- due to a denser 575 address assignment policy -- and updating a record seems like a 576 slightly more difficult thing to secure. 578 7.5 DDNS with Dynamic Prefix Delegation 580 In cases where more than one address is being used and updated, one 581 should consider where the updated server resides. That is, whether 582 the prefixes have been delegated to a node in the local site, or 583 whether they reside elsewhere, e.g., at the ISP. The reverse DNS 584 updates are typically easier to manage if they can be done within a 585 single administrative entity -- and therefore, if a reverse DNS 586 delegation has been made, it may be easier to enable reverse DNS at 587 the site, e.g. by a wildcard record, or by some DNS update mechanism. 589 8. Miscellaneous DNS Considerations 591 This section describes miscellaneous considerations about DNS which 592 seem related to IPv6, for which no better place has been found in 593 this document. 595 8.1 NAT-PT with DNS-ALG 597 NAT-PT [24] DNS-ALG is a critical component (unless something 598 replacing that functionality is specified) which mangles A records to 599 look like AAAA records to the IPv6-only nodes. Numerous problems have 600 been identified with DNS-ALG [25]. 602 8.2 Renumbering Procedures and Applications' Use of DNS 604 One of the most difficult problems of renumbering procedures [26] is 605 that an application which gets a DNS name disregards information such 606 as TTL, and uses the result obtained from DNS as long as it happens 607 to be stored in the memory of the application. For applications 608 which run for a long time, this could be days, weeks or even months; 609 some applications may be clever enough to organize the data 610 structures and functions in such a manner that look-ups get refreshed 611 now and then. This is an issue with no clear solution. 613 9. Acknowledgements 615 Some recommendations (Section 4.3, Section 5.1) about IPv6 service 616 provisioning were moved here from [27] by Erik Nordmark and Bob 617 Gilligan. Havard Eidnes provided useful feedback and improvements. 619 10. Security Considerations 621 This document reviews the operational procedures for IPv6 DNS 622 operations and does not have security considerations in itself. 624 However, it is worth nothing that in particular with Dynamic DNS 625 Updates, security models based on the source address validation are 626 very weak and cannot be recommended. On the other hand, it should be 627 noted that setting up an authorization mechanism (e.g., a shared 628 secret, or public-private keys) between a node and the DNS server has 629 to be done manually, and may require quite a bit of time and 630 expertise. 632 To re-emphasize which was already stated, reverse DNS checks provide 633 very weak security at best, and the only (questionable) 634 security-related use for them may be in conjunction with other 635 mechanisms when authenticating a user. 637 Normative References 639 [1] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS 640 Extensions to Support IP Version 6", RFC 3596, October 2003. 642 [2] Bush, R., Durand, A., Fink, B., Gudmundsson, O. and T. Hain, 643 "Representing Internet Protocol version 6 (IPv6) Addresses in 644 the Domain Name System (DNS)", RFC 3363, August 2002. 646 [3] Durand, A. and J. Ihren, "DNS IPv6 transport operational 647 guidelines", draft-ietf-dnsop-ipv6-transport-guidelines-01 (work 648 in progress), October 2003. 650 Informative References 652 [4] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August 653 2001. 655 [5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 656 Addressing Architecture", RFC 3513, April 2003. 658 [6] Huitema, C. and B. Carpenter, "Deprecating Site Local 659 Addresses", draft-ietf-ipv6-deprecate-site-local-02 (work in 660 progress), November 2003. 662 [7] Hazel, P., "IP Addresses that should never appear in the public 663 DNS", draft-ietf-dnsop-dontpublish-unreachable-03 (work in 664 progress), February 2002. 666 [8] Narten, T. and R. Draves, "Privacy Extensions for Stateless 667 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 669 [9] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 670 IPv4 Clouds", RFC 3056, February 2001. 672 [10] Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work in 673 progress), October 2002. 675 [11] Bush, R. and J. Damas, "Delegation of 2.0.0.2.ip6.arpa", 676 draft-ymbk-6to4-arpa-delegation-00 (work in progress), February 677 2003. 679 [12] Morishita, Y. and T. Jinmei, "Common Misbehavior against DNS 680 Queries for IPv6 Addresses", 681 draft-morishita-dnsop-misbehavior-against-aaaa-00 (work in 682 progress), June 2003. 684 [13] Larson, M. and P. Barber, "Observed DNS Resolution 685 Misbehavior", draft-ietf-dnsop-bad-dns-res-01 (work in 686 progress), June 2003. 688 [14] Savola, P., "Moving from 6bone to IPv6 Internet", 689 draft-savola-v6ops-6bone-mess-01 (work in progress), November 690 2002. 692 [15] Roy, S., "Dual Stack IPv6 on by Default", 693 draft-ietf-v6ops-v6onbydefault-00 (work in progress), October 694 2003. 696 [16] Roy, S., "IPv6 Neighbor Discovery On-Link Assumption Considered 697 Harmful", draft-ietf-v6ops-onlinkassumption-00 (work in 698 progress), October 2003. 700 [17] Shin, M., "Application Aspects of IPv6 Transition", 701 draft-shin-v6ops-application-transition-02 (work in progress), 702 October 2003. 704 [18] Ohta, M., "Preconfigured DNS Server Addresses", 705 draft-ohta-preconfigured-dns-00 (work in progress), July 2003. 707 [19] Jeong, J., "IPv6 DNS Discovery based on Router Advertisement", 708 draft-jeong-dnsop-ipv6-dns-discovery-00 (work in progress), 709 July 2003. 711 [20] Droms, R., "A Guide to Implementing Stateless DHCPv6 Service", 712 draft-ietf-dhc-dhcpv6-stateless-01 (work in progress), October 713 2003. 715 [21] Thomson, S. and T. Narten, "IPv6 Stateless Address 716 Autoconfiguration", RFC 2462, December 1998. 718 [22] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 719 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 720 April 1997. 722 [23] Wellington, B., "Secure Domain Name System (DNS) Dynamic 723 Update", RFC 3007, November 2000. 725 [24] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - 726 Protocol Translation (NAT-PT)", RFC 2766, February 2000. 728 [25] Durand, A., "Issues with NAT-PT DNS ALG in RFC2766", 729 draft-durand-v6ops-natpt-dns-alg-issues-00 (work in progress), 730 February 2003. 732 [26] Baker, F., "Procedures for Renumbering an IPv6 Network without 733 a Flag Day", draft-baker-ipv6-renumber-procedure-01 (work in 734 progress), October 2003. 736 [27] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 737 IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-01 (work in 738 progress), October 2003. 740 Authors' Addresses 742 Alain Durand 743 SUN Microsystems, Inc. 744 17 Network circle UMPL17-202 745 Menlo Park, CA 94025 746 USA 748 EMail: Alain.Durand@sun.com 750 Johan Ihren 751 Autonomica 752 Bellmansgatan 30 753 SE-118 47 Stockholm 754 Sweden 756 EMail: johani@autonomica.se 757 Pekka Savola 758 CSC/FUNET 760 Espoo 761 Finland 763 EMail: psavola@funet.fi 765 Appendix A. Site-local Addressing Considerations for DNS 767 As site-local addressing is being deprecated, and it is not yet clear 768 whether an addressing-based replacement (and which kind) is devised, 769 the considerations for site-local addressing are introduced here. 771 The interactions with DNS come in two flavors: forward and reverse 772 DNS. 774 To actually use site-local addresses within a site, this implies the 775 deployment of a "split-faced" or a fragmented DNS name space, for the 776 zones internal to the site, and the outsiders' view to it. The 777 procedures to achieve this are not elaborated here. The implication 778 is that site-local addresses must not be published in the public DNS. 780 To faciliate reverse DNS (if desired) with site-local addresses, the 781 stub resolvers must look for DNS information from the local DNS 782 servers, not e.g. starting from the root servers, so that the 783 site-local information may be provided locally. Note that the 784 experience private addresses in IPv4 has shown that the root servers 785 get loaded for requests for private address lookups in any case. 787 Intellectual Property Statement 789 The IETF takes no position regarding the validity or scope of any 790 intellectual property or other rights that might be claimed to 791 pertain to the implementation or use of the technology described in 792 this document or the extent to which any license under such rights 793 might or might not be available; neither does it represent that it 794 has made any effort to identify any such rights. Information on the 795 IETF's procedures with respect to rights in standards-track and 796 standards-related documentation can be found in BCP-11. Copies of 797 claims of rights made available for publication and any assurances of 798 licenses to be made available, or the result of an attempt made to 799 obtain a general license or permission for the use of such 800 proprietary rights by implementors or users of this specification can 801 be obtained from the IETF Secretariat. 803 The IETF invites any interested party to bring to its attention any 804 copyrights, patents or patent applications, or other proprietary 805 rights which may cover technology that may be required to practice 806 this standard. Please address the information to the IETF Executive 807 Director. 809 Full Copyright Statement 811 Copyright (C) The Internet Society (2003). All Rights Reserved. 813 This document and translations of it may be copied and furnished to 814 others, and derivative works that comment on or otherwise explain it 815 or assist in its implementation may be prepared, copied, published 816 and distributed, in whole or in part, without restriction of any 817 kind, provided that the above copyright notice and this paragraph are 818 included on all such copies and derivative works. However, this 819 document itself may not be modified in any way, such as by removing 820 the copyright notice or references to the Internet Society or other 821 Internet organizations, except as needed for the purpose of 822 developing Internet standards in which case the procedures for 823 copyrights defined in the Internet Standards process must be 824 followed, or as required to translate it into languages other than 825 English. 827 The limited permissions granted above are perpetual and will not be 828 revoked by the Internet Society or its successors or assignees. 830 This document and the information contained herein is provided on an 831 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 832 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 833 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 834 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 835 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 837 Acknowledgment 839 Funding for the RFC Editor function is currently provided by the 840 Internet Society.