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

非常好的dns解析软件

   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



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


   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
   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 [RFC4038].

   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



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


   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
   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 [RFC3901], 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 of 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



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


   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.

6.2  Dynamic DNS

   Dynamic DNS updates (DDNS) [RFC2136] [RFC3007] is a standardized
   mechanism for dynamically updating the DNS.  It works equally well
   with stateless address autoconfiguration (SLAAC), DHCPv6 or manual
   address configuration.  It is important to consider how each of these
   behave if IP address-based authentication, instead of stronger
   mechanisms [RFC3007], was used in the updates.

   1.  manual addresses are static and can be configured

   2.  DHCPv6 addresses could be reasonably static or dynamic, depending
       on the deployment, and could or could not be configured on the
       DNS server for the long term

   3.  SLAAC addresses are typically stable for a long time, but could
       require work to be configured and maintained.

   As relying on IP addresses for Dynamic DNS is rather insecure at
   best, stronger authentication should always be used; however, this
   requires that the authorization keying will be explicitly configured
   using unspecified operational methods.

   Note that with DHCP it is also possible that the DHCP server updates
   the DNS, not the host.  The host might only indicate in the DHCP
   exchange which hostname it would prefer, and the DHCP server would
   make the appropriate updates.  Nonetheless, while this makes setting
   up a secure channel between the updater and the DNS server easier, it
   does not help much with "content" security, i.e., whether the
   hostname was acceptable -- if the DNS server does not include
   policies, they must be included in the DHCP server (e.g., a regular



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


   host should not be able to state that its name is "www.example.com").
   DHCP-initiated DDNS updates have been extensively described in
   [I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and
   [I-D.ietf-dnsext-dhcid-rr].

   The nodes must somehow be configured with the information about the
   servers where they will attempt to update their addresses, sufficient
   security material for authenticating themselves to the server, and
   the hostname they will be updating.  Unless otherwise configured, the
   first could be obtained by looking up the authoritative name servers
   for the hostname; the second must be configured explicitly unless one
   chooses to trust the IP address-based authentication (not a good
   idea); and lastly, the nodename is typically pre-configured somehow
   on the node, e.g., at install time.

   Care should be observed when updating the addresses not to use longer
   TTLs for addresses than are preferred lifetimes for the addresses, so
   that if the node is renumbered in a managed fashion, the amount of
   stale DNS information is kept to the minimum.  That is, if the
   preferred lifetime of an address expires, the TTL of the record needs
   be modified unless it was already done before the expiration.  For
   better flexibility, the DNS TTL should be much shorter (e.g., a half
   or a third) than the lifetime of an address; that way, the node can
   start lowering the DNS TTL if it seems like the address has not been
   renewed/refreshed in a while.  Some discussion on how an
   administrator could manage the DNS TTL is included in [I-D.ietf-
   v6ops-renumbering-procedure]; this could be applied to (smart) hosts
   as well.

7.  Considerations about Reverse DNS Updating

   Updating the reverse DNS zone may be difficult because of the split
   authority over an address.  However, first we have to consider the
   applicability of reverse DNS in the first place.

7.1  Applicability of Reverse DNS

   Today, some applications use reverse DNS to either look up some hints
   about the topological information associated with an address (e.g.
   resolving web server access logs), or as a weak form of a security
   check, to get a feel whether the user's network administrator has
   "authorized" the use of the address (on the premises that adding a
   reverse record for an address would signal some form of
   authorization).

   One additional, maybe slightly more useful usage is ensuring that the
   reverse and forward DNS contents match (by looking up the pointer to
   the name by the IP address from the reverse tree, and ensuring that a



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


   record under the name in the forward tree points to the IP address)
   and correspond to a configured name or domain.  As a security check,
   it is typically accompanied by other mechanisms, such as a user/
   password login; the main purpose of the reverse+forward DNS check is
   to weed out the majority of unauthorized users, and if someone
   managed to bypass the checks, he would still need to authenticate
   "properly".

   It may also be desirable to store IPsec keying material corresponding
   to an IP address in the reverse DNS, as justified and described in
   [RFC4025].

   It is not clear whether it makes sense to require or recommend that
   reverse DNS records be updated.  In many cases, it would just make
   more sense to use proper mechanisms for security (or topological
   information lookup) in the first place.  At minimum, the applications
   which use it as a generic authorization (in the sense that a record
   exists at all) should be modified as soon as possible to avoid such
   lookups completely.

   The applicability is discussed at more length in [I-D.ietf-dnsop-
   inaddr-required].

7.2  Manual or Custom DNS Updates

   Reverse DNS can of course be updated using manual or custom methods.
   These are not further described here, except for one special case.

   One way to deploy reverse DNS would be to use wildcard records, for
   example, by configuring one name for a subnet (/64) or a site (/48).
   As a concrete example, a site (or the site's ISP) could configure the
   reverses of the prefix 2001:db8:f00::/48 to point to one name using a
   wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa.  IN PTR
   site.example.com."  Naturally, such a name could not be verified from
   the forward DNS, but would at least provide some form of "topological
   information" or "weak authorization" if that is really considered to
   be useful.  Note that this is not actually updating the DNS as such,
   as the whole point is to avoid DNS updates completely by manually
   configuring a generic name.

7.3  DDNS with Stateless Address Autoconfiguration

   Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in
   some regard, while being more difficult in another, as described
   below.

   The address space administrator decides whether the hosts are trusted
   to update their reverse DNS records or not.  If they are trusted and



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


   deployed at the same site (e.g., not across the Internet), a simple
   address-based authorization is typically sufficient (i.e., check that
   the DNS update is done from the same IP address as the record being
   updated); stronger security can also be used [RFC3007].  If they
   aren't allowed to update the reverses, no update can occur.  However,
   such address-based update authorization operationally requires that
   ingress filtering [RFC3704] has been set up at the border of the site
   where the updates occur, and as close to the updater as possible.

   Address-based authorization is simpler with reverse DNS (as there is
   a connection between the record and the address) than with forward
   DNS.  However, when a stronger form of security is used, forward DNS
   updates are simpler to manage because the host can be assumed to have
   an association with the domain.  Note that the user may roam to
   different networks, and does not necessarily have any association