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

bind 9.3结合mysql数据库

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



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
   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




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



   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
   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 to the reverse DNS, as justified and described in
   [I-D.ietf-ipseckey-rr].


   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




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



   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, 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.  (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
   with the owner of that address space -- so, assuming stronger form of
   authorization for reverse DNS updates than an address association is
   generally unfeasible.




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



   Moreover, the reverse zones must be cleaned up by an unspecified
   janitorial process: the node does not typically know a priori that it
   will be disconnected, and cannot send a DNS update using the correct
   source address to remove a record.


   A problem with defining the clean-up process is that it is difficult
   to ensure that a specific IP address and the corresponding record are
   no longer being used.  Considering the huge address space, and the
   unlikelihood of collision within 64 bits of the interface
   identifiers, a process which would remove the record after no traffic
   has been seen from a node in a long period of time (e.g., a month or
   year) might be one possible approach.


   To insert or update the record, the node must discover the DNS server
   to send the update to somehow, similar to as discussed in Section
   6.2.  One way to automate this is looking up the DNS server
   authoritative (e.g., through SOA record) for the IP address being
   updated, but the security material (unless the IP address-based
   authorization is trusted) must also be established by some other
   means.


   One should note that Cryptographically Generated Addresses
   [I-D.ietf-send-cga] (CGAs) may require a slightly different kind of
   treatment.  CGAs are addresses where the interface identifier is
   calculated from a public key, a modifier (used as a nonce), the
   subnet prefix, and other data.  Depending on the usage profile, CGAs
   might or might not be changed periodically due to e.g., privacy
   reasons.  As the CGA address is not predicatable, a reverse record
   can only reasonably be inserted in the DNS by the node which
   generates the address.


7.4  DDNS with DHCP


   With DHCPv4, the reverse DNS name is typically already inserted to
   the DNS that reflects to the name (e.g., "dhcp-67.example.com").  One
   can assume similar practice may become commonplace with DHCPv6 as
   well; all such mappings would be pre-configured, and would require no
   updating.


   If a more explicit control is required, similar considerations as
   with SLAAC apply, except for the fact that typically one must update
   a reverse DNS record instead of inserting one (if an address
   assignment policy that reassigns disused addresses is adopted) and
   updating a record seems like a slightly more difficult thing to
   secure.  However, it is yet uncertain how DHCPv6 is going to be used
   for address assignment.


   Note that when using DHCP, either the host or the DHCP server could




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



   perform the DNS updates; see the implications in Section 6.2.


   If disused addresses were to be reassigned, host-based DDNS reverse
   updates would need policy considerations for DNS record modification,
   as noted above.  On the other hand, if disused address were not to be
   assigned, host-based DNS reverse updates would have similar
   considerations as SLAAC in Section 7.3.  Server-based updates have
   similar properties except that the janitorial process could be
   integrated with DHCP address assignment.


7.5  DDNS with Dynamic Prefix Delegation


   In cases where a prefix, instead of an address, is being used and
   updated, one should consider what is the location of the server where
   DDNS updates are made.  That is, where the DNS server is located:


   1.  At the same organization as the prefix delegator.


   2.  At the site where the prefixes are delegated to.  In this case,
       the authority of the DNS reverse zone corresponding to the
       delegated prefix is also delegated to the site.


   3.  Elsewhere; this implies a relationship between the site and where
       DNS server is located, and such a relationship should be rather
       straightforward to secure as well.  Like in the previous case,
       the authority of the DNS reverse zone is also delegated.


   In the first case, managing the reverse DNS (delegation) is simpler
   as the DNS server and the prefix delegator are in the same
   administrative domain (as there is no need to delegate anything at
   all); alternatively, the prefix delegator might forgo DDNS reverse
   capability altogether, and use e.g., wildcard records (as described
   in Section 7.2).  In the other cases, it can be slighly more
   difficult, particularly as the site will have to configure the DNS
   server to be authoritative for the delegated reverse zone, implying
   automatic configuration of the DNS server -- as the prefix may be
   dynamic.


   Managing the DDNS reverse updates is typically simple in the second
   case, as the updated server is located at the local site, and
   arguably IP address-based authentication could be sufficient (or if
   not, setting up security relationships would be simpler).  As there
   is an explicit (security) relationship between the parties in the
   third case, setting up the security relationships to allow reverse
   DDNS updates should be rather straightforward as well (but IP
   address-based authentication might not be acceptable).  In the first
   case, however, setting up and managing such relationships might be a
   lot more difficult.




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



8.  Miscellaneous DNS Considerations


   This section describes miscellaneous considerations about DNS which
   seem related to IPv6, for which no better place has been found in
   this document.


8.1  NAT-PT with DNS-ALG


   The DNS-ALG component of NAT-PT mangles A records  to look like AAAA
   records to the IPv6-only nodes.  Numerous problems have been
   identified with DNS-ALG [I-D.durand-v6ops-natpt-dns-alg-issues].
   This is a strong reason not to use NAT-PT in the first place.