5 DNS Operations WG A. Durand
6 Internet-Draft SUN Microsystems, Inc.
7 Expires: January 17, 2006 J. Ihren
14 Operational Considerations and Issues with IPv6 DNS
15 draft-ietf-dnsop-ipv6-dns-issues-11.txt
19 By submitting this Internet-Draft, each author represents that any
20 applicable patent or other IPR claims of which he or she is aware
21 have been or will be disclosed, and any of which he or she becomes
22 aware will be disclosed, in accordance with Section 6 of BCP 79.
24 Internet-Drafts are working documents of the Internet Engineering
25 Task Force (IETF), its areas, and its working groups. Note that
26 other groups may also distribute working documents as Internet-
29 Internet-Drafts are draft documents valid for a maximum of six months
30 and may be updated, replaced, or obsoleted by other documents at any
31 time. It is inappropriate to use Internet-Drafts as reference
32 material or to cite them other than as "work in progress."
34 The list of current Internet-Drafts can be accessed at
35 http://www.ietf.org/ietf/1id-abstracts.txt.
37 The list of Internet-Draft Shadow Directories can be accessed at
38 http://www.ietf.org/shadow.html.
40 This Internet-Draft will expire on January 17, 2006.
44 Copyright (C) The Internet Society (2005).
48 This memo presents operational considerations and issues with IPv6
49 Domain Name System (DNS), including a summary of special IPv6
50 addresses, documentation of known DNS implementation misbehaviour,
51 recommendations and considerations on how to perform DNS naming for
52 service provisioning and for DNS resolver IPv6 support,
56 Durand, et al. Expires January 17, 2006 [Page 1]
58 Internet-Draft Considerations with IPv6 DNS July 2005
61 considerations for DNS updates for both the forward and reverse
62 trees, and miscellaneous issues. This memo is aimed to include a
63 summary of information about IPv6 DNS considerations for those who
64 have experience with IPv4 DNS.
68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
69 1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . 4
70 1.2 Independence of DNS Transport and DNS Records . . . . . . 4
71 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . 5
72 1.4 Query Type '*' and A/AAAA Records . . . . . . . . . . . . 5
73 2. DNS Considerations about Special IPv6 Addresses . . . . . . . 5
74 2.1 Limited-scope Addresses . . . . . . . . . . . . . . . . . 6
75 2.2 Temporary Addresses . . . . . . . . . . . . . . . . . . . 6
76 2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 6
77 2.4 Other Transition Mechanisms . . . . . . . . . . . . . . . 6
78 3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 7
79 3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . 7
80 3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 7
81 4. Recommendations for Service Provisioning using DNS . . . . . . 7
82 4.1 Use of Service Names instead of Node Names . . . . . . . . 8
83 4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . 8
84 4.3 Adding the Records Only when Fully IPv6-enabled . . . . . 9
85 4.4 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 10
86 4.4.1 TTL With Courtesy Additional Data . . . . . . . . . . 10
87 4.4.2 TTL With Critical Additional Data . . . . . . . . . . 10
88 4.5 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 11
89 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 11
90 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 11
91 5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 13
92 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 13
93 6. Considerations about Forward DNS Updating . . . . . . . . . . 13
94 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 14
95 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 14
96 7. Considerations about Reverse DNS Updating . . . . . . . . . . 15
97 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 15
98 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16
99 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 16
100 7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 18
101 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 18
102 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 19
103 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 19
104 8.2 Renumbering Procedures and Applications' Use of DNS . . . 19
105 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
106 10. Security Considerations . . . . . . . . . . . . . . . . . . 20
107 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
108 11.1 Normative References . . . . . . . . . . . . . . . . . . . 20
112 Durand, et al. Expires January 17, 2006 [Page 2]
114 Internet-Draft Considerations with IPv6 DNS July 2005
117 11.2 Informative References . . . . . . . . . . . . . . . . . . 22
118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
119 A. Unique Local Addressing Considerations for DNS . . . . . . . . 25
120 B. Behaviour of Additional Data in IPv4/IPv6 Environments . . . . 25
121 B.1 Description of Additional Data Scenarios . . . . . . . . . 26
122 B.2 Which Additional Data to Keep, If Any? . . . . . . . . . . 27
123 B.3 Discussion of the Potential Problems . . . . . . . . . . . 28
124 Intellectual Property and Copyright Statements . . . . . . . . 30
168 Durand, et al. Expires January 17, 2006 [Page 3]
170 Internet-Draft Considerations with IPv6 DNS July 2005
175 This memo presents operational considerations and issues with IPv6
176 DNS; it is meant to be an extensive summary and a list of pointers
177 for more information about IPv6 DNS considerations for those with
178 experience with IPv4 DNS.
180 The purpose of this document is to give information about various
181 issues and considerations related to DNS operations with IPv6; it is
182 not meant to be a normative specification or standard for IPv6 DNS.
184 The first section gives a brief overview of how IPv6 addresses and
185 names are represented in the DNS, how transport protocols and
186 resource records (don't) relate, and what IPv4/IPv6 name space
187 fragmentation means and how to avoid it; all of these are described
188 at more length in other documents.
190 The second section summarizes the special IPv6 address types and how
191 they relate to DNS. The third section describes observed DNS
192 implementation misbehaviours which have a varying effect on the use
193 of IPv6 records with DNS. The fourth section lists recommendations
194 and considerations for provisioning services with DNS. The fifth
195 section in turn looks at recommendations and considerations about
196 providing IPv6 support in the resolvers. The sixth and seventh
197 sections describe considerations with forward and reverse DNS
198 updates, respectively. The eighth section introduces several
199 miscellaneous IPv6 issues relating to DNS for which no better place
200 has been found in this memo. Appendix A looks briefly at the
201 requirements for unique local addressing.
203 1.1 Representing IPv6 Addresses in DNS Records
205 In the forward zones, IPv6 addresses are represented using AAAA
206 records. In the reverse zones, IPv6 address are represented using
207 PTR records in the nibble format under the ip6.arpa. tree. See
208 [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152]
209 for background information.
211 In particular one should note that the use of A6 records in the
212 forward tree or Bitlabels in the reverse tree is not recommended
213 [RFC3363]. Using DNAME records is not recommended in the reverse
214 tree in conjunction with A6 records; the document did not mean to
215 take a stance on any other use of DNAME records [RFC3364].
217 1.2 Independence of DNS Transport and DNS Records
219 DNS has been designed to present a single, globally unique name space
220 [RFC2826]. This property should be maintained, as described here and
224 Durand, et al. Expires January 17, 2006 [Page 4]
226 Internet-Draft Considerations with IPv6 DNS July 2005
231 The IP version used to transport the DNS queries and responses is
232 independent of the records being queried: AAAA records can be queried
233 over IPv4, and A records over IPv6. The DNS servers must not make
234 any assumptions about what data to return for Answer and Authority
235 sections based on the underlying transport used in a query.
237 However, there is some debate whether the addresses in Additional
238 section could be selected or filtered using hints obtained from which
239 transport was being used; this has some obvious problems because in
240 many cases the transport protocol does not correlate with the
241 requests, and because a "bad" answer is in a way worse than no answer
242 at all (consider the case where the client is led to believe that a
243 name received in the additional record does not have any AAAA records
246 As stated in [RFC3596]:
248 The IP protocol version used for querying resource records is
249 independent of the protocol version of the resource records; e.g.,
250 IPv4 transport can be used to query IPv6 records and vice versa.
253 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation
255 To avoid the DNS name space from fragmenting into parts where some
256 parts of DNS are only visible using IPv4 (or IPv6) transport, the
257 recommendation is to always keep at least one authoritative server
258 IPv4-enabled, and to ensure that recursive DNS servers support IPv4.
259 See DNS IPv6 transport guidelines [RFC3901] for more information.
261 1.4 Query Type '*' and A/AAAA Records
263 QTYPE=* is typically only used for debugging or management purposes;
264 it is worth keeping in mind that QTYPE=* ("ANY" queries) only return
265 any available RRsets, not *all* the RRsets, because the caches do not
266 necessarily have all the RRsets and have no way of guaranteeing that
267 they have all the RRsets. Therefore, to get both A and AAAA records
268 reliably, two separate queries must be made.
270 2. DNS Considerations about Special IPv6 Addresses
272 There are a couple of IPv6 address types which are somewhat special;
273 these are considered here.
280 Durand, et al. Expires January 17, 2006 [Page 5]
282 Internet-Draft Considerations with IPv6 DNS July 2005
285 2.1 Limited-scope Addresses
287 The IPv6 addressing architecture [RFC3513] includes two kinds of
288 local-use addresses: link-local (fe80::/10) and site-local
289 (fec0::/10). The site-local addresses have been deprecated [RFC3879]
290 but are discussed with unique local addresses in Appendix A.
292 Link-local addresses should never be published in DNS (whether in
293 forward or reverse tree), because they have only local (to the
294 connected link) significance [I-D.durand-dnsop-dont-publish].
296 2.2 Temporary Addresses
298 Temporary addresses defined in RFC3041 [RFC3041] (sometimes called
299 "privacy addresses") use a random number as the interface identifier.
300 Having DNS AAAA records that are updated to always contain the
301 current value of a node's temporary address would defeat the purpose
302 of the mechanism and is not recommended. However, it would still be
303 possible to return a non-identifiable name (e.g., the IPv6 address in
304 hexadecimal format), as described in [RFC3041].
308 6to4 [RFC3056] specifies an automatic tunneling mechanism which maps
309 a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48.
311 If the reverse DNS population would be desirable (see Section 7.1 for
312 applicability), there are a number of possible ways to do so.
314 The main proposal [I-D.huston-6to4-reverse-dns] aims to design an
315 autonomous reverse-delegation system that anyone being capable of
316 communicating using a specific 6to4 address would be able to set up a
317 reverse delegation to the corresponding 6to4 prefix. This could be
318 deployed by e.g., Regional Internet Registries (RIRs). This is a
319 practical solution, but may have some scalability concerns.
321 2.4 Other Transition Mechanisms
323 6to4 is mentioned as a case of an IPv6 transition mechanism requiring
324 special considerations. In general, mechanisms which include a
325 special prefix may need a custom solution; otherwise, for example
326 when IPv4 address is embedded as the suffix or not embedded at all,
327 special solutions are likely not needed.
329 Note that it does not seem feasible to provide reverse DNS with
330 another automatic tunneling mechanism, Teredo [I-D.huitema-v6ops-
331 teredo]; this is because the IPv6 address is based on the IPv4
332 address and UDP port of the current NAT mapping which is likely to be
336 Durand, et al. Expires January 17, 2006 [Page 6]
338 Internet-Draft Considerations with IPv6 DNS July 2005
341 relatively short-lived.
343 3. Observed DNS Implementation Misbehaviour
345 Several classes of misbehaviour in DNS servers, load-balancers and
346 resolvers have been observed. Most of these are rather generic, not
347 only applicable to IPv6 -- but in some cases, the consequences of
348 this misbehaviour are extremely severe in IPv6 environments and
349 deserve to be mentioned.
351 3.1 Misbehaviour of DNS Servers and Load-balancers
353 There are several classes of misbehaviour in certain DNS servers and
354 load-balancers which have been noticed and documented [RFC4074]: some
355 implementations silently drop queries for unimplemented DNS records
356 types, or provide wrong answers to such queries (instead of a proper
357 negative reply). While typically these issues are not limited to
358 AAAA records, the problems are aggravated by the fact that AAAA
359 records are being queried instead of (mainly) A records.
361 The problems are serious because when looking up a DNS name, typical
362 getaddrinfo() implementations, with AF_UNSPEC hint given, first try
363 to query the AAAA records of the name, and after receiving a
364 response, query the A records. This is done in a serial fashion --
365 if the first query is never responded to (instead of properly
366 returning a negative answer), significant timeouts will occur.
368 In consequence, this is an enormous problem for IPv6 deployments, and
369 in some cases, IPv6 support in the software has even been disabled
370 due to these problems.
372 The solution is to fix or retire those misbehaving implementations,
373 but that is likely not going to be effective. There are some
374 possible ways to mitigate the problem, e.g., by performing the
375 lookups somewhat in parallel and reducing the timeout as long as at
376 least one answer has been received; but such methods remain to be
377 investigated; slightly more on this is included in Section 5.
379 3.2 Misbehaviour of DNS Resolvers
381 Several classes of misbehaviour have also been noticed in DNS
382 resolvers [I-D.ietf-dnsop-bad-dns-res]. However, these do not seem
383 to directly impair IPv6 use, and are only referred to for
386 4. Recommendations for Service Provisioning using DNS
388 When names are added in the DNS to facilitate a service, there are
392 Durand, et al. Expires January 17, 2006 [Page 7]
394 Internet-Draft Considerations with IPv6 DNS July 2005
397 several general guidelines to consider to be able to do it as
398 smoothly as possible.
400 4.1 Use of Service Names instead of Node Names
402 It makes sense to keep information about separate services logically
403 separate in the DNS by using a different DNS hostname for each
404 service. There are several reasons for doing this, for example:
406 o It allows more flexibility and ease for migration of (only a part
407 of) services from one node to another,
409 o It allows configuring different properties (e.g., TTL) for each
412 o It allows deciding separately for each service whether to publish
413 the IPv6 addresses or not (in cases where some services are more
414 IPv6-ready than others).
416 Using SRV records [RFC2782] would avoid these problems.
417 Unfortunately, those are not sufficiently widely used to be
418 applicable in most cases. Hence an operation technique is to use
419 service names instead of node names (or, "hostnames"). This
420 operational technique is not specific to IPv6, but required to
421 understand the considerations described in Section 4.2 and
424 For example, assume a node named "pobox.example.com" provides both
425 SMTP and IMAP service. Instead of configuring the MX records to
426 point at "pobox.example.com", and configuring the mail clients to
427 look up the mail via IMAP from "pobox.example.com", one could use
428 e.g., "smtp.example.com" for SMTP (for both message submission and
429 mail relaying between SMTP servers) and "imap.example.com" for IMAP.
430 Note that in the specific case of SMTP relaying, the server itself
431 must typically also be configured to know all its names to ensure
432 loops do not occur. DNS can provide a layer of indirection between
433 service names and where the service actually is, and using which
434 addresses. (Obviously, when wanting to reach a specific node, one
435 should use the hostname rather than a service name.)
437 4.2 Separate vs the Same Service Names for IPv4 and IPv6
439 The service naming can be achieved in basically two ways: when a
440 service is named "service.example.com" for IPv4, the IPv6-enabled
441 service could either be added to "service.example.com", or added
442 separately under a different name, e.g., in a sub-domain, like,
443 "service.ipv6.example.com".
448 Durand, et al. Expires January 17, 2006 [Page 8]
450 Internet-Draft Considerations with IPv6 DNS July 2005
453 These two methods have different characteristics. Using a different
454 name allows for easier service piloting, minimizing the disturbance
455 to the "regular" users of IPv4 service; however, the service would
456 not be used transparently, without the user/application explicitly
457 finding it and asking for it -- which would be a disadvantage in most
458 cases. When the different name is under a sub-domain, if the
459 services are deployed within a restricted network (e.g., inside an
460 enterprise), it's possible to prefer them transparently, at least to
461 a degree, by modifying the DNS search path; however, this is a
462 suboptimal solution. Using the same service name is the "long-term"
463 solution, but may degrade performance for those clients whose IPv6
464 performance is lower than IPv4, or does not work as well (see
465 Section 4.3 for more).
467 In most cases, it makes sense to pilot or test a service using
468 separate service names, and move to the use of the same name when
469 confident enough that the service level will not degrade for the
470 users unaware of IPv6.
472 4.3 Adding the Records Only when Fully IPv6-enabled
474 The recommendation is that AAAA records for a service should not be
475 added to the DNS until all of following are true:
477 1. The address is assigned to the interface on the node.
479 2. The address is configured on the interface.
481 3. The interface is on a link which is connected to the IPv6
484 In addition, if the AAAA record is added for the node, instead of
485 service as recommended, all the services of the node should be IPv6-
486 enabled prior to adding the resource record.
488 For example, if an IPv6 node is isolated from an IPv6 perspective
489 (e.g., it is not connected to IPv6 Internet) constraint #3 would mean
490 that it should not have an address in the DNS.
492 Consider the case of two dual-stack nodes, which both have IPv6
493 enabled, but the server does not have (global) IPv6 connectivity. As
494 the client looks up the server's name, only A records are returned
495 (if the recommendations above are followed), and no IPv6
496 communication, which would have been unsuccessful, is even attempted.
498 The issues are not always so black-and-white. Usually it's important
499 that the service offered using both protocols is of roughly equal
500 quality, using the appropriate metrics for the service (e.g.,
504 Durand, et al. Expires January 17, 2006 [Page 9]
506 Internet-Draft Considerations with IPv6 DNS July 2005
509 latency, throughput, low packet loss, general reliability, etc.) --
510 this is typically very important especially for interactive or real-
511 time services. In many cases, the quality of IPv6 connectivity may
512 not yet be equal to that of IPv4, at least globally -- this has to be
513 taken into consideration when enabling services.
515 4.4 The Use of TTL for IPv4 and IPv6 RRs
517 The behaviour of DNS caching when different TTL values are used for
518 different RRsets of the same name calls for explicit discussion. For
519 example, let's consider two unrelated zone fragments:
521 example.com. 300 IN MX foo.example.com.
522 foo.example.com. 300 IN A 192.0.2.1
523 foo.example.com. 100 IN AAAA 2001:db8::1
527 child.example.com. 300 IN NS ns.child.example.com.
528 ns.child.example.com. 300 IN A 192.0.2.1
529 ns.child.example.com. 100 IN AAAA 2001:db8::1
531 In the former case, we have "courtesy" additional data; in the
532 latter, we have "critical" additional data. See more extensive
533 background discussion of additional data handling in Appendix B.
535 4.4.1 TTL With Courtesy Additional Data
537 When a caching resolver asks for the MX record of example.com, it
538 gets back "foo.example.com". It may also get back either one or both
539 of the A and AAAA records in the additional section. The resolver
540 must explicitly query for both A and AAAA records [RFC2821].
542 After 100 seconds, the AAAA record is removed from the cache(s)
543 because its TTL expired. It could be argued to be useful for the
544 caching resolvers to discard the A record when the shorter TTL (in
545 this case, for the AAAA record) expires; this would avoid the
546 situation where there would be a window of 200 seconds when
547 incomplete information is returned from the cache. Further argument
548 for discarding is that in the normal operation, the TTL values are so
549 high that very likely the incurred additional queries would not be
550 noticeable, compared to the obtained performance optimization. The
551 behaviour in this scenario is unspecified.
553 4.4.2 TTL With Critical Additional Data
555 The difference to courtesy additional data is that the A/AAAA records
556 served by the parent zone cannot be queried explicitly. Therefore
560 Durand, et al. Expires January 17, 2006 [Page 10]
562 Internet-Draft Considerations with IPv6 DNS July 2005
565 after 100 seconds the AAAA record is removed from the cache(s), but
566 the A record remains. Queries for the remaining 200 seconds
567 (provided that there are no further queries from the parent which
568 could refresh the caches) only return the A record, leading to a
569 potential opererational situation with unreachable servers.
571 Similar cache flushing strategies apply in this scenario; the record.
573 4.5 IPv6 Transport Guidelines for DNS Servers
575 As described in Section 1.3 and [RFC3901], there should continue to
576 be at least one authoritative IPv4 DNS server for every zone, even if
577 the zone has only IPv6 records. (Note that obviously, having more
578 servers with robust connectivity would be preferable, but this is the
579 minimum recommendation; also see [RFC2182].)
581 5. Recommendations for DNS Resolver IPv6 Support
583 When IPv6 is enabled on a node, there are several things to consider
584 to ensure that the process is as smooth as possible.
586 5.1 DNS Lookups May Query IPv6 Records Prematurely
588 The system library that implements the getaddrinfo() function for
589 looking up names is a critical piece when considering the robustness
590 of enabling IPv6; it may come in basically three flavours:
592 1. The system library does not know whether IPv6 has been enabled in
593 the kernel of the operating system: it may start looking up AAAA
594 records with getaddrinfo() and AF_UNSPEC hint when the system is
595 upgraded to a system library version which supports IPv6.
597 2. The system library might start to perform IPv6 queries with
598 getaddrinfo() only when IPv6 has been enabled in the kernel.
599 However, this does not guarantee that there exists any useful
600 IPv6 connectivity (e.g., the node could be isolated from the
601 other IPv6 networks, only having link-local addresses).
603 3. The system library might implement a toggle which would apply
604 some heuristics to the "IPv6-readiness" of the node before
605 starting to perform queries; for example, it could check whether
606 only link-local IPv6 address(es) exists, or if at least one
607 global IPv6 address exists.
609 First, let us consider generic implications of unnecessary queries
610 for AAAA records: when looking up all the records in the DNS, AAAA
611 records are typically tried first, and then A records. These are
612 done in serial, and the A query is not performed until a response is
616 Durand, et al. Expires January 17, 2006 [Page 11]
618 Internet-Draft Considerations with IPv6 DNS July 2005
621 received to the AAAA query. Considering the misbehaviour of DNS
622 servers and load-balancers, as described in Section 3.1, the look-up
623 delay for AAAA may incur additional unnecessary latency, and
624 introduce a component of unreliability.
626 One option here could be to do the queries partially in parallel; for
627 example, if the final response to the AAAA query is not received in
628 0.5 seconds, start performing the A query while waiting for the
629 result (immediate parallelism might be unoptimal, at least without
630 information sharing between the look-up threads, as that would
631 probably lead to duplicate non-cached delegation chain lookups).
633 An additional concern is the address selection, which may, in some
634 circumstances, prefer AAAA records over A records even when the node
635 does not have any IPv6 connectivity [I-D.ietf-v6ops-v6onbydefault].
636 In some cases, the implementation may attempt to connect or send a
637 datagram on a physical link [I-D.ietf-v6ops-onlinkassumption],
638 incurring very long protocol timeouts, instead of quickly failing
641 Now, we can consider the issues specific to each of the three
644 In the first case, the node performs a number of completely useless
645 DNS lookups as it will not be able to use the returned AAAA records
646 anyway. (The only exception is where the application desires to know
647 what's in the DNS, but not use the result for communication.) One
648 should be able to disable these unnecessary queries, for both latency
649 and reliability reasons. However, as IPv6 has not been enabled, the
650 connections to IPv6 addresses fail immediately, and if the
651 application is programmed properly, the application can fall
652 gracefully back to IPv4 [RFC4038].
654 The second case is similar to the first, except it happens to a
655 smaller set of nodes when IPv6 has been enabled but connectivity has
656 not been provided yet; similar considerations apply, with the
657 exception that IPv6 records, when returned, will be actually tried
658 first which may typically lead to long timeouts.
660 The third case is a bit more complex: optimizing away the DNS lookups
661 with only link-locals is probably safe (but may be desirable with
662 different lookup services which getaddrinfo() may support), as the
663 link-locals are typically automatically generated when IPv6 is
664 enabled, and do not indicate any form of IPv6 connectivity. That is,
665 performing DNS lookups only when a non-link-local address has been
666 configured on any interface could be beneficial -- this would be an
667 indication that either the address has been configured either from a
668 router advertisement, DHCPv6 [RFC3315], or manually. Each would
672 Durand, et al. Expires January 17, 2006 [Page 12]
674 Internet-Draft Considerations with IPv6 DNS July 2005
677 indicate at least some form of IPv6 connectivity, even though there
678 would not be guarantees of it.
680 These issues should be analyzed at more depth, and the fixes found
681 consensus on, perhaps in a separate document.
683 5.2 Obtaining a List of DNS Recursive Resolvers
685 In scenarios where DHCPv6 is available, a host can discover a list of
686 DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server"
687 option [RFC3646]. This option can be passed to a host through a
688 subset of DHCPv6 [RFC3736].
690 The IETF is considering the development of alternative mechanisms for
691 obtaining the list of DNS recursive name servers when DHCPv6 is
692 unavailable or inappropriate. No decision about taking on this
693 development work has been reached as of this writing (Aug 2004)
694 [I-D.ietf-dnsop-ipv6-dns-configuration].
696 In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms
697 under consideration for development include the use of well-known
698 addresses [I-D.ohta-preconfigured-dns] and the use of Router
699 Advertisements to convey the information [I-D.jeong-dnsop-ipv6-dns-
702 Note that even though IPv6 DNS resolver discovery is a recommended
703 procedure, it is not required for dual-stack nodes in dual-stack
704 networks as IPv6 DNS records can be queried over IPv4 as well as
705 IPv6. Obviously, nodes which are meant to function without manual
706 configuration in IPv6-only networks must implement the DNS resolver
709 5.3 IPv6 Transport Guidelines for Resolvers
711 As described in Section 1.3 and [RFC3901], the recursive resolvers
712 should be IPv4-only or dual-stack to be able to reach any IPv4-only
713 DNS server. Note that this requirement is also fulfilled by an IPv6-
714 only stub resolver pointing to a dual-stack recursive DNS resolver.
716 6. Considerations about Forward DNS Updating
718 While the topic of how to enable updating the forward DNS, i.e., the
719 mapping from names to the correct new addresses, is not specific to
720 IPv6, it should be considered especially due to the advent of
721 Stateless Address Autoconfiguration [RFC2462].
723 Typically forward DNS updates are more manageable than doing them in
724 the reverse DNS, because the updater can often be assumed to "own" a
728 Durand, et al. Expires January 17, 2006 [Page 13]
730 Internet-Draft Considerations with IPv6 DNS July 2005
733 certain DNS name -- and we can create a form of security relationship
734 with the DNS name and the node which is allowed to update it to point
737 A more complex form of DNS updates -- adding a whole new name into a
738 DNS zone, instead of updating an existing name -- is considered out
739 of scope for this memo as it could require zone-wide authentication.
740 Adding a new name in the forward zone is a problem which is still
741 being explored with IPv4, and IPv6 does not seem to add much new in
744 6.1 Manual or Custom DNS Updates
746 The DNS mappings can also be maintained by hand, in a semi-automatic
747 fashion or by running non-standardized protocols. These are not
748 considered at more length in this memo.
752 Dynamic DNS updates (DDNS) [RFC2136] [RFC3007] is a standardized
753 mechanism for dynamically updating the DNS. It works equally well
754 with stateless address autoconfiguration (SLAAC), DHCPv6 or manual
755 address configuration. It is important to consider how each of these
756 behave if IP address-based authentication, instead of stronger
757 mechanisms [RFC3007], was used in the updates.
759 1. manual addresses are static and can be configured
761 2. DHCPv6 addresses could be reasonably static or dynamic, depending
762 on the deployment, and could or could not be configured on the
763 DNS server for the long term
765 3. SLAAC addresses are typically stable for a long time, but could
766 require work to be configured and maintained.
768 As relying on IP addresses for Dynamic DNS is rather insecure at
769 best, stronger authentication should always be used; however, this
770 requires that the authorization keying will be explicitly configured
771 using unspecified operational methods.
773 Note that with DHCP it is also possible that the DHCP server updates
774 the DNS, not the host. The host might only indicate in the DHCP
775 exchange which hostname it would prefer, and the DHCP server would
776 make the appropriate updates. Nonetheless, while this makes setting
777 up a secure channel between the updater and the DNS server easier, it
778 does not help much with "content" security, i.e., whether the
779 hostname was acceptable -- if the DNS server does not include
780 policies, they must be included in the DHCP server (e.g., a regular
784 Durand, et al. Expires January 17, 2006 [Page 14]
786 Internet-Draft Considerations with IPv6 DNS July 2005
789 host should not be able to state that its name is "www.example.com").
790 DHCP-initiated DDNS updates have been extensively described in
791 [I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and
792 [I-D.ietf-dnsext-dhcid-rr].
794 The nodes must somehow be configured with the information about the
795 servers where they will attempt to update their addresses, sufficient
796 security material for authenticating themselves to the server, and
797 the hostname they will be updating. Unless otherwise configured, the
798 first could be obtained by looking up the authoritative name servers
799 for the hostname; the second must be configured explicitly unless one
800 chooses to trust the IP address-based authentication (not a good
801 idea); and lastly, the nodename is typically pre-configured somehow
802 on the node, e.g., at install time.
804 Care should be observed when updating the addresses not to use longer
805 TTLs for addresses than are preferred lifetimes for the addresses, so
806 that if the node is renumbered in a managed fashion, the amount of
807 stale DNS information is kept to the minimum. That is, if the
808 preferred lifetime of an address expires, the TTL of the record needs
809 be modified unless it was already done before the expiration. For
810 better flexibility, the DNS TTL should be much shorter (e.g., a half
811 or a third) than the lifetime of an address; that way, the node can
812 start lowering the DNS TTL if it seems like the address has not been
813 renewed/refreshed in a while. Some discussion on how an
814 administrator could manage the DNS TTL is included in [I-D.ietf-
815 v6ops-renumbering-procedure]; this could be applied to (smart) hosts
818 7. Considerations about Reverse DNS Updating
820 Updating the reverse DNS zone may be difficult because of the split
821 authority over an address. However, first we have to consider the
822 applicability of reverse DNS in the first place.
824 7.1 Applicability of Reverse DNS
826 Today, some applications use reverse DNS to either look up some hints
827 about the topological information associated with an address (e.g.
828 resolving web server access logs), or as a weak form of a security
829 check, to get a feel whether the user's network administrator has
830 "authorized" the use of the address (on the premises that adding a
831 reverse record for an address would signal some form of
834 One additional, maybe slightly more useful usage is ensuring that the
835 reverse and forward DNS contents match (by looking up the pointer to
836 the name by the IP address from the reverse tree, and ensuring that a
840 Durand, et al. Expires January 17, 2006 [Page 15]
842 Internet-Draft Considerations with IPv6 DNS July 2005
845 record under the name in the forward tree points to the IP address)
846 and correspond to a configured name or domain. As a security check,
847 it is typically accompanied by other mechanisms, such as a user/
848 password login; the main purpose of the reverse+forward DNS check is
849 to weed out the majority of unauthorized users, and if someone
850 managed to bypass the checks, he would still need to authenticate
853 It may also be desirable to store IPsec keying material corresponding
854 to an IP address in the reverse DNS, as justified and described in
857 It is not clear whether it makes sense to require or recommend that
858 reverse DNS records be updated. In many cases, it would just make
859 more sense to use proper mechanisms for security (or topological
860 information lookup) in the first place. At minimum, the applications
861 which use it as a generic authorization (in the sense that a record
862 exists at all) should be modified as soon as possible to avoid such
865 The applicability is discussed at more length in [I-D.ietf-dnsop-
868 7.2 Manual or Custom DNS Updates
870 Reverse DNS can of course be updated using manual or custom methods.
871 These are not further described here, except for one special case.
873 One way to deploy reverse DNS would be to use wildcard records, for
874 example, by configuring one name for a subnet (/64) or a site (/48).
875 As a concrete example, a site (or the site's ISP) could configure the
876 reverses of the prefix 2001:db8:f00::/48 to point to one name using a
877 wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR
878 site.example.com." Naturally, such a name could not be verified from
879 the forward DNS, but would at least provide some form of "topological
880 information" or "weak authorization" if that is really considered to
881 be useful. Note that this is not actually updating the DNS as such,
882 as the whole point is to avoid DNS updates completely by manually
883 configuring a generic name.
885 7.3 DDNS with Stateless Address Autoconfiguration
887 Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in
888 some regard, while being more difficult in another, as described
891 The address space administrator decides whether the hosts are trusted
892 to update their reverse DNS records or not. If they are trusted and
896 Durand, et al. Expires January 17, 2006 [Page 16]
898 Internet-Draft Considerations with IPv6 DNS July 2005
901 deployed at the same site (e.g., not across the Internet), a simple
902 address-based authorization is typically sufficient (i.e., check that
903 the DNS update is done from the same IP address as the record being
904 updated); stronger security can also be used [RFC3007]. If they
905 aren't allowed to update the reverses, no update can occur. However,
906 such address-based update authorization operationally requires that
907 ingress filtering [RFC3704] has been set up at the border of the site
908 where the updates occur, and as close to the updater as possible.
910 Address-based authorization is simpler with reverse DNS (as there is
911 a connection between the record and the address) than with forward
912 DNS. However, when a stronger form of security is used, forward DNS
913 updates are simpler to manage because the host can be assumed to have
914 an association with the domain. Note that the user may roam to
915 different networks, and does not necessarily have any association
916 with the owner of that address space -- so, assuming stronger form of
917 authorization for reverse DNS updates than an address association is
918 generally infeasible.
920 Moreover, the reverse zones must be cleaned up by an unspecified
921 janitorial process: the node does not typically know a priori that it
922 will be disconnected, and cannot send a DNS update using the correct
923 source address to remove a record.
925 A problem with defining the clean-up process is that it is difficult
926 to ensure that a specific IP address and the corresponding record are
927 no longer being used. Considering the huge address space, and the
928 unlikelihood of collision within 64 bits of the interface
929 identifiers, a process which would remove the record after no traffic
930 has been seen from a node in a long period of time (e.g., a month or
931 year) might be one possible approach.
933 To insert or update the record, the node must discover the DNS server
934 to send the update to somehow, similar to as discussed in
935 Section 6.2. One way to automate this is looking up the DNS server
936 authoritative (e.g., through SOA record) for the IP address being
937 updated, but the security material (unless the IP address-based
938 authorization is trusted) must also be established by some other
941 One should note that Cryptographically Generated Addresses [RFC3972]
942 (CGAs) may require a slightly different kind of treatment. CGAs are
943 addresses where the interface identifier is calculated from a public
944 key, a modifier (used as a nonce), the subnet prefix, and other data.
945 Depending on the usage profile, CGAs might or might not be changed
946 periodically due to e.g., privacy reasons. As the CGA address is not
947 predicatable, a reverse record can only reasonably be inserted in the
948 DNS by the node which generates the address.
952 Durand, et al. Expires January 17, 2006 [Page 17]
954 Internet-Draft Considerations with IPv6 DNS July 2005
959 With DHCPv4, the reverse DNS name is typically already inserted to
960 the DNS that reflects to the name (e.g., "dhcp-67.example.com"). One
961 can assume similar practice may become commonplace with DHCPv6 as
962 well; all such mappings would be pre-configured, and would require no
965 If a more explicit control is required, similar considerations as
966 with SLAAC apply, except for the fact that typically one must update
967 a reverse DNS record instead of inserting one (if an address
968 assignment policy that reassigns disused addresses is adopted) and
969 updating a record seems like a slightly more difficult thing to
970 secure. However, it is yet uncertain how DHCPv6 is going to be used
971 for address assignment.
973 Note that when using DHCP, either the host or the DHCP server could
974 perform the DNS updates; see the implications in Section 6.2.
976 If disused addresses were to be reassigned, host-based DDNS reverse
977 updates would need policy considerations for DNS record modification,
978 as noted above. On the other hand, if disused address were not to be
979 assigned, host-based DNS reverse updates would have similar
980 considerations as SLAAC in Section 7.3. Server-based updates have
981 similar properties except that the janitorial process could be
982 integrated with DHCP address assignment.
984 7.5 DDNS with Dynamic Prefix Delegation
986 In cases where a prefix, instead of an address, is being used and
987 updated, one should consider what is the location of the server where
988 DDNS updates are made. That is, where the DNS server is located:
990 1. At the same organization as the prefix delegator.
992 2. At the site where the prefixes are delegated to. In this case,
993 the authority of the DNS reverse zone corresponding to the
994 delegated prefix is also delegated to the site.
996 3. Elsewhere; this implies a relationship between the site and where
997 DNS server is located, and such a relationship should be rather
998 straightforward to secure as well. Like in the previous case,
999 the authority of the DNS reverse zone is also delegated.
1001 In the first case, managing the reverse DNS (delegation) is simpler
1002 as the DNS server and the prefix delegator are in the same
1003 administrative domain (as there is no need to delegate anything at
1004 all); alternatively, the prefix delegator might forgo DDNS reverse
1008 Durand, et al. Expires January 17, 2006 [Page 18]
1010 Internet-Draft Considerations with IPv6 DNS July 2005
1013 capability altogether, and use e.g., wildcard records (as described
1014 in Section 7.2). In the other cases, it can be slighly more
1015 difficult, particularly as the site will have to configure the DNS
1016 server to be authoritative for the delegated reverse zone, implying
1017 automatic configuration of the DNS server -- as the prefix may be
1020 Managing the DDNS reverse updates is typically simple in the second
1021 case, as the updated server is located at the local site, and
1022 arguably IP address-based authentication could be sufficient (or if
1023 not, setting up security relationships would be simpler). As there
1024 is an explicit (security) relationship between the parties in the
1025 third case, setting up the security relationships to allow reverse
1026 DDNS updates should be rather straightforward as well (but IP
1027 address-based authentication might not be acceptable). In the first
1028 case, however, setting up and managing such relationships might be a
1031 8. Miscellaneous DNS Considerations
1033 This section describes miscellaneous considerations about DNS which
1034 seem related to IPv6, for which no better place has been found in
1037 8.1 NAT-PT with DNS-ALG
1039 The DNS-ALG component of NAT-PT mangles A records to look like AAAA
1040 records to the IPv6-only nodes. Numerous problems have been
1041 identified with DNS-ALG [I-D.ietf-v6ops-natpt-to-exprmntl]. This is
1042 a strong reason not to use NAT-PT in the first place.
1044 8.2 Renumbering Procedures and Applications' Use of DNS
1046 One of the most difficult problems of systematic IP address
1047 renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that
1048 an application which looks up a DNS name disregards information such
1049 as TTL, and uses the result obtained from DNS as long as it happens
1050 to be stored in the memory of the application. For applications
1051 which run for a long time, this could be days, weeks or even months;
1052 some applications may be clever enough to organize the data
1053 structures and functions in such a manner that look-ups get refreshed
1056 While the issue appears to have a clear solution, "fix the
1057 applications", practically this is not reasonable immediate advice;
1058 the TTL information is not typically available in the APIs and
1059 libraries (so, the advice becomes "fix the applications, APIs and
1060 libraries"), and a lot more analysis is needed on how to practically
1064 Durand, et al. Expires January 17, 2006 [Page 19]
1066 Internet-Draft Considerations with IPv6 DNS July 2005
1069 go about to achieve the ultimate goal of avoiding using the names
1070 longer than expected.
1074 Some recommendations (Section 4.3, Section 5.1) about IPv6 service
1075 provisioning were moved here from [I-D.ietf-v6ops-mech-v2] by Erik
1076 Nordmark and Bob Gilligan. Havard Eidnes and Michael Patton provided
1077 useful feedback and improvements. Scott Rose, Rob Austein, Masataka
1078 Ohta, and Mark Andrews helped in clarifying the issues regarding
1079 additional data and the use of TTL. Jefsey Morfin, Ralph Droms,
1080 Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and
1081 Rob Austein provided useful feedback during the WG last call. Thomas
1082 Narten provided extensive feedback during the IESG evaluation.
1084 10. Security Considerations
1086 This document reviews the operational procedures for IPv6 DNS
1087 operations and does not have security considerations in itself.
1089 However, it is worth noting that in particular with Dynamic DNS
1090 Updates, security models based on the source address validation are
1091 very weak and cannot be recommended -- they could only be considered
1092 in the environments where ingress filtering [RFC3704] has been
1093 deployed. On the other hand, it should be noted that setting up an
1094 authorization mechanism (e.g., a shared secret, or public-private
1095 keys) between a node and the DNS server has to be done manually, and
1096 may require quite a bit of time and expertise.
1098 To re-emphasize what was already stated, the reverse+forward DNS
1099 check provides very weak security at best, and the only
1100 (questionable) security-related use for them may be in conjunction
1101 with other mechanisms when authenticating a user.
1105 11.1 Normative References
1107 [I-D.ietf-dnsop-ipv6-dns-configuration]
1108 Jeong, J., "IPv6 Host Configuration of DNS Server
1109 Information Approaches",
1110 draft-ietf-dnsop-ipv6-dns-configuration-06 (work in
1111 progress), May 2005.
1113 [I-D.ietf-ipv6-unique-local-addr]
1114 Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
1115 Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in
1116 progress), January 2005.
1120 Durand, et al. Expires January 17, 2006 [Page 20]
1122 Internet-Draft Considerations with IPv6 DNS July 2005
1125 [I-D.ietf-v6ops-renumbering-procedure]
1126 Baker, F., "Procedures for Renumbering an IPv6 Network
1127 without a Flag Day",
1128 draft-ietf-v6ops-renumbering-procedure-05 (work in
1129 progress), March 2005.
1131 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
1132 STD 13, RFC 1034, November 1987.
1134 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
1135 "Dynamic Updates in the Domain Name System (DNS UPDATE)",
1136 RFC 2136, April 1997.
1138 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
1139 Specification", RFC 2181, July 1997.
1141 [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
1142 and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
1145 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
1146 Autoconfiguration", RFC 2462, December 1998.
1148 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
1149 RFC 2671, August 1999.
1151 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
1154 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
1155 Update", RFC 3007, November 2000.
1157 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
1158 Stateless Address Autoconfiguration in IPv6", RFC 3041,
1161 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
1162 via IPv4 Clouds", RFC 3056, February 2001.
1164 [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
1167 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
1168 and M. Carney, "Dynamic Host Configuration Protocol for
1169 IPv6 (DHCPv6)", RFC 3315, July 2003.
1171 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
1172 Hain, "Representing Internet Protocol version 6 (IPv6)
1176 Durand, et al. Expires January 17, 2006 [Page 21]
1178 Internet-Draft Considerations with IPv6 DNS July 2005
1181 Addresses in the Domain Name System (DNS)", RFC 3363,
1184 [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS)
1185 Support for Internet Protocol version 6 (IPv6)", RFC 3364,
1188 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
1189 (IPv6) Addressing Architecture", RFC 3513, April 2003.
1191 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
1192 "DNS Extensions to Support IP Version 6", RFC 3596,
1195 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
1196 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
1199 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
1200 (DHCP) Service for IPv6", RFC 3736, April 2004.
1202 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local
1203 Addresses", RFC 3879, September 2004.
1205 [RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational
1206 Guidelines", BCP 91, RFC 3901, September 2004.
1208 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
1209 Castro, "Application Aspects of IPv6 Transition",
1210 RFC 4038, March 2005.
1212 [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against
1213 DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
1215 11.2 Informative References
1217 [I-D.durand-dnsop-dont-publish]
1218 Durand, A. and T. Chown, "To publish, or not to publish,
1219 that is the question.", draft-durand-dnsop-dont-publish-00
1220 (work in progress), February 2005.
1222 [I-D.huitema-v6ops-teredo]
1223 Huitema, C., "Teredo: Tunneling IPv6 over UDP through
1224 NATs", draft-huitema-v6ops-teredo-05 (work in progress),
1227 [I-D.huston-6to4-reverse-dns]
1228 Huston, G., "6to4 Reverse DNS Delegation",
1232 Durand, et al. Expires January 17, 2006 [Page 22]
1234 Internet-Draft Considerations with IPv6 DNS July 2005
1237 draft-huston-6to4-reverse-dns-03 (work in progress),
1240 [I-D.ietf-dhc-ddns-resolution]
1241 Stapp, M. and B. Volz, "Resolution of FQDN Conflicts among
1242 DHCP Clients", draft-ietf-dhc-ddns-resolution-09 (work in
1243 progress), June 2005.
1245 [I-D.ietf-dhc-fqdn-option]
1246 Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option",
1247 draft-ietf-dhc-fqdn-option-10 (work in progress),
1250 [I-D.ietf-dnsext-dhcid-rr]
1251 Stapp, M., Lemon, T., and A. Gustafsson, "A DNS RR for
1252 encoding DHCP information (DHCID RR)",
1253 draft-ietf-dnsext-dhcid-rr-09 (work in progress),
1256 [I-D.ietf-dnsop-bad-dns-res]
1257 Larson, M. and P. Barber, "Observed DNS Resolution
1258 Misbehavior", draft-ietf-dnsop-bad-dns-res-03 (work in
1259 progress), October 2004.
1261 [I-D.ietf-dnsop-inaddr-required]
1262 Senie, D., "Encouraging the use of DNS IN-ADDR Mapping",
1263 draft-ietf-dnsop-inaddr-required-06 (work in progress),
1266 [I-D.ietf-v6ops-3gpp-analysis]
1267 Wiljakka, J., "Analysis on IPv6 Transition in 3GPP
1268 Networks", draft-ietf-v6ops-3gpp-analysis-11 (work in
1269 progress), October 2004.
1271 [I-D.ietf-v6ops-mech-v2]
1272 Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
1273 for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-07
1274 (work in progress), March 2005.
1276 [I-D.ietf-v6ops-natpt-to-exprmntl]
1277 Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
1278 Experimental", draft-ietf-v6ops-natpt-to-exprmntl-01 (work
1279 in progress), July 2005.
1281 [I-D.ietf-v6ops-onlinkassumption]
1282 Roy, S., "IPv6 Neighbor Discovery On-Link Assumption
1283 Considered Harmful", draft-ietf-v6ops-onlinkassumption-03
1284 (work in progress), May 2005.
1288 Durand, et al. Expires January 17, 2006 [Page 23]
1290 Internet-Draft Considerations with IPv6 DNS July 2005
1293 [I-D.ietf-v6ops-v6onbydefault]
1294 Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack
1295 IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03
1296 (work in progress), July 2004.
1298 [I-D.jeong-dnsop-ipv6-dns-discovery]
1299 Jeong, J., "IPv6 DNS Configuration based on Router
1300 Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-04
1301 (work in progress), February 2005.
1303 [I-D.ohta-preconfigured-dns]
1304 Ohta, M., "Preconfigured DNS Server Addresses",
1305 draft-ohta-preconfigured-dns-01 (work in progress),
1308 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
1309 Translation - Protocol Translation (NAT-PT)", RFC 2766,
1312 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
1313 specifying the location of services (DNS SRV)", RFC 2782,
1316 [RFC2826] Internet Architecture Board, "IAB Technical Comment on the
1317 Unique DNS Root", RFC 2826, May 2000.
1319 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
1320 Networks", BCP 84, RFC 3704, March 2004.
1322 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
1323 RFC 3972, March 2005.
1325 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying
1326 Material in DNS", RFC 4025, March 2005.
1332 SUN Microsystems, Inc.
1333 17 Network circle UMPL17-202
1334 Menlo Park, CA 94025
1337 Email: Alain.Durand@sun.com
1344 Durand, et al. Expires January 17, 2006 [Page 24]
1346 Internet-Draft Considerations with IPv6 DNS July 2005
1355 Email: johani@autonomica.se
1363 Email: psavola@funet.fi
1365 Appendix A. Unique Local Addressing Considerations for DNS
1367 Unique local addresses [I-D.ietf-ipv6-unique-local-addr] have
1368 replaced the now-deprecated site-local addresses [RFC3879]. From the
1369 perspective of the DNS, the locally generated unique local addresses
1370 (LUL) and site-local addresses have similar properties.
1372 The interactions with DNS come in two flavors: forward and reverse
1375 To actually use local addresses within a site, this implies the
1376 deployment of a "split-faced" or a fragmented DNS name space, for the
1377 zones internal to the site, and the outsiders' view to it. The
1378 procedures to achieve this are not elaborated here. The implication
1379 is that local addresses must not be published in the public DNS.
1381 To faciliate reverse DNS (if desired) with local addresses, the stub
1382 resolvers must look for DNS information from the local DNS servers,
1383 not e.g. starting from the root servers, so that the local
1384 information may be provided locally. Note that the experience of
1385 private addresses in IPv4 has shown that the root servers get loaded
1386 for requests for private address lookups in any case. This
1387 requirement is discussed in [I-D.ietf-ipv6-unique-local-addr].
1389 Appendix B. Behaviour of Additional Data in IPv4/IPv6 Environments
1391 DNS responses do not always fit in a single UDP packet. We'll
1392 examine the cases which happen when this is due to too much data in
1393 the Additional Section.
1400 Durand, et al. Expires January 17, 2006 [Page 25]
1402 Internet-Draft Considerations with IPv6 DNS July 2005
1405 B.1 Description of Additional Data Scenarios
1407 There are two kinds of additional data:
1409 1. "critical" additional data; this must be included in all
1410 scenarios, with all the RRsets, and
1412 2. "courtesy" additional data; this could be sent in full, with only
1413 a few RRsets, or with no RRsets, and can be fetched separately as
1414 well, but at the cost of additional queries.
1416 The responding server can algorithmically determine which type the
1417 additional data is by checking whether it's at or below a zone cut.
1419 Only those additional data records (even if sometimes carelessly
1420 termed "glue") are considered "critical" or real "glue" if and only
1421 if they meet the abovementioned condition, as specified in Section
1424 Remember that resource record sets (RRsets) are never "broken up", so
1425 if a name has 4 A records and 5 AAAA records, you can either return
1426 all 9, all 4 A records, all 5 AAAA records or nothing. In
1427 particular, notice that for the "critical" additional data getting
1428 all the RRsets can be critical.
1430 In particular, [RFC2181] specifies (in Section 9) that:
1432 a. if all the "critical" RRsets do not fit, the sender should set
1433 the TC bit, and the recipient should discard the whole response
1434 and retry using mechanism allowing larger responses such as TCP.
1436 b. "courtesy" additional data should not cause the setting of TC
1437 bit, but instead all the non-fitting additional data RRsets
1440 An example of the "courtesy" additional data is A/AAAA records in
1441 conjunction with MX records as shown in Section 4.4; an example of
1442 the "critical" additional data is shown below (where getting both the
1443 A and AAAA RRsets is critical w.r.t. to the NS RR):
1445 child.example.com. IN NS ns.child.example.com.
1446 ns.child.example.com. IN A 192.0.2.1
1447 ns.child.example.com. IN AAAA 2001:db8::1
1449 When there is too much "courtesy" additional data, at least the non-
1450 fitting RRsets should be removed [RFC2181]; however, as the
1451 additional data is not critical, even all of it could be safely
1456 Durand, et al. Expires January 17, 2006 [Page 26]
1458 Internet-Draft Considerations with IPv6 DNS July 2005
1461 When there is too much "critical" additional data, TC bit will have
1462 to be set, and the recipient should ignore the response and retry
1463 using TCP; if some data were to be left in the UDP response, the
1464 issue is which data could be retained.
1466 Failing to discard the response with TC bit or omitting critical
1467 information but not setting TC bit lead to an unrecoverable problem.
1468 Omitting only some of the RRsets if all would not fit (but not
1469 setting TC bit) leads to a performance problem. These are discussed
1470 in the next two subsections.
1472 B.2 Which Additional Data to Keep, If Any?
1474 If the implementation decides to keep as much data (whether
1475 "critical" or "courtesy") as possible in the UDP responses, it might
1476 be tempting to use the transport of the DNS query as a hint in either
1477 of these cases: return the AAAA records if the query was done over
1478 IPv6, or return the A records if the query was done over IPv4.
1479 However, this breaks the model of independence of DNS transport and
1480 resource records, as noted in Section 1.2.
1482 With courtesy additional data, as long as enough RRsets will be
1483 removed so that TC will not be set, it is allowed to send as many
1484 complete RRsets as the implementations prefers. However, the
1485 implementations are also free to omit all such RRsets, even if
1486 complete. Omitting all the RRsets (when removing only some would
1487 suffice) may create a performance penalty, whereby the client may
1488 need to issue one or more additional queries to obtain necessary
1489 and/or consistent information.
1491 With critical additional data, the alternatives are either returning
1492 nothing (and absolutely requiring a retry with TCP) or returning
1493 something (working also in the case if the recipient does not discard
1494 the response and retry using TCP) in addition to setting the TC bit.
1495 If the process for selecting "something" from the critical data would
1496 otherwise be practically "flipping the coin" between A and AAAA
1497 records, it could be argued that if one looked at the transport of
1498 the query, it would have a larger possibility of being right than
1499 just 50/50. In other words, if the returned critical additional data
1500 would have to be selected somehow, using something more sophisticated
1501 than a random process would seem justifiable.
1503 That is, leaving in some intelligently selected critical additional
1504 data is a tradeoff between creating an optimization for those
1505 resolvers which ignore the "should discard" recommendation, and
1506 causing a protocol problem by propagating inconsistent information
1507 about "critical" records in the caches.
1512 Durand, et al. Expires January 17, 2006 [Page 27]
1514 Internet-Draft Considerations with IPv6 DNS July 2005
1517 Similarly, leaving in the complete courtesy additional data RRsets
1518 instead of removing all the RRsets is a performance tradeoff as
1519 described in the next section.
1521 B.3 Discussion of the Potential Problems
1523 As noted above, the temptation for omitting only some of the
1524 additional data could be problematic. This is discussed more below.
1526 For courtesy additional data, this causes a potential performance
1527 problem as this requires that the clients issue re-queries for the
1528 potentially omitted RRsets. For critical additional data, this
1529 causes a potential unrecoverable problem if the response is not
1530 discarded and the query not re-tried with TCP, as the nameservers
1531 might be reachable only through the omitted RRsets.
1533 If an implementation would look at the transport used for the query,
1534 it is worth remembering that often the host using the records is
1535 different from the node requesting them from the authoritative DNS
1536 server (or even a caching resolver). So, whichever version the
1537 requestor (e.g., a recursive server in the middle) uses makes no
1538 difference to the ultimate user of the records, whose transport
1539 capabilities might differ from those of the requestor. This might
1540 result in e.g., inappropriately returning A records to an IPv6-only
1541 node, going through a translation, or opening up another IP-level
1542 session (e.g., a PDP context [I-D.ietf-v6ops-3gpp-analysis]).
1543 Therefore, at least in many scenarios, it would be very useful if the
1544 information returned would be consistent and complete -- or if that
1545 is not feasible, return no misleading information but rather leave it
1546 to the client to query again.
1548 The problem of too much additional data seems to be an operational
1549 one: the zone administrator entering too many records which will be
1550 returned either truncated (or missing some RRsets, depending on
1551 implementations) to the users. A protocol fix for this is using
1552 EDNS0 [RFC2671] to signal the capacity for larger UDP packet sizes,
1553 pushing up the relevant threshold. Further, DNS server
1554 implementations should rather omit courtesy additional data
1555 completely rather than including only some RRsets [RFC2181]. An
1556 operational fix for this is having the DNS server implementations
1557 return a warning when the administrators create zones which would
1558 result in too much additional data being returned. Further, DNS
1559 server implementations should warn of or disallow such zone
1560 configurations which are recursive or otherwise difficult to manage
1563 Additionally, to avoid the case where an application would not get an
1564 address at all due to some of courtesy additional data being omitted,
1568 Durand, et al. Expires January 17, 2006 [Page 28]
1570 Internet-Draft Considerations with IPv6 DNS July 2005
1573 the resolvers should be able to query the specific records of the
1574 desired protocol, not just rely on getting all the required RRsets in
1575 the additional section.
1624 Durand, et al. Expires January 17, 2006 [Page 29]
1626 Internet-Draft Considerations with IPv6 DNS July 2005
1629 Intellectual Property Statement
1631 The IETF takes no position regarding the validity or scope of any
1632 Intellectual Property Rights or other rights that might be claimed to
1633 pertain to the implementation or use of the technology described in
1634 this document or the extent to which any license under such rights
1635 might or might not be available; nor does it represent that it has
1636 made any independent effort to identify any such rights. Information
1637 on the procedures with respect to rights in RFC documents can be
1638 found in BCP 78 and BCP 79.
1640 Copies of IPR disclosures made to the IETF Secretariat and any
1641 assurances of licenses to be made available, or the result of an
1642 attempt made to obtain a general license or permission for the use of
1643 such proprietary rights by implementers or users of this
1644 specification can be obtained from the IETF on-line IPR repository at
1645 http://www.ietf.org/ipr.
1647 The IETF invites any interested party to bring to its attention any
1648 copyrights, patents or patent applications, or other proprietary
1649 rights that may cover technology that may be required to implement
1650 this standard. Please address the information to the IETF at
1654 Disclaimer of Validity
1656 This document and the information contained herein are provided on an
1657 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1658 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1659 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1660 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1661 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1662 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1667 Copyright (C) The Internet Society (2005). This document is subject
1668 to the rights, licenses and restrictions contained in BCP 78, and
1669 except as set forth therein, the authors retain all their rights.
1674 Funding for the RFC Editor function is currently provided by the
1680 Durand, et al. Expires January 17, 2006 [Page 30]