[RFC4339] Jeong, J., Ed., "IPv6 Host Configuration of DNS Server
Information Approaches", RFC 4339, February 2006.
11.2. Informative References
[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.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition
Mechanisms for IPv6 Hosts and Routers", RFC 4213,
October 2005.
[RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third
Generation Partnership Project (3GPP) Networks",
RFC 4215, October 2005.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
February 2006.
[TC-TEST] Jinmei, T., "Thread "RFC2181 section 9.1: TC bit
handling and additional data" on DNSEXT mailing list,
Message-
Id:y7vek9j9hyo.wl%jinmei@isl.rdc.toshiba.co.jp", August
1, 2005, <http://ops.ietf.org/lists/namedroppers/
namedroppers.2005/msg01102.html>.
[WIP-AD2005] Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
Experimental", Work in Progress, October 2005.
[WIP-DC2005] Durand, A. and T. Chown, "To publish, or not to
publish, that is the question", Work in Progress,
October 2005.
[WIP-H2005] Huston, G., "6to4 Reverse DNS Delegation
Specification", Work in Progress, November 2005.
[WIP-J2006] Jeong, J., "IPv6 Router Advertisement Option for DNS
Configuration", Work in Progress, January 2006.
[WIP-LB2005] Larson, M. and P. Barber, "Observed DNS Resolution
Misbehavior", Work in Progress, February 2006.
[WIP-O2004] Ohta, M., "Preconfigured DNS Server Addresses", Work in
Progress, February 2004.
[WIP-R2006] Roy, S., "IPv6 Neighbor Discovery On-Link Assumption
Considered Harmful", Work in Progress, January 2006.
[WIP-RDP2004] Roy, S., Durand, A., and J. Paugh, "Issues with Dual
Stack IPv6 on by Default", Work in Progress, July 2004.
[WIP-S2005a] Stapp, M., "The DHCP Client FQDN Option", Work in
Progress, March 2006.
[WIP-S2005b] Stapp, M., "A DNS RR for Encoding DHCP Information
(DHCID RR)", Work in Progress, March 2006.
[WIP-S2005c] Senie, D., "Encouraging the use of DNS IN-ADDR
Mapping", Work in Progress, August 2005.
[WIP-SV2005] Stapp, M. and B. Volz, "Resolution of FQDN Conflicts
among DHCP Clients", Work in Progress, March 2006.
Appendix A. Unique Local Addressing Considerations for DNS
Unique local addresses [RFC4193] 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 facilitate 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 [RFC4193].
Appendix B. Behavior of Additional Data in IPv4/IPv6 Environments
DNS responses do not always fit in a single UDP packet. We’ll
examine the cases that happen when this is due to too much data in
the Additional section.
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 above-mentioned 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 the 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 with respect 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.
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.
However, the practice may differ from the specification. Testing and
code analysis of three recent implementations [TC-TEST] confirm this.
None of the tested implementations have a strict separation of
critical and courtesy additional data, while some forms of additional
data may be treated preferably. All the implementations remove some
(critical or courtesy) additional data RRsets without setting the TC
bit if the response would not otherwise fit.
Failing to discard the response with the TC bit or omitting critical
information but not setting the TC bit lead to an unrecoverable
problem. Omitting only some of the RRsets if all would not fit (but
not setting the TC bit) leads to a performance problem. These are
discussed in the next two subsections.
B.2. Which Additional Data to Keep, If Any?
NOTE: omitting some critical additional data instead of setting the
TC bit violates a ’should’ in Section 9 of RFC2181. However, as many
implementations still do that [TC-TEST], operators need to understand
its implications, and we describe that behavior as well.
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 trade-off between creating an optimization for those
resolvers that ignore the "should discard" recommendation and causing
a protocol problem by propagating inconsistent information about
"critical" records in the caches.
Similarly, leaving in the complete courtesy additional data RRsets
instead of removing all the RRsets is a performance trade-off as
described in the next section.
B.3. Discussion of the Potential Problems
As noted above, the temptation for omitting only some of the
additional data could be problematic. This is discussed more below.
For courtesy additional data, this causes a potential performance
problem as this requires that the clients issue re-queries for the
potentially omitted RRsets. For critical additional data, this
causes a potential unrecoverable problem if the response is not
discarded and the query not re-tried with TCP, as the nameservers
might be reachable only through the omitted RRsets.
If an implementation would look at the transport used for the query,
it is worth remembering that often the host using the records is
different from the node requesting them from the authoritative DNS
server (or even a caching resolver). So, whichever version the
requestor (e.g., a recursive server in the middle) uses makes no
difference to the ultimate user of the records, whose transport
capabilities might differ from those of the requestor. This might
result in, e.g., inappropriately returning A records to an IPv6-only
node, going through a translation, or opening up another IP-level
session (e.g., a Packet Data Protocol (PDP) context [RFC4215]).
Therefore, at least in many scenarios, it would be very useful if the
information returned would be consistent and complete -- or if that
is not feasible, leave it to the client to query again.
The problem of too much additional data seems to be an operational
one: the zone administrator entering too many records that will be
returned truncated (or missing some RRsets, depending on
implementations) to the users. A protocol fix for this is using
Extension Mechanisms for DNS (EDNS0) [RFC2671] to signal the capacity
for larger UDP packet sizes, pushing up the relevant threshold.
Further, DNS server implementations should 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 that would
result in too much additional data being returned. Further, DNS
server implementations should warn of or disallow such zone
configurations that are recursive or otherwise difficult to manage by
the protocol.
Authors’ Addresses
Alain Durand
Comcast
1500 Market St.
Philadelphia, PA 19102
USA
EMail: Alain_Durand@cable.comcast.com
Johan Ihren
Autonomica
Bellmansgatan 30
SE-118 47 Stockholm
Sweden
EMail: johani@autonomica.se
Pekka Savola
CSC/FUNET
Espoo
Finland
EMail: psavola@funet.fi
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).