1 Network Working Group A. Durand
2 Request for Comments: 4472 Comcast
3 Category: Informational J. Ihren
4 Autonomica
5 P. Savola
6 CSC/FUNET
7 April 2006
8
9
10 Operational Considerations and Issues with IPv6 DNS
11
12 Status of This Memo
13
14 This memo provides information for the Internet community. It does
15 not specify an Internet standard of any kind. Distribution of this
16 memo is unlimited.
17
18 Copyright Notice
19
20 Copyright (C) The Internet Society (2006).
21
22 Abstract
23
24 This memo presents operational considerations and issues with IPv6
25 Domain Name System (DNS), including a summary of special IPv6
26 addresses, documentation of known DNS implementation misbehavior,
27 recommendations and considerations on how to perform DNS naming for
28 service provisioning and for DNS resolver IPv6 support,
29 considerations for DNS updates for both the forward and reverse
30 trees, and miscellaneous issues. This memo is aimed to include a
31 summary of information about IPv6 DNS considerations for those who
32 have experience with IPv4 DNS.
33
34 Table of Contents
35
36 1. Introduction ....................................................3
37 1.1. Representing IPv6 Addresses in DNS Records .................3
38 1.2. Independence of DNS Transport and DNS Records ..............4
39 1.3. Avoiding IPv4/IPv6 Name Space Fragmentation ................4
40 1.4. Query Type '*' and A/AAAA Records ..........................4
41 2. DNS Considerations about Special IPv6 Addresses .................5
42 2.1. Limited-Scope Addresses ....................................5
43 2.2. Temporary Addresses ........................................5
44 2.3. 6to4 Addresses .............................................5
45 2.4. Other Transition Mechanisms ................................5
46 3. Observed DNS Implementation Misbehavior .........................6
47 3.1. Misbehavior of DNS Servers and Load-balancers ..............6
48 3.2. Misbehavior of DNS Resolvers ...............................6
49
50
51
52 Durand, et al. Informational [Page 1]
53 RFC 4472 Considerations with IPv6 DNS April 2006
54
55
56 4. Recommendations for Service Provisioning Using DNS ..............7
57 4.1. Use of Service Names instead of Node Names .................7
58 4.2. Separate vs. the Same Service Names for IPv4 and IPv6 ......8
59 4.3. Adding the Records Only When Fully IPv6-enabled ............8
60 4.4. The Use of TTL for IPv4 and IPv6 RRs .......................9
61 4.4.1. TTL with Courtesy Additional Data ...................9
62 4.4.2. TTL with Critical Additional Data ..................10
63 4.5. IPv6 Transport Guidelines for DNS Servers .................10
64 5. Recommendations for DNS Resolver IPv6 Support ..................10
65 5.1. DNS Lookups May Query IPv6 Records Prematurely ............10
66 5.2. Obtaining a List of DNS Recursive Resolvers ...............12
67 5.3. IPv6 Transport Guidelines for Resolvers ...................12
68 6. Considerations about Forward DNS Updating ......................13
69 6.1. Manual or Custom DNS Updates ..............................13
70 6.2. Dynamic DNS ...............................................13
71 7. Considerations about Reverse DNS Updating ......................14
72 7.1. Applicability of Reverse DNS ..............................14
73 7.2. Manual or Custom DNS Updates ..............................15
74 7.3. DDNS with Stateless Address Autoconfiguration .............16
75 7.4. DDNS with DHCP ............................................17
76 7.5. DDNS with Dynamic Prefix Delegation .......................17
77 8. Miscellaneous DNS Considerations ...............................18
78 8.1. NAT-PT with DNS-ALG .......................................18
79 8.2. Renumbering Procedures and Applications' Use of DNS .......18
80 9. Acknowledgements ...............................................19
81 10. Security Considerations .......................................19
82 11. References ....................................................20
83 11.1. Normative References .....................................20
84 11.2. Informative References ...................................22
85 Appendix A. Unique Local Addressing Considerations for DNS ........24
86 Appendix B. Behavior of Additional Data in IPv4/IPv6
87 Environments ..........................................24
88 B.1. Description of Additional Data Scenarios ..................24
89 B.2. Which Additional Data to Keep, If Any? ....................26
90 B.3. Discussion of the Potential Problems ......................27
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107 Durand, et al. Informational [Page 2]
108 RFC 4472 Considerations with IPv6 DNS April 2006
109
110
111 1. Introduction
112
113 This memo presents operational considerations and issues with IPv6
114 DNS; it is meant to be an extensive summary and a list of pointers
115 for more information about IPv6 DNS considerations for those with
116 experience with IPv4 DNS.
117
118 The purpose of this document is to give information about various
119 issues and considerations related to DNS operations with IPv6; it is
120 not meant to be a normative specification or standard for IPv6 DNS.
121
122 The first section gives a brief overview of how IPv6 addresses and
123 names are represented in the DNS, how transport protocols and
124 resource records (don't) relate, and what IPv4/IPv6 name space
125 fragmentation means and how to avoid it; all of these are described
126 at more length in other documents.
127
128 The second section summarizes the special IPv6 address types and how
129 they relate to DNS. The third section describes observed DNS
130 implementation misbehaviors that have a varying effect on the use of
131 IPv6 records with DNS. The fourth section lists recommendations and
132 considerations for provisioning services with DNS. The fifth section
133 in turn looks at recommendations and considerations about providing
134 IPv6 support in the resolvers. The sixth and seventh sections
135 describe considerations with forward and reverse DNS updates,
136 respectively. The eighth section introduces several miscellaneous
137 IPv6 issues relating to DNS for which no better place has been found
138 in this memo. Appendix A looks briefly at the requirements for
139 unique local addressing. Appendix B discusses additional data.
140
141 1.1. Representing IPv6 Addresses in DNS Records
142
143 In the forward zones, IPv6 addresses are represented using AAAA
144 records. In the reverse zones, IPv6 address are represented using
145 PTR records in the nibble format under the ip6.arpa. tree. See
146 [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152]
147 for background information.
148
149 In particular, one should note that the use of A6 records in the
150 forward tree or Bitlabels in the reverse tree is not recommended
151 [RFC3363]. Using DNAME records is not recommended in the reverse
152 tree in conjunction with A6 records; the document did not mean to
153 take a stance on any other use of DNAME records [RFC3364].
154
155
156
157
158
159
160
161
162 Durand, et al. Informational [Page 3]
163 RFC 4472 Considerations with IPv6 DNS April 2006
164
165
166 1.2. Independence of DNS Transport and DNS Records
167
168 DNS has been designed to present a single, globally unique name space
169 [RFC2826]. This property should be maintained, as described here and
170 in Section 1.3.
171
172 The IP version used to transport the DNS queries and responses is
173 independent of the records being queried: AAAA records can be queried
174 over IPv4, and A records over IPv6. The DNS servers must not make
175 any assumptions about what data to return for Answer and Authority
176 sections based on the underlying transport used in a query.
177
178 However, there is some debate whether the addresses in Additional
179 section could be selected or filtered using hints obtained from which
180 transport was being used; this has some obvious problems because in
181 many cases the transport protocol does not correlate with the
182 requests, and because a "bad" answer is in a way worse than no answer
183 at all (consider the case where the client is led to believe that a
184 name received in the additional record does not have any AAAA records
185 at all).
186
187 As stated in [RFC3596]:
188
189 The IP protocol version used for querying resource records is
190 independent of the protocol version of the resource records; e.g.,
191 IPv4 transport can be used to query IPv6 records and vice versa.
192
193 1.3. Avoiding IPv4/IPv6 Name Space Fragmentation
194
195 To avoid the DNS name space from fragmenting into parts where some
196 parts of DNS are only visible using IPv4 (or IPv6) transport, the
197 recommendation is to always keep at least one authoritative server
198 IPv4-enabled, and to ensure that recursive DNS servers support IPv4.
199 See DNS IPv6 transport guidelines [RFC3901] for more information.
200
201 1.4. Query Type '*' and A/AAAA Records
202
203 QTYPE=* is typically only used for debugging or management purposes;
204 it is worth keeping in mind that QTYPE=* ("ANY" queries) only return
205 any available RRsets, not *all* the RRsets, because the caches do not
206 necessarily have all the RRsets and have no way of guaranteeing that
207 they have all the RRsets. Therefore, to get both A and AAAA records
208 reliably, two separate queries must be made.
209
210
211
212
213
214
215
216
217 Durand, et al. Informational [Page 4]
218 RFC 4472 Considerations with IPv6 DNS April 2006
219
220
221 2. DNS Considerations about Special IPv6 Addresses
222
223 There are a couple of IPv6 address types that are somewhat special;
224 these are considered here.
225
226 2.1. Limited-Scope Addresses
227
228 The IPv6 addressing architecture [RFC4291] includes two kinds of
229 local-use addresses: link-local (fe80::/10) and site-local
230 (fec0::/10). The site-local addresses have been deprecated [RFC3879]
231 but are discussed with unique local addresses in Appendix A.
232
233 Link-local addresses should never be published in DNS (whether in
234 forward or reverse tree), because they have only local (to the
235 connected link) significance [WIP-DC2005].
236
237 2.2. Temporary Addresses
238
239 Temporary addresses defined in RFC 3041 [RFC3041] (sometimes called
240 "privacy addresses") use a random number as the interface identifier.
241 Having DNS AAAA records that are updated to always contain the
242 current value of a node's temporary address would defeat the purpose
243 of the mechanism and is not recommended. However, it would still be
244 possible to return a non-identifiable name (e.g., the IPv6 address in
245 hexadecimal format), as described in [RFC3041].
246
247 2.3. 6to4 Addresses
248
249 6to4 [RFC3056] specifies an automatic tunneling mechanism that maps a
250 public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48.
251
252 If the reverse DNS population would be desirable (see Section 7.1 for
253 applicability), there are a number of possible ways to do so.
254
255 [WIP-H2005] aims to design an autonomous reverse-delegation system
256 that anyone being capable of communicating using a specific 6to4
257 address would be able to set up a reverse delegation to the
258 corresponding 6to4 prefix. This could be deployed by, e.g., Regional
259 Internet Registries (RIRs). This is a practical solution, but may
260 have some scalability concerns.
261
262 2.4. Other Transition Mechanisms
263
264 6to4 is mentioned as a case of an IPv6 transition mechanism requiring
265 special considerations. In general, mechanisms that include a
266 special prefix may need a custom solution; otherwise, for example,
267 when IPv4 address is embedded as the suffix or not embedded at all,
268 special solutions are likely not needed.
269
270
271
272 Durand, et al. Informational [Page 5]
273 RFC 4472 Considerations with IPv6 DNS April 2006
274
275
276 Note that it does not seem feasible to provide reverse DNS with
277 another automatic tunneling mechanism, Teredo [RFC4380]; this is
278 because the IPv6 address is based on the IPv4 address and UDP port of
279 the current Network Address Translation (NAT) mapping, which is
280 likely to be relatively short-lived.
281
282 3. Observed DNS Implementation Misbehavior
283
284 Several classes of misbehavior in DNS servers, load-balancers, and
285 resolvers have been observed. Most of these are rather generic, not
286 only applicable to IPv6 -- but in some cases, the consequences of
287 this misbehavior are extremely severe in IPv6 environments and
288 deserve to be mentioned.
289
290 3.1. Misbehavior of DNS Servers and Load-balancers
291
292 There are several classes of misbehavior in certain DNS servers and
293 load-balancers that have been noticed and documented [RFC4074]: some
294 implementations silently drop queries for unimplemented DNS records
295 types, or provide wrong answers to such queries (instead of a proper
296 negative reply). While typically these issues are not limited to
297 AAAA records, the problems are aggravated by the fact that AAAA
298 records are being queried instead of (mainly) A records.
299
300 The problems are serious because when looking up a DNS name, typical
301 getaddrinfo() implementations, with AF_UNSPEC hint given, first try
302 to query the AAAA records of the name, and after receiving a
303 response, query the A records. This is done in a serial fashion --
304 if the first query is never responded to (instead of properly
305 returning a negative answer), significant time-outs will occur.
306
307 In consequence, this is an enormous problem for IPv6 deployments, and
308 in some cases, IPv6 support in the software has even been disabled
309 due to these problems.
310
311 The solution is to fix or retire those misbehaving implementations,
312 but that is likely not going to be effective. There are some
313 possible ways to mitigate the problem, e.g., by performing the
314 lookups somewhat in parallel and reducing the time-out as long as at
315 least one answer has been received, but such methods remain to be
316 investigated; slightly more on this is included in Section 5.
317
318 3.2. Misbehavior of DNS Resolvers
319
320 Several classes of misbehavior have also been noticed in DNS
321 resolvers [WIP-LB2005]. However, these do not seem to directly
322 impair IPv6 use, and are only referred to for completeness.
323
324
325
326
327 Durand, et al. Informational [Page 6]
328 RFC 4472 Considerations with IPv6 DNS April 2006
329
330
331 4. Recommendations for Service Provisioning Using DNS
332
333 When names are added in the DNS to facilitate a service, there are
334 several general guidelines to consider to be able to do it as
335 smoothly as possible.
336
337 4.1. Use of Service Names instead of Node Names
338
339 It makes sense to keep information about separate services logically
340 separate in the DNS by using a different DNS hostname for each
341 service. There are several reasons for doing this, for example:
342
343 o It allows more flexibility and ease for migration of (only a part
344 of) services from one node to another,
345
346 o It allows configuring different properties (e.g., Time to Live
347 (TTL)) for each service, and
348
349 o It allows deciding separately for each service whether or not to
350 publish the IPv6 addresses (in cases where some services are more
351 IPv6-ready than others).
352
353 Using SRV records [RFC2782] would avoid these problems.
354 Unfortunately, those are not sufficiently widely used to be
355 applicable in most cases. Hence an operation technique is to use
356 service names instead of node names (or "hostnames"). This
357 operational technique is not specific to IPv6, but required to
358 understand the considerations described in Section 4.2 and
359 Section 4.3.
360
361 For example, assume a node named "pobox.example.com" provides both
362 SMTP and IMAP service. Instead of configuring the MX records to
363 point at "pobox.example.com", and configuring the mail clients to
364 look up the mail via IMAP from "pobox.example.com", one could use,
365 e.g., "smtp.example.com" for SMTP (for both message submission and
366 mail relaying between SMTP servers) and "imap.example.com" for IMAP.
367 Note that in the specific case of SMTP relaying, the server itself
368 must typically also be configured to know all its names to ensure
369 that loops do not occur. DNS can provide a layer of indirection
370 between service names and where the service actually is, and using
371 which addresses. (Obviously, when wanting to reach a specific node,
372 one should use the hostname rather than a service name.)
373
374
375
376
377
378
379
380
381
382 Durand, et al. Informational [Page 7]
383 RFC 4472 Considerations with IPv6 DNS April 2006
384
385
386 4.2. Separate vs. the Same Service Names for IPv4 and IPv6
387
388 The service naming can be achieved in basically two ways: when a
389 service is named "service.example.com" for IPv4, the IPv6-enabled
390 service could either be added to "service.example.com" or added
391 separately under a different name, e.g., in a sub-domain like
392 "service.ipv6.example.com".
393
394 These two methods have different characteristics. Using a different
395 name allows for easier service piloting, minimizing the disturbance
396 to the "regular" users of IPv4 service; however, the service would
397 not be used transparently, without the user/application explicitly
398 finding it and asking for it -- which would be a disadvantage in most
399 cases. When the different name is under a sub-domain, if the
400 services are deployed within a restricted network (e.g., inside an
401 enterprise), it's possible to prefer them transparently, at least to
402 a degree, by modifying the DNS search path; however, this is a
403 suboptimal solution. Using the same service name is the "long-term"
404 solution, but may degrade performance for those clients whose IPv6
405 performance is lower than IPv4, or does not work as well (see
406 Section 4.3 for more).
407
408 In most cases, it makes sense to pilot or test a service using
409 separate service names, and move to the use of the same name when
410 confident enough that the service level will not degrade for the
411 users unaware of IPv6.
412
413 4.3. Adding the Records Only When Fully IPv6-enabled
414
415 The recommendation is that AAAA records for a service should not be
416 added to the DNS until all of following are true:
417
418 1. The address is assigned to the interface on the node.
419
420 2. The address is configured on the interface.
421
422 3. The interface is on a link that is connected to the IPv6
423 infrastructure.
424
425 In addition, if the AAAA record is added for the node, instead of
426 service as recommended, all the services of the node should be IPv6-
427 enabled prior to adding the resource record.
428
429 For example, if an IPv6 node is isolated from an IPv6 perspective
430 (e.g., it is not connected to IPv6 Internet) constraint #3 would mean
431 that it should not have an address in the DNS.
432
433
434
435
436
437 Durand, et al. Informational [Page 8]
438 RFC 4472 Considerations with IPv6 DNS April 2006
439
440
441 Consider the case of two dual-stack nodes, which both are IPv6-
442 enabled, but the server does not have (global) IPv6 connectivity. As
443 the client looks up the server's name, only A records are returned
444 (if the recommendations above are followed), and no IPv6
445 communication, which would have been unsuccessful, is even attempted.
446
447 The issues are not always so black-and-white. Usually, it's
448 important that the service offered using both protocols is of roughly
449 equal quality, using the appropriate metrics for the service (e.g.,
450 latency, throughput, low packet loss, general reliability, etc.).
451 This is typically very important especially for interactive or real-
452 time services. In many cases, the quality of IPv6 connectivity may
453 not yet be equal to that of IPv4, at least globally; this has to be
454 taken into consideration when enabling services.
455
456 4.4. The Use of TTL for IPv4 and IPv6 RRs
457
458 The behavior of DNS caching when different TTL values are used for
459 different RRsets of the same name calls for explicit discussion. For
460 example, let's consider two unrelated zone fragments:
461
462 example.com. 300 IN MX foo.example.com.
463 foo.example.com. 300 IN A 192.0.2.1
464 foo.example.com. 100 IN AAAA 2001:db8::1
465
466 ...
467
468 child.example.com. 300 IN NS ns.child.example.com.
469 ns.child.example.com. 300 IN A 192.0.2.1
470 ns.child.example.com. 100 IN AAAA 2001:db8::1
471
472 In the former case, we have "courtesy" additional data; in the
473 latter, we have "critical" additional data. See more extensive
474 background discussion of additional data handling in Appendix B.
475
476 4.4.1. TTL with Courtesy Additional Data
477
478 When a caching resolver asks for the MX record of example.com, it
479 gets back "foo.example.com". It may also get back either one or both
480 of the A and AAAA records in the additional section. The resolver
481 must explicitly query for both A and AAAA records [RFC2821].
482
483 After 100 seconds, the AAAA record is removed from the cache(s)
484 because its TTL expired. It could be argued to be useful for the
485 caching resolvers to discard the A record when the shorter TTL (in
486 this case, for the AAAA record) expires; this would avoid the
487 situation where there would be a window of 200 seconds when
488 incomplete information is returned from the cache. Further argument
489
490
491
492 Durand, et al. Informational [Page 9]
493 RFC 4472 Considerations with IPv6 DNS April 2006
494
495
496 for discarding is that in the normal operation, the TTL values are so
497 high that very likely the incurred additional queries would not be
498 noticeable, compared to the obtained performance optimization. The
499 behavior in this scenario is unspecified.
500
501 4.4.2. TTL with Critical Additional Data
502
503 The difference to courtesy additional data is that the A/AAAA records
504 served by the parent zone cannot be queried explicitly. Therefore,
505 after 100 seconds the AAAA record is removed from the cache(s), but
506 the A record remains. Queries for the remaining 200 seconds
507 (provided that there are no further queries from the parent that
508 could refresh the caches) only return the A record, leading to a
509 potential operational situation with unreachable servers.
510
511 Similar cache flushing strategies apply in this scenario; the
512 behavior is likewise unspecified.
513
514 4.5. IPv6 Transport Guidelines for DNS Servers
515
516 As described in Section 1.3 and [RFC3901], there should continue to
517 be at least one authoritative IPv4 DNS server for every zone, even if
518 the zone has only IPv6 records. (Note that obviously, having more
519 servers with robust connectivity would be preferable, but this is the
520 minimum recommendation; also see [RFC2182].)
521
522 5. Recommendations for DNS Resolver IPv6 Support
523
524 When IPv6 is enabled on a node, there are several things to consider
525 to ensure that the process is as smooth as possible.
526
527 5.1. DNS Lookups May Query IPv6 Records Prematurely
528
529 The system library that implements the getaddrinfo() function for
530 looking up names is a critical piece when considering the robustness
531 of enabling IPv6; it may come in basically three flavors:
532
533 1. The system library does not know whether IPv6 has been enabled in
534 the kernel of the operating system: it may start looking up AAAA
535 records with getaddrinfo() and AF_UNSPEC hint when the system is
536 upgraded to a system library version that supports IPv6.
537
538 2. The system library might start to perform IPv6 queries with
539 getaddrinfo() only when IPv6 has been enabled in the kernel.
540 However, this does not guarantee that there exists any useful
541 IPv6 connectivity (e.g., the node could be isolated from the
542 other IPv6 networks, only having link-local addresses).
543
544
545
546
547 Durand, et al. Informational [Page 10]
548 RFC 4472 Considerations with IPv6 DNS April 2006
549
550
551 3. The system library might implement a toggle that would apply some
552 heuristics to the "IPv6-readiness" of the node before starting to
553 perform queries; for example, it could check whether only link-
554 local IPv6 address(es) exists, or if at least one global IPv6
555 address exists.
556
557 First, let us consider generic implications of unnecessary queries
558 for AAAA records: when looking up all the records in the DNS, AAAA
559 records are typically tried first, and then A records. These are
560 done in serial, and the A query is not performed until a response is
561 received to the AAAA query. Considering the misbehavior of DNS
562 servers and load-balancers, as described in Section 3.1, the lookup
563 delay for AAAA may incur additional unnecessary latency, and
564 introduce a component of unreliability.
565
566 One option here could be to do the queries partially in parallel; for
567 example, if the final response to the AAAA query is not received in
568 0.5 seconds, start performing the A query while waiting for the
569 result. (Immediate parallelism might not be optimal, at least
570 without information-sharing between the lookup threads, as that would
571 probably lead to duplicate non-cached delegation chain lookups.)
572
573 An additional concern is the address selection, which may, in some
574 circumstances, prefer AAAA records over A records even when the node
575 does not have any IPv6 connectivity [WIP-RDP2004]. In some cases,
576 the implementation may attempt to connect or send a datagram on a
577 physical link [WIP-R2006], incurring very long protocol time-outs,
578 instead of quickly falling back to IPv4.
579
580 Now, we can consider the issues specific to each of the three
581 possibilities:
582
583 In the first case, the node performs a number of completely useless
584 DNS lookups as it will not be able to use the returned AAAA records
585 anyway. (The only exception is where the application desires to know
586 what's in the DNS, but not use the result for communication.) One
587 should be able to disable these unnecessary queries, for both latency
588 and reliability reasons. However, as IPv6 has not been enabled, the
589 connections to IPv6 addresses fail immediately, and if the
590 application is programmed properly, the application can fall
591 gracefully back to IPv4 [RFC4038].
592
593 The second case is similar to the first, except it happens to a
594 smaller set of nodes when IPv6 has been enabled but connectivity has
595 not been provided yet. Similar considerations apply, with the
596 exception that IPv6 records, when returned, will be actually tried
597 first, which may typically lead to long time-outs.
598
599
600
601
602 Durand, et al. Informational [Page 11]
603 RFC 4472 Considerations with IPv6 DNS April 2006
604
605
606 The third case is a bit more complex: optimizing away the DNS lookups
607 with only link-locals is probably safe (but may be desirable with
608 different lookup services that getaddrinfo() may support), as the
609 link-locals are typically automatically generated when IPv6 is
610 enabled, and do not indicate any form of IPv6 connectivity. That is,
611 performing DNS lookups only when a non-link-local address has been
612 configured on any interface could be beneficial -- this would be an
613 indication that the address has been configured either from a router
614 advertisement, Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
615 [RFC3315], or manually. Each would indicate at least some form of
616 IPv6 connectivity, even though there would not be guarantees of it.
617
618 These issues should be analyzed at more depth, and the fixes found
619 consensus on, perhaps in a separate document.
620
621 5.2. Obtaining a List of DNS Recursive Resolvers
622
623 In scenarios where DHCPv6 is available, a host can discover a list of
624 DNS recursive resolvers through the DHCPv6 "DNS Recursive Name
625 Server" option [RFC3646]. This option can be passed to a host
626 through a subset of DHCPv6 [RFC3736].
627
628 The IETF is considering the development of alternative mechanisms for
629 obtaining the list of DNS recursive name servers when DHCPv6 is
630 unavailable or inappropriate. No decision about taking on this
631 development work has been reached as of this writing [RFC4339].
632
633 In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms
634 under consideration for development include the use of [WIP-O2004]
635 and the use of Router Advertisements to convey the information
636 [WIP-J2006].
637
638 Note that even though IPv6 DNS resolver discovery is a recommended
639 procedure, it is not required for dual-stack nodes in dual-stack
640 networks as IPv6 DNS records can be queried over IPv4 as well as
641 IPv6. Obviously, nodes that are meant to function without manual
642 configuration in IPv6-only networks must implement the DNS resolver
643 discovery function.
644
645 5.3. IPv6 Transport Guidelines for Resolvers
646
647 As described in Section 1.3 and [RFC3901], the recursive resolvers
648 should be IPv4-only or dual-stack to be able to reach any IPv4-only
649 DNS server. Note that this requirement is also fulfilled by an IPv6-
650 only stub resolver pointing to a dual-stack recursive DNS resolver.
651
652
653
654
655
656
657 Durand, et al. Informational [Page 12]
658 RFC 4472 Considerations with IPv6 DNS April 2006
659
660
661 6. Considerations about Forward DNS Updating
662
663 While the topic of how to enable updating the forward DNS, i.e., the
664 mapping from names to the correct new addresses, is not specific to
665 IPv6, it should be considered especially due to the advent of
666 Stateless Address Autoconfiguration [RFC2462].
667
668 Typically, forward DNS updates are more manageable than doing them in
669 the reverse DNS, because the updater can often be assumed to "own" a
670 certain DNS name -- and we can create a form of security relationship
671 with the DNS name and the node that is allowed to update it to point
672 to a new address.
673
674 A more complex form of DNS updates -- adding a whole new name into a
675 DNS zone, instead of updating an existing name -- is considered out
676 of scope for this memo as it could require zone-wide authentication.
677 Adding a new name in the forward zone is a problem that is still
678 being explored with IPv4, and IPv6 does not seem to add much new in
679 that area.
680
681 6.1. Manual or Custom DNS Updates
682
683 The DNS mappings can also be maintained by hand, in a semi-automatic
684 fashion or by running non-standardized protocols. These are not
685 considered at more length in this memo.
686
687 6.2. Dynamic DNS
688
689 Dynamic DNS updates (DDNS) [RFC2136] [RFC3007] is a standardized
690 mechanism for dynamically updating the DNS. It works equally well
691 with Stateless Address Autoconfiguration (SLAAC), DHCPv6, or manual
692 address configuration. It is important to consider how each of these
693 behave if IP address-based authentication, instead of stronger
694 mechanisms [RFC3007], was used in the updates.
695
696 1. Manual addresses are static and can be configured.
697
698 2. DHCPv6 addresses could be reasonably static or dynamic, depending
699 on the deployment, and could or could not be configured on the
700 DNS server for the long term.
701
702 3. SLAAC addresses are typically stable for a long time, but could
703 require work to be configured and maintained.
704
705 As relying on IP addresses for Dynamic DNS is rather insecure at
706 best, stronger authentication should always be used; however, this
707 requires that the authorization keying will be explicitly configured
708 using unspecified operational methods.
709
710
711
712 Durand, et al. Informational [Page 13]
713 RFC 4472 Considerations with IPv6 DNS April 2006
714
715
716 Note that with DHCP it is also possible that the DHCP server updates
717 the DNS, not the host. The host might only indicate in the DHCP
718 exchange which hostname it would prefer, and the DHCP server would
719 make the appropriate updates. Nonetheless, while this makes setting
720 up a secure channel between the updater and the DNS server easier, it
721 does not help much with "content" security, i.e., whether the
722 hostname was acceptable -- if the DNS server does not include
723 policies, they must be included in the DHCP server (e.g., a regular
724 host should not be able to state that its name is "www.example.com").
725 DHCP-initiated DDNS updates have been extensively described in
726 [WIP-SV2005], [WIP-S2005a], and [WIP-S2005b].
727
728 The nodes must somehow be configured with the information about the
729 servers where they will attempt to update their addresses, sufficient
730 security material for authenticating themselves to the server, and
731 the hostname they will be updating. Unless otherwise configured, the
732 first could be obtained by looking up the authoritative name servers
733 for the hostname; the second must be configured explicitly unless one
734 chooses to trust the IP address-based authentication (not a good
735 idea); and lastly, the nodename is typically pre-configured somehow
736 on the node, e.g., at install time.
737
738 Care should be observed when updating the addresses not to use longer
739 TTLs for addresses than are preferred lifetimes for the addresses, so
740 that if the node is renumbered in a managed fashion, the amount of
741 stale DNS information is kept to the minimum. That is, if the
742 preferred lifetime of an address expires, the TTL of the record needs
743 to be modified unless it was already done before the expiration. For
744 better flexibility, the DNS TTL should be much shorter (e.g., a half
745 or a third) than the lifetime of an address; that way, the node can
746 start lowering the DNS TTL if it seems like the address has not been
747 renewed/refreshed in a while. Some discussion on how an
748 administrator could manage the DNS TTL is included in [RFC4192]; this
749 could be applied to (smart) hosts as well.
750
751 7. Considerations about Reverse DNS Updating
752
753 Updating the reverse DNS zone may be difficult because of the split
754 authority over an address. However, first we have to consider the
755 applicability of reverse DNS in the first place.
756
757 7.1. Applicability of Reverse DNS
758
759 Today, some applications use reverse DNS either to look up some hints
760 about the topological information associated with an address (e.g.,
761 resolving web server access logs) or (as a weak form of a security
762 check) to get a feel whether the user's network administrator has
763
764
765
766
767 Durand, et al. Informational [Page 14]
768 RFC 4472 Considerations with IPv6 DNS April 2006
769
770
771 "authorized" the use of the address (on the premise that adding a
772 reverse record for an address would signal some form of
773 authorization).
774
775 One additional, maybe slightly more useful usage is ensuring that the
776 reverse and forward DNS contents match (by looking up the pointer to
777 the name by the IP address from the reverse tree, and ensuring that a
778 record under the name in the forward tree points to the IP address)
779 and correspond to a configured name or domain. As a security check,
780 it is typically accompanied by other mechanisms, such as a user/
781 password login; the main purpose of the reverse+forward DNS check is
782 to weed out the majority of unauthorized users, and if someone
783 managed to bypass the checks, he would still need to authenticate
784 "properly".
785
786 It may also be desirable to store IPsec keying material corresponding
787 to an IP address in the reverse DNS, as justified and described in
788 [RFC4025].
789
790 It is not clear whether it makes sense to require or recommend that
791 reverse DNS records be updated. In many cases, it would just make
792 more sense to use proper mechanisms for security (or topological
793 information lookup) in the first place. At minimum, the applications
794 that use it as a generic authorization (in the sense that a record
795 exists at all) should be modified as soon as possible to avoid such
796 lookups completely.
797
798 The applicability is discussed at more length in [WIP-S2005c].
799
800 7.2. Manual or Custom DNS Updates
801
802 Reverse DNS can of course be updated using manual or custom methods.
803 These are not further described here, except for one special case.
804
805 One way to deploy reverse DNS would be to use wildcard records, for
806 example, by configuring one name for a subnet (/64) or a site (/48).
807 As a concrete example, a site (or the site's ISP) could configure the
808 reverses of the prefix 2001:db8:f00::/48 to point to one name using a
809 wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR
810 site.example.com.". Naturally, such a name could not be verified
811 from the forward DNS, but would at least provide some form of
812 "topological information" or "weak authorization" if that is really
813 considered to be useful. Note that this is not actually updating the
814 DNS as such, as the whole point is to avoid DNS updates completely by
815 manually configuring a generic name.
816
817
818
819
820
821
822 Durand, et al. Informational [Page 15]
823 RFC 4472 Considerations with IPv6 DNS April 2006
824
825
826 7.3. DDNS with Stateless Address Autoconfiguration
827
828 Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in
829 some regard, while being more difficult in another, as described
830 below.
831
832 The address space administrator decides whether or not the hosts are
833 trusted to update their reverse DNS records. If they are trusted and
834 deployed at the same site (e.g., not across the Internet), a simple
835 address-based authorization is typically sufficient (i.e., check that
836 the DNS update is done from the same IP address as the record being
837 updated); stronger security can also be used [RFC3007]. If they
838 aren't allowed to update the reverses, no update can occur. However,
839 such address-based update authorization operationally requires that
840 ingress filtering [RFC3704] has been set up at the border of the site
841 where the updates occur, and as close to the updater as possible.
842
843 Address-based authorization is simpler with reverse DNS (as there is
844 a connection between the record and the address) than with forward
845 DNS. However, when a stronger form of security is used, forward DNS
846 updates are simpler to manage because the host can be assumed to have
847 an association with the domain. Note that the user may roam to
848 different networks and does not necessarily have any association with
849 the owner of that address space. So, assuming a stronger form of
850 authorization for reverse DNS updates than an address association is
851 generally infeasible.
852
853 Moreover, the reverse zones must be cleaned up by an unspecified
854 janitorial process: the node does not typically know a priori that it
855 will be disconnected, and it cannot send a DNS update using the
856 correct source address to remove a record.
857
858 A problem with defining the clean-up process is that it is difficult
859 to ensure that a specific IP address and the corresponding record are
860 no longer being used. Considering the huge address space, and the
861 unlikelihood of collision within 64 bits of the interface
862 identifiers, a process that would remove the record after no traffic
863 has been seen from a node in a long period of time (e.g., a month or
864 year) might be one possible approach.
865
866 To insert or update the record, the node must discover the DNS server
867 to send the update to somehow, similar to as discussed in
868 Section 6.2. One way to automate this is looking up the DNS server
869 authoritative (e.g., through SOA record) for the IP address being
870 updated, but the security material (unless the IP address-based
871 authorization is trusted) must also be established by some other
872 means.
873
874
875
876
877 Durand, et al. Informational [Page 16]
878 RFC 4472 Considerations with IPv6 DNS April 2006
879
880
881 One should note that Cryptographically Generated Addresses (CGAs)
882 [RFC3972] may require a slightly different kind of treatment. CGAs
883 are addresses where the interface identifier is calculated from a
884 public key, a modifier (used as a nonce), the subnet prefix, and
885 other data. Depending on the usage profile, CGAs might or might not
886 be changed periodically due to, e.g., privacy reasons. As the CGA
887 address is not predictable, a reverse record can only reasonably be
888 inserted in the DNS by the node that generates the address.
889
890 7.4. DDNS with DHCP
891
892 With DHCPv4, the reverse DNS name is typically already inserted to
893 the DNS that reflects the name (e.g., "dhcp-67.example.com"). One
894 can assume similar practice may become commonplace with DHCPv6 as
895 well; all such mappings would be pre-configured and would require no
896 updating.
897
898 If a more explicit control is required, similar considerations as
899 with SLAAC apply, except for the fact that typically one must update
900 a reverse DNS record instead of inserting one (if an address
901 assignment policy that reassigns disused addresses is adopted) and
902 updating a record seems like a slightly more difficult thing to
903 secure. However, it is yet uncertain how DHCPv6 is going to be used
904 for address assignment.
905
906 Note that when using DHCP, either the host or the DHCP server could
907 perform the DNS updates; see the implications in Section 6.2.
908
909 If disused addresses were to be reassigned, host-based DDNS reverse
910 updates would need policy considerations for DNS record modification,
911 as noted above. On the other hand, if disused address were not to be
912 assigned, host-based DNS reverse updates would have similar
913 considerations as SLAAC in Section 7.3. Server-based updates have
914 similar properties except that the janitorial process could be
915 integrated with DHCP address assignment.
916
917 7.5. DDNS with Dynamic Prefix Delegation
918
919 In cases where a prefix, instead of an address, is being used and
920 updated, one should consider what is the location of the server where
921 DDNS updates are made. That is, where the DNS server is located:
922
923 1. At the same organization as the prefix delegator.
924
925 2. At the site where the prefixes are delegated to. In this case,
926 the authority of the DNS reverse zone corresponding to the
927 delegated prefix is also delegated to the site.
928
929
930
931
932 Durand, et al. Informational [Page 17]
933 RFC 4472 Considerations with IPv6 DNS April 2006
934
935
936 3. Elsewhere; this implies a relationship between the site and where
937 the DNS server is located, and such a relationship should be
938 rather straightforward to secure as well. Like in the previous
939 case, the authority of the DNS reverse zone is also delegated.
940
941 In the first case, managing the reverse DNS (delegation) is simpler
942 as the DNS server and the prefix delegator are in the same
943 administrative domain (as there is no need to delegate anything at
944 all); alternatively, the prefix delegator might forgo DDNS reverse
945 capability altogether, and use, e.g., wildcard records (as described
946 in Section 7.2). In the other cases, it can be slightly more
947 difficult, particularly as the site will have to configure the DNS
948 server to be authoritative for the delegated reverse zone, implying
949 automatic configuration of the DNS server -- as the prefix may be
950 dynamic.
951
952 Managing the DDNS reverse updates is typically simple in the second
953 case, as the updated server is located at the local site, and
954 arguably IP address-based authentication could be sufficient (or if
955 not, setting up security relationships would be simpler). As there
956 is an explicit (security) relationship between the parties in the
957 third case, setting up the security relationships to allow reverse
958 DDNS updates should be rather straightforward as well (but IP
959 address-based authentication might not be acceptable). In the first
960 case, however, setting up and managing such relationships might be a
961 lot more difficult.
962
963 8. Miscellaneous DNS Considerations
964
965 This section describes miscellaneous considerations about DNS that
966 seem related to IPv6, for which no better place has been found in
967 this document.
968
969 8.1. NAT-PT with DNS-ALG
970
971 The DNS-ALG component of NAT-PT [RFC2766] mangles A records to look
972 like AAAA records to the IPv6-only nodes. Numerous problems have
973 been identified with [WIP-AD2005]. This is a strong reason not to
974 use NAT-PT in the first place.
975
976 8.2. Renumbering Procedures and Applications' Use of DNS
977
978 One of the most difficult problems of systematic IP address
979 renumbering procedures [RFC4192] is that an application that looks up
980 a DNS name disregards information such as TTL, and uses the result
981 obtained from DNS as long as it happens to be stored in the memory of
982 the application. For applications that run for a long time, this
983
984
985
986
987 Durand, et al. Informational [Page 18]
988 RFC 4472 Considerations with IPv6 DNS April 2006
989
990
991 could be days, weeks, or even months. Some applications may be
992 clever enough to organize the data structures and functions in such a
993 manner that lookups get refreshed now and then.
994
995 While the issue appears to have a clear solution, "fix the
996 applications", practically, this is not reasonable immediate advice.
997 The TTL information is not typically available in the APIs and
998 libraries (so, the advice becomes "fix the applications, APIs, and
999 libraries"), and a lot more analysis is needed on how to practically
1000 go about to achieve the ultimate goal of avoiding using the names
1001 longer than expected.
1002
1003 9. Acknowledgements
1004
1005 Some recommendations (Section 4.3, Section 5.1) about IPv6 service
1006 provisioning were moved here from [RFC4213] by Erik Nordmark and Bob
1007 Gilligan. Havard Eidnes and Michael Patton provided useful feedback
1008 and improvements. Scott Rose, Rob Austein, Masataka Ohta, and Mark
1009 Andrews helped in clarifying the issues regarding additional data and
1010 the use of TTL. Jefsey Morfin, Ralph Droms, Peter Koch, Jinmei
1011 Tatuya, Iljitsch van Beijnum, Edward Lewis, and Rob Austein provided
1012 useful feedback during the WG last call. Thomas Narten provided
1013 extensive feedback during the IESG evaluation.
1014
1015 10. Security Considerations
1016
1017 This document reviews the operational procedures for IPv6 DNS
1018 operations and does not have security considerations in itself.
1019
1020 However, it is worth noting that in particular with Dynamic DNS
1021 updates, security models based on the source address validation are
1022 very weak and cannot be recommended -- they could only be considered
1023 in the environments where ingress filtering [RFC3704] has been
1024 deployed. On the other hand, it should be noted that setting up an
1025 authorization mechanism (e.g., a shared secret, or public-private
1026 keys) between a node and the DNS server has to be done manually, and
1027 may require quite a bit of time and expertise.
1028
1029 To re-emphasize what was already stated, the reverse+forward DNS
1030 check provides very weak security at best, and the only
1031 (questionable) security-related use for them may be in conjunction
1032 with other mechanisms when authenticating a user.
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042 Durand, et al. Informational [Page 19]
1043 RFC 4472 Considerations with IPv6 DNS April 2006
1044
1045
1046 11. References
1047
1048 11.1. Normative References
1049
1050 [RFC1034] Mockapetris, P., "Domain names - concepts and
1051 facilities", STD 13, RFC 1034, November 1987.
1052
1053 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
1054 "Dynamic Updates in the Domain Name System (DNS
1055 UPDATE)", RFC 2136, April 1997.
1056
1057 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
1058 Specification", RFC 2181, July 1997.
1059
1060 [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton,
1061 "Selection and Operation of Secondary DNS Servers",
1062 BCP 16, RFC 2182, July 1997.
1063
1064 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
1065 Autoconfiguration", RFC 2462, December 1998.
1066
1067 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
1068 RFC 2671, August 1999.
1069
1070 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
1071 April 2001.
1072
1073 [RFC3007] Wellington, B., "Secure Domain Name System (DNS)
1074 Dynamic Update", RFC 3007, November 2000.
1075
1076 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
1077 Stateless Address Autoconfiguration in IPv6", RFC 3041,
1078 January 2001.
1079
1080 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
1081 via IPv4 Clouds", RFC 3056, February 2001.
1082
1083 [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
1084 August 2001.
1085
1086 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
1087 and M. Carney, "Dynamic Host Configuration Protocol for
1088 IPv6 (DHCPv6)", RFC 3315, July 2003.
1089
1090 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
1091 Hain, "Representing Internet Protocol version 6 (IPv6)
1092 Addresses in the Domain Name System (DNS)", RFC 3363,
1093 August 2002.
1094
1095
1096
1097 Durand, et al. Informational [Page 20]
1098 RFC 4472 Considerations with IPv6 DNS April 2006
1099
1100
1101 [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS)
1102 Support for Internet Protocol version 6 (IPv6)",
1103 RFC 3364, August 2002.
1104
1105 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
1106 "DNS Extensions to Support IP Version 6", RFC 3596,
1107 October 2003.
1108
1109 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
1110 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
1111 December 2003.
1112
1113 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration
1114 Protocol (DHCP) Service for IPv6", RFC 3736,
1115 April 2004.
1116
1117 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local
1118 Addresses", RFC 3879, September 2004.
1119
1120 [RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport
1121 Operational Guidelines", BCP 91, RFC 3901,
1122 September 2004.
1123
1124 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
1125 Castro, "Application Aspects of IPv6 Transition",
1126 RFC 4038, March 2005.
1127
1128 [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior
1129 Against DNS Queries for IPv6 Addresses", RFC 4074,
1130 May 2005.
1131
1132 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
1133 Renumbering an IPv6 Network without a Flag Day",
1134 RFC 4192, September 2005.
1135
1136 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
1137 Addresses", RFC 4193, October 2005.
1138
1139 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
1140 Architecture", RFC 4291, February 2006.
1141
1142 [RFC4339] Jeong, J., Ed., "IPv6 Host Configuration of DNS Server
1143 Information Approaches", RFC 4339, February 2006.
1144
1145
1146
1147
1148
1149
1150
1151
1152 Durand, et al. Informational [Page 21]
1153 RFC 4472 Considerations with IPv6 DNS April 2006
1154
1155
1156 11.2. Informative References
1157
1158 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
1159 Translation - Protocol Translation (NAT-PT)", RFC 2766,
1160 February 2000.
1161
1162 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR
1163 for specifying the location of services (DNS SRV)",
1164 RFC 2782, February 2000.
1165
1166 [RFC2826] Internet Architecture Board, "IAB Technical Comment on
1167 the Unique DNS Root", RFC 2826, May 2000.
1168
1169 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
1170 Multihomed Networks", BCP 84, RFC 3704, March 2004.
1171
1172 [RFC3972] Aura, T., "Cryptographically Generated Addresses
1173 (CGA)", RFC 3972, March 2005.
1174
1175 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying
1176 Material in DNS", RFC 4025, March 2005.
1177
1178 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition
1179 Mechanisms for IPv6 Hosts and Routers", RFC 4213,
1180 October 2005.
1181
1182 [RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third
1183 Generation Partnership Project (3GPP) Networks",
1184 RFC 4215, October 2005.
1185
1186 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
1187 Network Address Translations (NATs)", RFC 4380,
1188 February 2006.
1189
1190 [TC-TEST] Jinmei, T., "Thread "RFC2181 section 9.1: TC bit
1191 handling and additional data" on DNSEXT mailing list,
1192 Message-
1193 Id:y7vek9j9hyo.wl%jinmei@isl.rdc.toshiba.co.jp", August
1194 1, 2005, <http://ops.ietf.org/lists/namedroppers/
1195 namedroppers.2005/msg01102.html>.
1196
1197 [WIP-AD2005] Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
1198 Experimental", Work in Progress, October 2005.
1199
1200 [WIP-DC2005] Durand, A. and T. Chown, "To publish, or not to
1201 publish, that is the question", Work in Progress,
1202 October 2005.
1203
1204
1205
1206
1207 Durand, et al. Informational [Page 22]
1208 RFC 4472 Considerations with IPv6 DNS April 2006
1209
1210
1211 [WIP-H2005] Huston, G., "6to4 Reverse DNS Delegation
1212 Specification", Work in Progress, November 2005.
1213
1214 [WIP-J2006] Jeong, J., "IPv6 Router Advertisement Option for DNS
1215 Configuration", Work in Progress, January 2006.
1216
1217 [WIP-LB2005] Larson, M. and P. Barber, "Observed DNS Resolution
1218 Misbehavior", Work in Progress, February 2006.
1219
1220 [WIP-O2004] Ohta, M., "Preconfigured DNS Server Addresses", Work in
1221 Progress, February 2004.
1222
1223 [WIP-R2006] Roy, S., "IPv6 Neighbor Discovery On-Link Assumption
1224 Considered Harmful", Work in Progress, January 2006.
1225
1226 [WIP-RDP2004] Roy, S., Durand, A., and J. Paugh, "Issues with Dual
1227 Stack IPv6 on by Default", Work in Progress, July 2004.
1228
1229 [WIP-S2005a] Stapp, M., "The DHCP Client FQDN Option", Work in
1230 Progress, March 2006.
1231
1232 [WIP-S2005b] Stapp, M., "A DNS RR for Encoding DHCP Information
1233 (DHCID RR)", Work in Progress, March 2006.
1234
1235 [WIP-S2005c] Senie, D., "Encouraging the use of DNS IN-ADDR
1236 Mapping", Work in Progress, August 2005.
1237
1238 [WIP-SV2005] Stapp, M. and B. Volz, "Resolution of FQDN Conflicts
1239 among DHCP Clients", Work in Progress, March 2006.
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262 Durand, et al. Informational [Page 23]
1263 RFC 4472 Considerations with IPv6 DNS April 2006
1264
1265
1266 Appendix A. Unique Local Addressing Considerations for DNS
1267
1268 Unique local addresses [RFC4193] have replaced the now-deprecated
1269 site-local addresses [RFC3879]. From the perspective of the DNS, the
1270 locally generated unique local addresses (LUL) and site-local
1271 addresses have similar properties.
1272
1273 The interactions with DNS come in two flavors: forward and reverse
1274 DNS.
1275
1276 To actually use local addresses within a site, this implies the
1277 deployment of a "split-faced" or a fragmented DNS name space, for the
1278 zones internal to the site, and the outsiders' view to it. The
1279 procedures to achieve this are not elaborated here. The implication
1280 is that local addresses must not be published in the public DNS.
1281
1282 To facilitate reverse DNS (if desired) with local addresses, the stub
1283 resolvers must look for DNS information from the local DNS servers,
1284 not, e.g., starting from the root servers, so that the local
1285 information may be provided locally. Note that the experience of
1286 private addresses in IPv4 has shown that the root servers get loaded
1287 for requests for private address lookups in any case. This
1288 requirement is discussed in [RFC4193].
1289
1290 Appendix B. Behavior of Additional Data in IPv4/IPv6 Environments
1291
1292 DNS responses do not always fit in a single UDP packet. We'll
1293 examine the cases that happen when this is due to too much data in
1294 the Additional section.
1295
1296 B.1. Description of Additional Data Scenarios
1297
1298 There are two kinds of additional data:
1299
1300 1. "critical" additional data; this must be included in all
1301 scenarios, with all the RRsets, and
1302
1303 2. "courtesy" additional data; this could be sent in full, with only
1304 a few RRsets, or with no RRsets, and can be fetched separately as
1305 well, but at the cost of additional queries.
1306
1307 The responding server can algorithmically determine which type the
1308 additional data is by checking whether it's at or below a zone cut.
1309
1310 Only those additional data records (even if sometimes carelessly
1311 termed "glue") are considered "critical" or real "glue" if and only
1312 if they meet the above-mentioned condition, as specified in Section
1313 4.2.1 of [RFC1034].
1314
1315
1316
1317 Durand, et al. Informational [Page 24]
1318 RFC 4472 Considerations with IPv6 DNS April 2006
1319
1320
1321 Remember that resource record sets (RRsets) are never "broken up", so
1322 if a name has 4 A records and 5 AAAA records, you can either return
1323 all 9, all 4 A records, all 5 AAAA records, or nothing. In
1324 particular, notice that for the "critical" additional data getting
1325 all the RRsets can be critical.
1326
1327 In particular, [RFC2181] specifies (in Section 9) that:
1328
1329 a. if all the "critical" RRsets do not fit, the sender should set
1330 the TC bit, and the recipient should discard the whole response
1331 and retry using mechanism allowing larger responses such as TCP.
1332
1333 b. "courtesy" additional data should not cause the setting of the TC
1334 bit, but instead all the non-fitting additional data RRsets
1335 should be removed.
1336
1337 An example of the "courtesy" additional data is A/AAAA records in
1338 conjunction with MX records as shown in Section 4.4; an example of
1339 the "critical" additional data is shown below (where getting both the
1340 A and AAAA RRsets is critical with respect to the NS RR):
1341
1342 child.example.com. IN NS ns.child.example.com.
1343 ns.child.example.com. IN A 192.0.2.1
1344 ns.child.example.com. IN AAAA 2001:db8::1
1345
1346 When there is too much "courtesy" additional data, at least the non-
1347 fitting RRsets should be removed [RFC2181]; however, as the
1348 additional data is not critical, even all of it could be safely
1349 removed.
1350
1351 When there is too much "critical" additional data, TC bit will have
1352 to be set, and the recipient should ignore the response and retry
1353 using TCP; if some data were to be left in the UDP response, the
1354 issue is which data could be retained.
1355
1356 However, the practice may differ from the specification. Testing and
1357 code analysis of three recent implementations [TC-TEST] confirm this.
1358 None of the tested implementations have a strict separation of
1359 critical and courtesy additional data, while some forms of additional
1360 data may be treated preferably. All the implementations remove some
1361 (critical or courtesy) additional data RRsets without setting the TC
1362 bit if the response would not otherwise fit.
1363
1364 Failing to discard the response with the TC bit or omitting critical
1365 information but not setting the TC bit lead to an unrecoverable
1366 problem. Omitting only some of the RRsets if all would not fit (but
1367 not setting the TC bit) leads to a performance problem. These are
1368 discussed in the next two subsections.
1369
1370
1371
1372 Durand, et al. Informational [Page 25]
1373 RFC 4472 Considerations with IPv6 DNS April 2006
1374
1375
1376 B.2. Which Additional Data to Keep, If Any?
1377
1378 NOTE: omitting some critical additional data instead of setting the
1379 TC bit violates a 'should' in Section 9 of RFC2181. However, as many
1380 implementations still do that [TC-TEST], operators need to understand
1381 its implications, and we describe that behavior as well.
1382
1383 If the implementation decides to keep as much data (whether
1384 "critical" or "courtesy") as possible in the UDP responses, it might
1385 be tempting to use the transport of the DNS query as a hint in either
1386 of these cases: return the AAAA records if the query was done over
1387 IPv6, or return the A records if the query was done over IPv4.
1388 However, this breaks the model of independence of DNS transport and
1389 resource records, as noted in Section 1.2.
1390
1391 With courtesy additional data, as long as enough RRsets will be
1392 removed so that TC will not be set, it is allowed to send as many
1393 complete RRsets as the implementations prefers. However, the
1394 implementations are also free to omit all such RRsets, even if
1395 complete. Omitting all the RRsets (when removing only some would
1396 suffice) may create a performance penalty, whereby the client may
1397 need to issue one or more additional queries to obtain necessary
1398 and/or consistent information.
1399
1400 With critical additional data, the alternatives are either returning
1401 nothing (and absolutely requiring a retry with TCP) or returning
1402 something (working also in the case if the recipient does not discard
1403 the response and retry using TCP) in addition to setting the TC bit.
1404 If the process for selecting "something" from the critical data would
1405 otherwise be practically "flipping the coin" between A and AAAA
1406 records, it could be argued that if one looked at the transport of
1407 the query, it would have a larger possibility of being right than
1408 just 50/50. In other words, if the returned critical additional data
1409 would have to be selected somehow, using something more sophisticated
1410 than a random process would seem justifiable.
1411
1412 That is, leaving in some intelligently selected critical additional
1413 data is a trade-off between creating an optimization for those
1414 resolvers that ignore the "should discard" recommendation and causing
1415 a protocol problem by propagating inconsistent information about
1416 "critical" records in the caches.
1417
1418 Similarly, leaving in the complete courtesy additional data RRsets
1419 instead of removing all the RRsets is a performance trade-off as
1420 described in the next section.
1421
1422
1423
1424
1425
1426
1427 Durand, et al. Informational [Page 26]
1428 RFC 4472 Considerations with IPv6 DNS April 2006
1429
1430
1431 B.3. Discussion of the Potential Problems
1432
1433 As noted above, the temptation for omitting only some of the
1434 additional data could be problematic. This is discussed more below.
1435
1436 For courtesy additional data, this causes a potential performance
1437 problem as this requires that the clients issue re-queries for the
1438 potentially omitted RRsets. For critical additional data, this
1439 causes a potential unrecoverable problem if the response is not
1440 discarded and the query not re-tried with TCP, as the nameservers
1441 might be reachable only through the omitted RRsets.
1442
1443 If an implementation would look at the transport used for the query,
1444 it is worth remembering that often the host using the records is
1445 different from the node requesting them from the authoritative DNS
1446 server (or even a caching resolver). So, whichever version the
1447 requestor (e.g., a recursive server in the middle) uses makes no
1448 difference to the ultimate user of the records, whose transport
1449 capabilities might differ from those of the requestor. This might
1450 result in, e.g., inappropriately returning A records to an IPv6-only
1451 node, going through a translation, or opening up another IP-level
1452 session (e.g., a Packet Data Protocol (PDP) context [RFC4215]).
1453 Therefore, at least in many scenarios, it would be very useful if the
1454 information returned would be consistent and complete -- or if that
1455 is not feasible, leave it to the client to query again.
1456
1457 The problem of too much additional data seems to be an operational
1458 one: the zone administrator entering too many records that will be
1459 returned truncated (or missing some RRsets, depending on
1460 implementations) to the users. A protocol fix for this is using
1461 Extension Mechanisms for DNS (EDNS0) [RFC2671] to signal the capacity
1462 for larger UDP packet sizes, pushing up the relevant threshold.
1463 Further, DNS server implementations should omit courtesy additional
1464 data completely rather than including only some RRsets [RFC2181]. An
1465 operational fix for this is having the DNS server implementations
1466 return a warning when the administrators create zones that would
1467 result in too much additional data being returned. Further, DNS
1468 server implementations should warn of or disallow such zone
1469 configurations that are recursive or otherwise difficult to manage by
1470 the protocol.
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482 Durand, et al. Informational [Page 27]
1483 RFC 4472 Considerations with IPv6 DNS April 2006
1484
1485
1486 Authors' Addresses
1487
1488 Alain Durand
1489 Comcast
1490 1500 Market St.
1491 Philadelphia, PA 19102
1492 USA
1493
1494 EMail: Alain_Durand@cable.comcast.com
1495
1496
1497 Johan Ihren
1498 Autonomica
1499 Bellmansgatan 30
1500 SE-118 47 Stockholm
1501 Sweden
1502
1503 EMail: johani@autonomica.se
1504
1505
1506 Pekka Savola
1507 CSC/FUNET
1508 Espoo
1509 Finland
1510
1511 EMail: psavola@funet.fi
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537 Durand, et al. Informational [Page 28]
1538 RFC 4472 Considerations with IPv6 DNS April 2006
1539
1540
1541 Full Copyright Statement
1542
1543 Copyright (C) The Internet Society (2006).
1544
1545 This document is subject to the rights, licenses and restrictions
1546 contained in BCP 78, and except as set forth therein, the authors
1547 retain all their rights.
1548
1549 This document and the information contained herein are provided on an
1550 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1551 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1552 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1553 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1554 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1555 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1556
1557 Intellectual Property
1558
1559 The IETF takes no position regarding the validity or scope of any
1560 Intellectual Property Rights or other rights that might be claimed to
1561 pertain to the implementation or use of the technology described in
1562 this document or the extent to which any license under such rights
1563 might or might not be available; nor does it represent that it has
1564 made any independent effort to identify any such rights. Information
1565 on the procedures with respect to rights in RFC documents can be
1566 found in BCP 78 and BCP 79.
1567
1568 Copies of IPR disclosures made to the IETF Secretariat and any
1569 assurances of licenses to be made available, or the result of an
1570 attempt made to obtain a general license or permission for the use of
1571 such proprietary rights by implementers or users of this
1572 specification can be obtained from the IETF on-line IPR repository at
1573 http://www.ietf.org/ipr.
1574
1575 The IETF invites any interested party to bring to its attention any
1576 copyrights, patents or patent applications, or other proprietary
1577 rights that may cover technology that may be required to implement
1578 this standard. Please address the information to the IETF at
1579 ietf-ipr@ietf.org.
1580
1581 Acknowledgement
1582
1583 Funding for the RFC Editor function is provided by the IETF
1584 Administrative Support Activity (IASA).
1585
1586
1587
1588
1589
1590
1591
1592 Durand, et al. Informational [Page 29]
1593
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.