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

bind 9.3结合mysql数据库

   However, with critical additional data, the alternatives are either
   returning nothing (and requiring a retry with TCP) or returning
   something (possibly obviating the need for a retry with TCP).  If the
   process for selecting "something" from the critical data would
   otherwise be practically "flipping the coin" between A and AAAA
   records, it could be argued that if one looked at the transport of
   the query, it would have a larger possibility of being right than
   just 50/50.  In other words, if the returned critical additional data
   would have to be selected somehow, using something more sophisticated
   than a random process would seem justifiable.


   The problem of too much additional data seems to be an operational
   one: the zone administrator entering too many records which will be
   returned either truncated or missing some RRsets to the users.  A
   protocol fix for this is using EDNS0 [RFC2671] to signal the capacity
   for larger UDP packet sizes, pushing up the relevant threshold.




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



   Further, DNS server implementations should rather omit courtesy
   additional data completely rather than including only some RRsets
   [RFC2181].  An operational fix for this is having the DNS server
   implementations return a warning when the administrators create zones
   which would result in too much additional data being returned.
   Further, DNS server implementations should warn of or disallow such
   zone configurations which are recursive or otherwise difficult to
   manage by the protocol.


   Additionally, to avoid the case where an application would not get an
   address at all due to some of "courtesy" additional data being
   omitted, the resolvers should be able to query the specific records
   of the desired protocol, not just rely on getting all the required
   RRsets in the additional section.


4.5  The Use of TTL for IPv4 and IPv6 RRs


   In the previous section, we discussed a danger with queries,
   potentially leading to omitting RRsets from the additional section;
   this could happen to both critical and "courtesy" additional data.
   This section discusses another problem with the latter, leading to
   omitting RRsets in cached data, highlighted in the IPv4/IPv6
   environment.


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


      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


   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.  So, there are
   three cases about returning records for the MX in the additional
   section:


   1.  We get back no A or AAAA RRsets: this is the simplest case,
       because then we have to query which information is required
       explicitly, guaranteeing that we get all the information we're
       interested in.


   2.  We get back all the RRsets: this is an optimization as there is
       no need to perform more queries, causing lower latency.  However,
       it is impossible to guarantee that in fact we would always get
       back all the records (the only way to ensure that is to send a
       AAAA query for the name after getting the cached reply with A




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



       records or vice versa).


   3.  We only get back A or AAAA RRsets even if both existed: this is
       indistinguishable from the previous case, and may have problems
       at least in certain environments as described in the previous
       section.


   As the third case was considered in the previous section, we assume
   we get back both A and AAAA records of foo.example.com, or the stub
   resolver explicitly asks, in two separate queries, both A and AAAA
   records.


   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.  The behaviour in
   this scenario is unspecified.


   To simplify the situation, it might help to use the same TTL for all
   the resource record sets referring to the same name, unless there is
   a particular reason for not doing so.  However, there are some
   scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where
   a different strategy is preferable.


   Thus, applications that use the response should not rely on a
   particular TTL configuration.  For example, even if an application
   gets a response that only has the A record in the example described
   above, it should be still aware that there could be a AAAA record for
   "foo.example.com".  That is, the application should try to fetch the
   missing records itself if it needs the record.


4.6  IPv6 Transport Guidelines for DNS Servers


   As described in Section 1.3 and
   [I-D.ietf-dnsop-ipv6-transport-guidelines], 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.






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



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
   records are typically tried first, and then A records.  These are
   done in serial, and the A query is not performed until a response is
   received to the AAAA query.  Considering the misbehaviour of DNS
   servers and load-balancers, as described in Section 3.1, the look-up
   delay for AAAA may incur additional unnecessary latency, and
   introduce a component of unreliability.


   One option here could be to do the queries partially in parallel; for
   example, if the final response to the AAAA query is not received in
   0.5 seconds, start performing the A query while waiting for the
   result (immediate parallelism might be unoptimal, at least without
   information sharing between the look-up threads, as that would
   probably lead to duplicate non-cached delegation chain lookups).


   An additional concern is the address selection, which may, in some
   circumstances, prefer AAAA records over A records even when the node
   does not have any IPv6 connectivity [I-D.ietf-v6ops-v6onbydefault].
   In some cases, the implementation may attempt to connect or send a
   datagram on a physical link [I-D.ietf-v6ops-onlinkassumption],
   incurring very long protocol timeouts, instead of quickly failing
   back to IPv4.


   Now, we can consider the issues specific to each of the three




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



   possibilities:


   In the first case, the node performs a number of completely useless
   DNS lookups as it will not be able to use the returned AAAA records
   anyway.  (The only exception is where the application desires to know
   what's in the DNS, but not use the result for communication.)  One
   should be able to disable these unnecessary queries, for both latency
   and reliability reasons.  However, as IPv6 has not been enabled, the
   connections to IPv6 addresses fail immediately, and if the
   application is programmed properly, the application can fall
   gracefully back to IPv4 [I-D.ietf-v6ops-application-transition].


   The second case is similar to the first, except it happens to a
   smaller set of nodes when IPv6 has been enabled but connectivity has
   not been provided yet; similar considerations apply, with the
   exception that IPv6 records, when returned, will be actually tried
   first which may typically lead to long timeouts.


   The third case is a bit more complex: optimizing away the DNS lookups
   with only link-locals is probably safe (but may be desirable with
   different lookup services which getaddrinfo() may support), as the
   link-locals are typically automatically generated when IPv6 is
   enabled, and do not indicate any form of IPv6 connectivity.  That is,
   performing DNS lookups only when a non-link-local address has been
   configured on any interface could be beneficial -- this would be an
   indication that either the address has been configured either from a
   router advertisement, DHCPv6 [RFC3315], or manually.  Each would
   indicate at least some form of IPv6 connectivity, even though there
   would not be guarantees of it.


   These issues should be analyzed at more depth, and the fixes found
   consensus on, perhaps in a separate document.


5.2  Obtaining a List of DNS Recursive Resolvers


   In scenarios where DHCPv6 is available, a host can discover a list of
   DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server"
   option [RFC3646].  This option can be passed to a host through a
   subset of DHCPv6 [RFC3736].


   The IETF is considering the development of alternative mechanisms for
   obtaining the list of DNS recursive name servers when DHCPv6 is
   unavailable or inappropriate.  No decision about taking on this
   development work has been reached as of this writing (Aug 2004)
   [I-D.ietf-dnsop-ipv6-dns-configuration].


   In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms
   under consideration for development include the use of well-known




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



   addresses [I-D.ohta-preconfigured-dns] and the use of Router
   Advertisements to convey the information
   [I-D.jeong-dnsop-ipv6-dns-discovery].


   Note that even though IPv6 DNS resolver discovery is a recommended
   procedure, it is not required for dual-stack nodes in dual-stack
   networks as IPv6 DNS records can be queried over IPv4 as well as
   IPv6.  Obviously, nodes which are meant to function without manual
   configuration in IPv6-only networks must implement the DNS resolver
   discovery function.


5.3  IPv6 Transport Guidelines for Resolvers


   As described in Section 1.3 and
   [I-D.ietf-dnsop-ipv6-transport-guidelines], the recursive resolvers
   should be IPv4-only or dual-stack to be able to reach any IPv4-only
   DNS server.  Note that this requirement is also fulfilled by an
   IPv6-only stub resolver pointing to a dual-stack recursive DNS
   resolver.


6.  Considerations about Forward DNS Updating


   While the topic how to enable updating the forward DNS, i.e., the
   mapping from names to the correct new addresses, is not specific to
   IPv6, it should be considered especially due to the advent of
   Stateless Address Autoconfiguration [RFC2462].


   Typically forward DNS updates are more manageable than doing them in
   the reverse DNS, because the updater can often be assumed to "own" a
   certain DNS name -- and we can create a form of security relationship
   with the DNS name and the node which is allowed to update it to point
   to a new address.


   A more complex form of DNS updates -- adding a whole new name into a
   DNS zone, instead of updating an existing name -- is considered out
   of scope for this memo as it could require zone-wide authentication.
   Adding a new name in the forward zone is a problem which is still
   being explored with IPv4, and IPv6 does not seem to add much new in
   that area.


6.1  Manual or Custom DNS Updates


   The DNS mappings can also be maintained by hand, in a semi-automatic
   fashion or by running non-standardized protocols.  These are not
   considered at more length in this memo.