draft-ietf-dnsop-ipv6-dns-issues-11.txt

非常好的dns解析软件

2.3  6to4 Addresses

   6to4 [RFC3056] specifies an automatic tunneling mechanism which maps
   a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48.

   If the reverse DNS population would be desirable (see Section 7.1 for
   applicability), there are a number of possible ways to do so.

   The main proposal [I-D.huston-6to4-reverse-dns] aims to design an
   autonomous reverse-delegation system that anyone being capable of
   communicating using a specific 6to4 address would be able to set up a
   reverse delegation to the corresponding 6to4 prefix.  This could be
   deployed by e.g., Regional Internet Registries (RIRs).  This is a
   practical solution, but may have some scalability concerns.

2.4  Other Transition Mechanisms

   6to4 is mentioned as a case of an IPv6 transition mechanism requiring
   special considerations.  In general, mechanisms which include a
   special prefix may need a custom solution; otherwise, for example
   when IPv4 address is embedded as the suffix or not embedded at all,
   special solutions are likely not needed.

   Note that it does not seem feasible to provide reverse DNS with
   another automatic tunneling mechanism, Teredo [I-D.huitema-v6ops-
   teredo]; this is because the IPv6 address is based on the IPv4
   address and UDP port of the current NAT mapping which is likely to be



Durand, et al.          Expires January 17, 2006                [Page 6]

Internet-Draft        Considerations with IPv6 DNS             July 2005


   relatively short-lived.

3.  Observed DNS Implementation Misbehaviour

   Several classes of misbehaviour in DNS servers, load-balancers and
   resolvers have been observed.  Most of these are rather generic, not
   only applicable to IPv6 -- but in some cases, the consequences of
   this misbehaviour are extremely severe in IPv6 environments and
   deserve to be mentioned.

3.1  Misbehaviour of DNS Servers and Load-balancers

   There are several classes of misbehaviour in certain DNS servers and
   load-balancers which have been noticed and documented [RFC4074]: some
   implementations silently drop queries for unimplemented DNS records
   types, or provide wrong answers to such queries (instead of a proper
   negative reply).  While typically these issues are not limited to
   AAAA records, the problems are aggravated by the fact that AAAA
   records are being queried instead of (mainly) A records.

   The problems are serious because when looking up a DNS name, typical
   getaddrinfo() implementations, with AF_UNSPEC hint given, first try
   to query the AAAA records of the name, and after receiving a
   response, query the A records.  This is done in a serial fashion --
   if the first query is never responded to (instead of properly
   returning a negative answer), significant timeouts will occur.

   In consequence, this is an enormous problem for IPv6 deployments, and
   in some cases, IPv6 support in the software has even been disabled
   due to these problems.

   The solution is to fix or retire those misbehaving implementations,
   but that is likely not going to be effective.  There are some
   possible ways to mitigate the problem, e.g., by performing the
   lookups somewhat in parallel and reducing the timeout as long as at
   least one answer has been received; but such methods remain to be
   investigated; slightly more on this is included in Section 5.

3.2  Misbehaviour of DNS Resolvers

   Several classes of misbehaviour have also been noticed in DNS
   resolvers [I-D.ietf-dnsop-bad-dns-res].  However, these do not seem
   to directly impair IPv6 use, and are only referred to for
   completeness.

4.  Recommendations for Service Provisioning using DNS

   When names are added in the DNS to facilitate a service, there are



Durand, et al.          Expires January 17, 2006                [Page 7]

Internet-Draft        Considerations with IPv6 DNS             July 2005


   several general guidelines to consider to be able to do it as
   smoothly as possible.

4.1  Use of Service Names instead of Node Names

   It makes sense to keep information about separate services logically
   separate in the DNS by using a different DNS hostname for each
   service.  There are several reasons for doing this, for example:

   o  It allows more flexibility and ease for migration of (only a part
      of) services from one node to another,

   o  It allows configuring different properties (e.g., TTL) for each
      service, and

   o  It allows deciding separately for each service whether to publish
      the IPv6 addresses or not (in cases where some services are more
      IPv6-ready than others).

   Using SRV records [RFC2782] would avoid these problems.
   Unfortunately, those are not sufficiently widely used to be
   applicable in most cases.  Hence an operation technique is to use
   service names instead of node names (or, "hostnames").  This
   operational technique is not specific to IPv6, but required to
   understand the considerations described in Section 4.2 and
   Section 4.3.

   For example, assume a node named "pobox.example.com" provides both
   SMTP and IMAP service.  Instead of configuring the MX records to
   point at "pobox.example.com", and configuring the mail clients to
   look up the mail via IMAP from "pobox.example.com", one could use
   e.g., "smtp.example.com" for SMTP (for both message submission and
   mail relaying between SMTP servers) and "imap.example.com" for IMAP.
   Note that in the specific case of SMTP relaying, the server itself
   must typically also be configured to know all its names to ensure
   loops do not occur.  DNS can provide a layer of indirection between
   service names and where the service actually is, and using which
   addresses.  (Obviously, when wanting to reach a specific node, one
   should use the hostname rather than a service name.)

4.2  Separate vs the Same Service Names for IPv4 and IPv6

   The service naming can be achieved in basically two ways: when a
   service is named "service.example.com" for IPv4, the IPv6-enabled
   service could either be added to "service.example.com", or added
   separately under a different name, e.g., in a sub-domain, like,
   "service.ipv6.example.com".




Durand, et al.          Expires January 17, 2006                [Page 8]

Internet-Draft        Considerations with IPv6 DNS             July 2005


   These two methods have different characteristics.  Using a different
   name allows for easier service piloting, minimizing the disturbance
   to the "regular" users of IPv4 service; however, the service would
   not be used transparently, without the user/application explicitly
   finding it and asking for it -- which would be a disadvantage in most
   cases.  When the different name is under a sub-domain, if the
   services are deployed within a restricted network (e.g., inside an
   enterprise), it's possible to prefer them transparently, at least to
   a degree, by modifying the DNS search path; however, this is a
   suboptimal solution.  Using the same service name is the "long-term"
   solution, but may degrade performance for those clients whose IPv6
   performance is lower than IPv4, or does not work as well (see
   Section 4.3 for more).

   In most cases, it makes sense to pilot or test a service using
   separate service names, and move to the use of the same name when
   confident enough that the service level will not degrade for the
   users unaware of IPv6.

4.3  Adding the Records Only when Fully IPv6-enabled

   The recommendation is that AAAA records for a service should not be
   added to the DNS until all of following are true:

   1.  The address is assigned to the interface on the node.

   2.  The address is configured on the interface.

   3.  The interface is on a link which is connected to the IPv6
       infrastructure.

   In addition, if the AAAA record is added for the node, instead of
   service as recommended, all the services of the node should be IPv6-
   enabled prior to adding the resource record.

   For example, if an IPv6 node is isolated from an IPv6 perspective
   (e.g., it is not connected to IPv6 Internet) constraint #3 would mean
   that it should not have an address in the DNS.

   Consider the case of two dual-stack nodes, which both have IPv6
   enabled, but the server does not have (global) IPv6 connectivity.  As
   the client looks up the server's name, only A records are returned
   (if the recommendations above are followed), and no IPv6
   communication, which would have been unsuccessful, is even attempted.

   The issues are not always so black-and-white.  Usually it's important
   that the service offered using both protocols is of roughly equal
   quality, using the appropriate metrics for the service (e.g.,



Durand, et al.          Expires January 17, 2006                [Page 9]

Internet-Draft        Considerations with IPv6 DNS             July 2005


   latency, throughput, low packet loss, general reliability, etc.) --
   this is typically very important especially for interactive or real-
   time services.  In many cases, the quality of IPv6 connectivity may
   not yet be equal to that of IPv4, at least globally -- this has to be
   taken into consideration when enabling services.

4.4  The Use of TTL for IPv4 and IPv6 RRs

   The behaviour of DNS caching when different TTL values are used for
   different RRsets of the same name calls for explicit discussion.  For
   example, let's consider two unrelated zone fragments:

      example.com.        300    IN    MX     foo.example.com.
      foo.example.com.    300    IN    A      192.0.2.1
      foo.example.com.    100    IN    AAAA   2001:db8::1

   ...

      child.example.com.    300  IN    NS     ns.child.example.com.
      ns.child.example.com. 300  IN    A      192.0.2.1
      ns.child.example.com. 100  IN    AAAA   2001:db8::1

   In the former case, we have "courtesy" additional data; in the
   latter, we have "critical" additional data.  See more extensive
   background discussion of additional data handling in Appendix B.

4.4.1  TTL With Courtesy Additional Data

   When a caching resolver asks for the MX record of example.com, it
   gets back "foo.example.com".  It may also get back either one or both
   of the A and AAAA records in the additional section.  The resolver
   must explicitly query for both A and AAAA records [RFC2821].

   After 100 seconds, the AAAA record is removed from the cache(s)
   because its TTL expired.  It could be argued to be useful for the
   caching resolvers to discard the A record when the shorter TTL (in
   this case, for the AAAA record) expires; this would avoid the
   situation where there would be a window of 200 seconds when
   incomplete information is returned from the cache.  Further argument
   for discarding is that in the normal operation, the TTL values are so
   high that very likely the incurred additional queries would not be
   noticeable, compared to the obtained performance optimization.  The
   behaviour in this scenario is unspecified.

4.4.2  TTL With Critical Additional Data

   The difference to courtesy additional data is that the A/AAAA records
   served by the parent zone cannot be queried explicitly.  Therefore



Durand, et al.          Expires January 17, 2006               [Page 10]

Internet-Draft        Considerations with IPv6 DNS             July 2005


   after 100 seconds the AAAA record is removed from the cache(s), but
   the A record remains.  Queries for the remaining 200 seconds
   (provided that there are no further queries from the parent which
   could refresh the caches) only return the A record, leading to a
   potential opererational situation with unreachable servers.

   Similar cache flushing strategies apply in this scenario; the record.

4.5  IPv6 Transport Guidelines for DNS Servers

   As described in Section 1.3 and [RFC3901], there should continue to
   be at least one authoritative IPv4 DNS server for every zone, even if
   the zone has only IPv6 records.  (Note that obviously, having more
   servers with robust connectivity would be preferable, but this is the
   minimum recommendation; also see [RFC2182].)

5.  Recommendations for DNS Resolver IPv6 Support

   When IPv6 is enabled on a node, there are several things to consider
   to ensure that the process is as smooth as possible.

5.1  DNS Lookups May Query IPv6 Records Prematurely

   The system library that implements the getaddrinfo() function for
   looking up names is a critical piece when considering the robustness
   of enabling IPv6; it may come in basically three flavours:

   1.  The system library does not know whether IPv6 has been enabled in
       the kernel of the operating system: it may start looking up AAAA
       records with getaddrinfo() and AF_UNSPEC hint when the system is
       upgraded to a system library version which supports IPv6.

   2.  The system library might start to perform IPv6 queries with
       getaddrinfo() only when IPv6 has been enabled in the kernel.
       However, this does not guarantee that there exists any useful
       IPv6 connectivity (e.g., the node could be isolated from the
       other IPv6 networks, only having link-local addresses).

   3.  The system library might implement a toggle which would apply
       some heuristics to the "IPv6-readiness" of the node before
       starting to perform queries; for example, it could check whether
       only link-local IPv6 address(es) exists, or if at least one
       global IPv6 address exists.

   First, let us consider generic implications of unnecessary queries
   for AAAA records: when looking up all the records in the DNS, AAAA