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

非常好的dns解析软件

   with the owner of that address space -- so, assuming stronger form of
   authorization for reverse DNS updates than an address association is
   generally infeasible.

   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 [RFC3972]
   (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.



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


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



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


   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.

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.ietf-v6ops-natpt-to-exprmntl].  This is
   a strong reason not to use NAT-PT in the first place.

8.2  Renumbering Procedures and Applications' Use of DNS

   One of the most difficult problems of systematic IP address
   renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that
   an application which looks up a DNS name disregards information such
   as TTL, and uses the result obtained from DNS as long as it happens
   to be stored in the memory of the application.  For applications
   which run for a long time, this could be days, weeks or even months;
   some applications may be clever enough to organize the data
   structures and functions in such a manner that look-ups get refreshed
   now and then.

   While the issue appears to have a clear solution, "fix the
   applications", practically this is not reasonable immediate advice;
   the TTL information is not typically available in the APIs and
   libraries (so, the advice becomes "fix the applications, APIs and
   libraries"), and a lot more analysis is needed on how to practically



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


   go about to achieve the ultimate goal of avoiding using the names
   longer than expected.

9.  Acknowledgements

   Some recommendations (Section 4.3, Section 5.1) about IPv6 service
   provisioning were moved here from [I-D.ietf-v6ops-mech-v2] by Erik
   Nordmark and Bob Gilligan.  Havard Eidnes and Michael Patton provided
   useful feedback and improvements.  Scott Rose, Rob Austein, Masataka
   Ohta, and Mark Andrews helped in clarifying the issues regarding
   additional data and the use of TTL.  Jefsey Morfin, Ralph Droms,
   Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and
   Rob Austein provided useful feedback during the WG last call.  Thomas
   Narten provided extensive feedback during the IESG evaluation.

10.  Security Considerations

   This document reviews the operational procedures for IPv6 DNS
   operations and does not have security considerations in itself.

   However, it is worth noting that in particular with Dynamic DNS
   Updates, security models based on the source address validation are
   very weak and cannot be recommended -- they could only be considered
   in the environments where ingress filtering [RFC3704] has been
   deployed.  On the other hand, it should be noted that setting up an
   authorization mechanism (e.g., a shared secret, or public-private
   keys) between a node and the DNS server has to be done manually, and
   may require quite a bit of time and expertise.

   To re-emphasize what was already stated, the reverse+forward DNS
   check provides very weak security at best, and the only
   (questionable) security-related use for them may be in conjunction
   with other mechanisms when authenticating a user.

11.  References

11.1  Normative References

   [I-D.ietf-dnsop-ipv6-dns-configuration]
              Jeong, J., "IPv6 Host Configuration of DNS Server
              Information Approaches",
              draft-ietf-dnsop-ipv6-dns-configuration-06 (work in
              progress), May 2005.

   [I-D.ietf-ipv6-unique-local-addr]
              Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in
              progress), January 2005.



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


   [I-D.ietf-v6ops-renumbering-procedure]
              Baker, F., "Procedures for Renumbering an IPv6 Network
              without a Flag Day",
              draft-ietf-v6ops-renumbering-procedure-05 (work in
              progress), March 2005.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, April 1997.

   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, July 1997.

   [RFC2182]  Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
              and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
              July 1997.

   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998.

   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
              RFC 2671, August 1999.

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
              Update", RFC 3007, November 2000.

   [RFC3041]  Narten, T. and R. Draves, "Privacy Extensions for
              Stateless Address Autoconfiguration in IPv6", RFC 3041,
              January 2001.

   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

   [RFC3152]  Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
              August 2001.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3363]  Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
              Hain, "Representing Internet Protocol version 6 (IPv6)



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


              Addresses in the Domain Name System (DNS)", RFC 3363,
              August 2002.

   [RFC3364]  Austein, R., "Tradeoffs in Domain Name System (DNS)
              Support for Internet Protocol version 6 (IPv6)", RFC 3364,
              August 2002.

   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
              (IPv6) Addressing Architecture", RFC 3513, April 2003.

   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
              "DNS Extensions to Support IP Version 6", RFC 3596,
              October 2003.

   [RFC3646]  Droms, R., "DNS Configuration options for Dynamic Host
              Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
              December 2003.

   [RFC3736]  Droms, R., "Stateless Dynamic Host Configuration Protocol
              (DHCP) Service for IPv6", RFC 3736, April 2004.

   [RFC3879]  Huitema, C. and B. Carpenter, "Deprecating Site Local
              Addresses", RFC 3879, September 2004.

   [RFC3901]  Durand, A. and J. Ihren, "DNS IPv6 Transport Operational
              Guidelines", BCP 91, RFC 3901, September 2004.

   [RFC4038]  Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
              Castro, "Application Aspects of IPv6 Transition",
              RFC 4038, March 2005.

   [RFC4074]  Morishita, Y. and T. Jinmei, "Common Misbehavior Against
              DNS Queries for IPv6 Addresses", RFC 4074, May 2005.

11.2  Informative References

   [I-D.durand-dnsop-dont-publish]
              Durand, A. and T. Chown, "To publish, or not to publish,
              that is the question.", draft-durand-dnsop-dont-publish-00
              (work in progress), February 2005.