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

bind 9.3结合mysql数据库

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
   [I-D.moore-6to4-dns], some more applicable than the others.


   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, above, 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.  This is why only
   6to4 and Teredo [I-D.huitema-v6ops-teredo] are described.


   Note that it does not seem feasible to provide reverse DNS with




Durand, et al.          Expires February 7, 2005                [Page 6]
Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004



   another automatic tunneling mechanism, 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 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
   [I-D.ietf-dnsop-misbehavior-against-aaaa]: 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.





Durand, et al.          Expires February 7, 2005                [Page 7]
Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004



4.  Recommendations for Service Provisioning using DNS


   When names are added in the DNS to facilitate a service, there are
   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


   When a node provides multiple services which should not be
   fate-sharing, or might support different IP versions, one should keep
   them logically separate in the DNS.  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 should 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.)


   This is a good practice with IPv4 as well, because it provides more
   flexibility and enables easier migration of services from one host to
   another.  A specific reason why this is relevant for IPv6 is that the
   different services may have a different level of IPv6 support -- that
   is, one node providing multiple services might want to enable just
   one service to be IPv6-visible while keeping some others as
   IPv4-only, improving flexibility.


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 be either added to "service.example.com", or added
   separately under a different name, e.g., in a sub-domain, like,
   "service.ipv6.example.com".


   These two methods have different characteristics.  Using a different




Durand, et al.          Expires February 7, 2005                [Page 8]
Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004



   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
   if the service offered using both protocols is of roughly equal
   quality, using the appropriate metrics for the service (e.g.,
   latency, throughput, low packet loss, general reliability, etc.) --




Durand, et al.          Expires February 7, 2005                [Page 9]
Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004



   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
   [I-D.savola-v6ops-6bone-mess].


4.4  Behaviour of Additional Data in IPv4/IPv6 Environments


4.4.1  Description of Additional Data Scenarios


   Consider the case where the query name is so long, the number of the
   additional records is so high, or for other reasons that the entire
   response would not fit in a single UDP packet.  In some cases, the
   responder truncates the response with the TC bit being set (leading
   to a retry with TCP), in order for the querier to get the entire
   response later.


   There are two kinds of additional data:


   1.  glue, i.e., "critical" additional data; this must be included in
       all scenarios, with all the RRsets as possible, and


   2.  "courtesy" additional data; this could be sent in full, with only
       a few RRsets, or with no RRsets, and can be fetched separately as
       well, but at the cost of additional queries.  This data must
       never cause setting of the TC bit.


   The responding server can algorithmically determine which type the
   additional data is by checking whether it's at or below a zone cut.


   Meanwhile, resource record sets (RRsets) are never "broken up", so if
   a name has 4 A records and 5 AAAA records, you can either return all
   9, all 4 A records, all 5 AAAA records or nothing.  In particular,
   notice that for the "critical" additional data getting all the RRsets
   can be critical.


   An example of the "courtesy" additional data is A/AAAA records in
   conjunction of MX records as shown in Section 4.5; an example of the
   "critical" additional data is shown below (where getting both the A
   and AAAA RRsets is critical):


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


   When there is too much courtesy additional data, some or all of it
   need to be removed [RFC2181]; if some is left in the response, the
   issue is which data should be retained.  When there is too much




Durand, et al.          Expires February 7, 2005               [Page 10]
Internet-Draft    Considerations and Issues with IPv6 DNS    August 2004



   critical additional data, TC bit will have to be set, and some or all
   of it need to be removed; if some is left in the response, the issue
   is which data should be retained.


   If the implementation decides to keep as much data as possible, it
   might be tempting to use the transport of the DNS query as a hint in
   either of these cases: return the AAAA records if the query was done
   over IPv6, or return the A records if the query was done over IPv4.
   However, this breaks the model of independence of DNS transport and
   resource records, as noted in Section 1.2.


   It is worth remembering that often the host using the records is
   different from the node requesting them from the authoritative DNS
   server (or even a caching resolver).  So, whichever version the
   requestor (e.g., a recursive server in the middle) uses makes no
   difference to the ultimate user of the records, whose transport
   capabilities might differ from those of the requestor.  This might
   result in e.g., inappropriately returning A records to an IPv6-only
   node, going through a translation, or opening up another IP-level
   session (e.g., a PDP context [I-D.ietf-v6ops-3gpp-analysis]).
   Therefore, at least in many scenarios, it would be very useful if the
   information returned would be consistent and complete -- or if that
   is not feasible, return no misleading information but rather leave it
   to the client to query again.


4.4.2  Discussion of the Problems


   As noted above, the temptation for omitting only some of the
   additional data based on the transport of the query could be
   problematic.  In particular, there appears to be little justification
   for doing so in the case of "courtesy" data.