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

非常好的dns解析软件

   [I-D.huitema-v6ops-teredo]
              Huitema, C., "Teredo: Tunneling IPv6 over UDP through
              NATs", draft-huitema-v6ops-teredo-05 (work in progress),
              April 2005.

   [I-D.huston-6to4-reverse-dns]
              Huston, G., "6to4 Reverse DNS Delegation",



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


              draft-huston-6to4-reverse-dns-03 (work in progress),
              October 2004.

   [I-D.ietf-dhc-ddns-resolution]
              Stapp, M. and B. Volz, "Resolution of FQDN Conflicts among
              DHCP Clients", draft-ietf-dhc-ddns-resolution-09 (work in
              progress), June 2005.

   [I-D.ietf-dhc-fqdn-option]
              Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option",
              draft-ietf-dhc-fqdn-option-10 (work in progress),
              February 2005.

   [I-D.ietf-dnsext-dhcid-rr]
              Stapp, M., Lemon, T., and A. Gustafsson, "A DNS RR for
              encoding DHCP information (DHCID RR)",
              draft-ietf-dnsext-dhcid-rr-09 (work in progress),
              February 2005.

   [I-D.ietf-dnsop-bad-dns-res]
              Larson, M. and P. Barber, "Observed DNS Resolution
              Misbehavior", draft-ietf-dnsop-bad-dns-res-03 (work in
              progress), October 2004.

   [I-D.ietf-dnsop-inaddr-required]
              Senie, D., "Encouraging the use of DNS IN-ADDR Mapping",
              draft-ietf-dnsop-inaddr-required-06 (work in progress),
              February 2005.

   [I-D.ietf-v6ops-3gpp-analysis]
              Wiljakka, J., "Analysis on IPv6 Transition in 3GPP
              Networks", draft-ietf-v6ops-3gpp-analysis-11 (work in
              progress), October 2004.

   [I-D.ietf-v6ops-mech-v2]
              Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
              for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-07
              (work in progress), March 2005.

   [I-D.ietf-v6ops-natpt-to-exprmntl]
              Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
              Experimental", draft-ietf-v6ops-natpt-to-exprmntl-01 (work
              in progress), July 2005.

   [I-D.ietf-v6ops-onlinkassumption]
              Roy, S., "IPv6 Neighbor Discovery On-Link Assumption
              Considered Harmful", draft-ietf-v6ops-onlinkassumption-03
              (work in progress), May 2005.



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


   [I-D.ietf-v6ops-v6onbydefault]
              Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack
              IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03
              (work in progress), July 2004.

   [I-D.jeong-dnsop-ipv6-dns-discovery]
              Jeong, J., "IPv6 DNS Configuration based on Router
              Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-04
              (work in progress), February 2005.

   [I-D.ohta-preconfigured-dns]
              Ohta, M., "Preconfigured DNS Server Addresses",
              draft-ohta-preconfigured-dns-01 (work in progress),
              February 2004.

   [RFC2766]  Tsirtsis, G. and P. Srisuresh, "Network Address
              Translation - Protocol Translation (NAT-PT)", RFC 2766,
              February 2000.

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [RFC2826]  Internet Architecture Board, "IAB Technical Comment on the
              Unique DNS Root", RFC 2826, May 2000.

   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, March 2004.

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, March 2005.

   [RFC4025]  Richardson, M., "A Method for Storing IPsec Keying
              Material in DNS", RFC 4025, March 2005.


Authors' Addresses

   Alain Durand
   SUN Microsystems, Inc.
   17 Network circle UMPL17-202
   Menlo Park, CA  94025
   USA

   Email: [e-mail]






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


   Johan Ihren
   Autonomica
   Bellmansgatan 30
   SE-118 47 Stockholm
   Sweden

   Email: [e-mail]


   Pekka Savola
   CSC/FUNET
   Espoo
   Finland

   Email: [e-mail]

Appendix A.  Unique Local Addressing Considerations for DNS

   Unique local addresses [I-D.ietf-ipv6-unique-local-addr] have
   replaced the now-deprecated site-local addresses [RFC3879].  From the
   perspective of the DNS, the locally generated unique local addresses
   (LUL) and site-local addresses have similar properties.

   The interactions with DNS come in two flavors: forward and reverse
   DNS.

   To actually use local addresses within a site, this implies the
   deployment of a "split-faced" or a fragmented DNS name space, for the
   zones internal to the site, and the outsiders' view to it.  The
   procedures to achieve this are not elaborated here.  The implication
   is that local addresses must not be published in the public DNS.

   To faciliate reverse DNS (if desired) with local addresses, the stub
   resolvers must look for DNS information from the local DNS servers,
   not e.g. starting from the root servers, so that the local
   information may be provided locally.  Note that the experience of
   private addresses in IPv4 has shown that the root servers get loaded
   for requests for private address lookups in any case.  This
   requirement is discussed in [I-D.ietf-ipv6-unique-local-addr].

Appendix B.  Behaviour of Additional Data in IPv4/IPv6 Environments

   DNS responses do not always fit in a single UDP packet.  We'll
   examine the cases which happen when this is due to too much data in
   the Additional Section.






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


B.1  Description of Additional Data Scenarios

   There are two kinds of additional data:

   1.  "critical" additional data; this must be included in all
       scenarios, with all the RRsets, 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.

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

   Only those additional data records (even if sometimes carelessly
   termed "glue") are considered "critical" or real "glue" if and only
   if they meet the abovementioned condition, as specified in Section
   4.2.1 of [RFC1034].

   Remember that 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.

   In particular, [RFC2181] specifies (in Section 9) that:

   a.  if all the "critical" RRsets do not fit, the sender should set
       the TC bit, and the recipient should discard the whole response
       and retry using mechanism allowing larger responses such as TCP.

   b.  "courtesy" additional data should not cause the setting of TC
       bit, but instead all the non-fitting additional data RRsets
       should be removed.

   An example of the "courtesy" additional data is A/AAAA records in
   conjunction with MX records as shown in Section 4.4; an example of
   the "critical" additional data is shown below (where getting both the
   A and AAAA RRsets is critical w.r.t. to the NS RR):

      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, at least the non-
   fitting RRsets should be removed [RFC2181]; however, as the
   additional data is not critical, even all of it could be safely
   removed.



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


   When there is too much "critical" additional data, TC bit will have
   to be set, and the recipient should ignore the response and retry
   using TCP; if some data were to be left in the UDP response, the
   issue is which data could be retained.

   Failing to discard the response with TC bit or omitting critical
   information but not setting TC bit lead to an unrecoverable problem.
   Omitting only some of the RRsets if all would not fit (but not
   setting TC bit) leads to a performance problem.  These are discussed
   in the next two subsections.

B.2  Which Additional Data to Keep, If Any?

   If the implementation decides to keep as much data (whether
   "critical" or "courtesy") as possible in the UDP responses, 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.

   With courtesy additional data, as long as enough RRsets will be
   removed so that TC will not be set, it is allowed to send as many
   complete RRsets as the implementations prefers.  However, the
   implementations are also free to omit all such RRsets, even if
   complete.  Omitting all the RRsets (when removing only some would
   suffice) may create a performance penalty, whereby the client may
   need to issue one or more additional queries to obtain necessary
   and/or consistent information.

   With critical additional data, the alternatives are either returning
   nothing (and absolutely requiring a retry with TCP) or returning
   something (working also in the case if the recipient does not discard
   the response and retry using TCP) in addition to setting the TC bit.
   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.

   That is, leaving in some intelligently selected critical additional
   data is a tradeoff between creating an optimization for those
   resolvers which ignore the "should discard" recommendation, and
   causing a protocol problem by propagating inconsistent information
   about "critical" records in the caches.




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


   Similarly, leaving in the complete courtesy additional data RRsets
   instead of removing all the RRsets is a performance tradeoff as
   described in the next section.

B.3  Discussion of the Potential Problems

   As noted above, the temptation for omitting only