< draft-ietf-dnsop-ipv6-dns-issues-11.txt   draft-ietf-dnsop-ipv6-dns-issues-12.txt >
DNS Operations WG A. Durand DNS Operations WG A. Durand
Internet-Draft SUN Microsystems, Inc. Internet-Draft Comcast
Expires: January 17, 2006 J. Ihren Expires: April 22, 2006 J. Ihren
Autonomica Autonomica
P. Savola P. Savola
CSC/FUNET CSC/FUNET
July 16, 2005 October 19, 2005
Operational Considerations and Issues with IPv6 DNS Operational Considerations and Issues with IPv6 DNS
draft-ietf-dnsop-ipv6-dns-issues-11.txt draft-ietf-dnsop-ipv6-dns-issues-12.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 17, 2006. This Internet-Draft will expire on April 22, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This memo presents operational considerations and issues with IPv6 This memo presents operational considerations and issues with IPv6
Domain Name System (DNS), including a summary of special IPv6 Domain Name System (DNS), including a summary of special IPv6
addresses, documentation of known DNS implementation misbehaviour, addresses, documentation of known DNS implementation misbehaviour,
recommendations and considerations on how to perform DNS naming for recommendations and considerations on how to perform DNS naming for
service provisioning and for DNS resolver IPv6 support, service provisioning and for DNS resolver IPv6 support,
considerations for DNS updates for both the forward and reverse considerations for DNS updates for both the forward and reverse
trees, and miscellaneous issues. This memo is aimed to include a trees, and miscellaneous issues. This memo is aimed to include a
summary of information about IPv6 DNS considerations for those who summary of information about IPv6 DNS considerations for those who
have experience with IPv4 DNS. have experience with IPv4 DNS.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . 4 1.1. Representing IPv6 Addresses in DNS Records . . . . . . . . 4
1.2 Independence of DNS Transport and DNS Records . . . . . . 4 1.2. Independence of DNS Transport and DNS Records . . . . . . 4
1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . 5 1.3. Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . 5
1.4 Query Type '*' and A/AAAA Records . . . . . . . . . . . . 5 1.4. Query Type '*' and A/AAAA Records . . . . . . . . . . . . 5
2. DNS Considerations about Special IPv6 Addresses . . . . . . . 5 2. DNS Considerations about Special IPv6 Addresses . . . . . . . 5
2.1 Limited-scope Addresses . . . . . . . . . . . . . . . . . 6 2.1. Limited-scope Addresses . . . . . . . . . . . . . . . . . 6
2.2 Temporary Addresses . . . . . . . . . . . . . . . . . . . 6 2.2. Temporary Addresses . . . . . . . . . . . . . . . . . . . 6
2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 6 2.3. 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Other Transition Mechanisms . . . . . . . . . . . . . . . 6 2.4. Other Transition Mechanisms . . . . . . . . . . . . . . . 6
3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 7 3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 7
3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . 7 3.1. Misbehaviour of DNS Servers and Load-balancers . . . . . . 7
3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 7 3.2. Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 7
4. Recommendations for Service Provisioning using DNS . . . . . . 7 4. Recommendations for Service Provisioning using DNS . . . . . . 8
4.1 Use of Service Names instead of Node Names . . . . . . . . 8 4.1. Use of Service Names instead of Node Names . . . . . . . . 8
4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . 8 4.2. Separate vs the Same Service Names for IPv4 and IPv6 . . . 8
4.3 Adding the Records Only when Fully IPv6-enabled . . . . . 9 4.3. Adding the Records Only when Fully IPv6-enabled . . . . . 9
4.4 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 10 4.4. The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 10
4.4.1 TTL With Courtesy Additional Data . . . . . . . . . . 10 4.4.1. TTL With Courtesy Additional Data . . . . . . . . . . 10
4.4.2 TTL With Critical Additional Data . . . . . . . . . . 10 4.4.2. TTL With Critical Additional Data . . . . . . . . . . 11
4.5 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 11 4.5. IPv6 Transport Guidelines for DNS Servers . . . . . . . . 11
5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 11 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 11
5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 11 5.1. DNS Lookups May Query IPv6 Records Prematurely . . . . . . 11
5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 13 5.2. Obtaining a List of DNS Recursive Resolvers . . . . . . . 13
5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 13 5.3. IPv6 Transport Guidelines for Resolvers . . . . . . . . . 13
6. Considerations about Forward DNS Updating . . . . . . . . . . 13 6. Considerations about Forward DNS Updating . . . . . . . . . . 14
6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 14 6.1. Manual or Custom DNS Updates . . . . . . . . . . . . . . . 14
6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 14
7. Considerations about Reverse DNS Updating . . . . . . . . . . 15 7. Considerations about Reverse DNS Updating . . . . . . . . . . 15
7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 15 7.1. Applicability of Reverse DNS . . . . . . . . . . . . . . . 15
7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16 7.2. Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16
7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 16 7.3. DDNS with Stateless Address Autoconfiguration . . . . . . 17
7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 18 7.4. DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 18
7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 18 7.5. DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 18
8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 19 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 19
8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 19 8.1. NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 19
8.2 Renumbering Procedures and Applications' Use of DNS . . . 19 8.2. Renumbering Procedures and Applications' Use of DNS . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11.1 Normative References . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.2 Informative References . . . . . . . . . . . . . . . . . . 22 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 12.2. Informative References . . . . . . . . . . . . . . . . . . 23
A. Unique Local Addressing Considerations for DNS . . . . . . . . 25 Appendix A. Unique Local Addressing Considerations for DNS . . . 25
B. Behaviour of Additional Data in IPv4/IPv6 Environments . . . . 25 Appendix B. Behaviour of Additional Data in IPv4/IPv6
B.1 Description of Additional Data Scenarios . . . . . . . . . 26 Environments . . . . . . . . . . . . . . . . . . . . 25
B.2 Which Additional Data to Keep, If Any? . . . . . . . . . . 27 B.1. Description of Additional Data Scenarios . . . . . . . . . 25
B.3 Discussion of the Potential Problems . . . . . . . . . . . 28 B.2. Which Additional Data to Keep, If Any? . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . 30 B.3. Discussion of the Potential Problems . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 29
1. Introduction 1. Introduction
This memo presents operational considerations and issues with IPv6 This memo presents operational considerations and issues with IPv6
DNS; it is meant to be an extensive summary and a list of pointers DNS; it is meant to be an extensive summary and a list of pointers
for more information about IPv6 DNS considerations for those with for more information about IPv6 DNS considerations for those with
experience with IPv4 DNS. experience with IPv4 DNS.
The purpose of this document is to give information about various The purpose of this document is to give information about various
issues and considerations related to DNS operations with IPv6; it is issues and considerations related to DNS operations with IPv6; it is
skipping to change at page 4, line 35 skipping to change at page 4, line 35
of IPv6 records with DNS. The fourth section lists recommendations of IPv6 records with DNS. The fourth section lists recommendations
and considerations for provisioning services with DNS. The fifth and considerations for provisioning services with DNS. The fifth
section in turn looks at recommendations and considerations about section in turn looks at recommendations and considerations about
providing IPv6 support in the resolvers. The sixth and seventh providing IPv6 support in the resolvers. The sixth and seventh
sections describe considerations with forward and reverse DNS sections describe considerations with forward and reverse DNS
updates, respectively. The eighth section introduces several updates, respectively. The eighth section introduces several
miscellaneous IPv6 issues relating to DNS for which no better place miscellaneous IPv6 issues relating to DNS for which no better place
has been found in this memo. Appendix A looks briefly at the has been found in this memo. Appendix A looks briefly at the
requirements for unique local addressing. requirements for unique local addressing.
1.1 Representing IPv6 Addresses in DNS Records 1.1. Representing IPv6 Addresses in DNS Records
In the forward zones, IPv6 addresses are represented using AAAA In the forward zones, IPv6 addresses are represented using AAAA
records. In the reverse zones, IPv6 address are represented using records. In the reverse zones, IPv6 address are represented using
PTR records in the nibble format under the ip6.arpa. tree. See PTR records in the nibble format under the ip6.arpa. tree. See
[RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152] [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152]
for background information. for background information.
In particular one should note that the use of A6 records in the In particular one should note that the use of A6 records in the
forward tree or Bitlabels in the reverse tree is not recommended forward tree or Bitlabels in the reverse tree is not recommended
[RFC3363]. Using DNAME records is not recommended in the reverse [RFC3363]. Using DNAME records is not recommended in the reverse
tree in conjunction with A6 records; the document did not mean to tree in conjunction with A6 records; the document did not mean to
take a stance on any other use of DNAME records [RFC3364]. take a stance on any other use of DNAME records [RFC3364].
1.2 Independence of DNS Transport and DNS Records 1.2. Independence of DNS Transport and DNS Records
DNS has been designed to present a single, globally unique name space DNS has been designed to present a single, globally unique name space
[RFC2826]. This property should be maintained, as described here and [RFC2826]. This property should be maintained, as described here and
in Section 1.3. in Section 1.3.
The IP version used to transport the DNS queries and responses is The IP version used to transport the DNS queries and responses is
independent of the records being queried: AAAA records can be queried independent of the records being queried: AAAA records can be queried
over IPv4, and A records over IPv6. The DNS servers must not make over IPv4, and A records over IPv6. The DNS servers must not make
any assumptions about what data to return for Answer and Authority any assumptions about what data to return for Answer and Authority
sections based on the underlying transport used in a query. sections based on the underlying transport used in a query.
skipping to change at page 5, line 27 skipping to change at page 5, line 27
at all (consider the case where the client is led to believe that a at all (consider the case where the client is led to believe that a
name received in the additional record does not have any AAAA records name received in the additional record does not have any AAAA records
at all). at all).
As stated in [RFC3596]: As stated in [RFC3596]:
The IP protocol version used for querying resource records is The IP protocol version used for querying resource records is
independent of the protocol version of the resource records; e.g., independent of the protocol version of the resource records; e.g.,
IPv4 transport can be used to query IPv6 records and vice versa. IPv4 transport can be used to query IPv6 records and vice versa.
1.3 Avoiding IPv4/IPv6 Name Space Fragmentation 1.3. Avoiding IPv4/IPv6 Name Space Fragmentation
To avoid the DNS name space from fragmenting into parts where some To avoid the DNS name space from fragmenting into parts where some
parts of DNS are only visible using IPv4 (or IPv6) transport, the parts of DNS are only visible using IPv4 (or IPv6) transport, the
recommendation is to always keep at least one authoritative server recommendation is to always keep at least one authoritative server
IPv4-enabled, and to ensure that recursive DNS servers support IPv4. IPv4-enabled, and to ensure that recursive DNS servers support IPv4.
See DNS IPv6 transport guidelines [RFC3901] for more information. See DNS IPv6 transport guidelines [RFC3901] for more information.
1.4 Query Type '*' and A/AAAA Records 1.4. Query Type '*' and A/AAAA Records
QTYPE=* is typically only used for debugging or management purposes; QTYPE=* is typically only used for debugging or management purposes;
it is worth keeping in mind that QTYPE=* ("ANY" queries) only return it is worth keeping in mind that QTYPE=* ("ANY" queries) only return
any available RRsets, not *all* the RRsets, because the caches do not any available RRsets, not *all* the RRsets, because the caches do not
necessarily have all the RRsets and have no way of guaranteeing that necessarily have all the RRsets and have no way of guaranteeing that
they have all the RRsets. Therefore, to get both A and AAAA records they have all the RRsets. Therefore, to get both A and AAAA records
reliably, two separate queries must be made. reliably, two separate queries must be made.
2. DNS Considerations about Special IPv6 Addresses 2. DNS Considerations about Special IPv6 Addresses
There are a couple of IPv6 address types which are somewhat special; There are a couple of IPv6 address types which are somewhat special;
these are considered here. these are considered here.
2.1 Limited-scope Addresses 2.1. Limited-scope Addresses
The IPv6 addressing architecture [RFC3513] includes two kinds of The IPv6 addressing architecture [RFC3513] includes two kinds of
local-use addresses: link-local (fe80::/10) and site-local local-use addresses: link-local (fe80::/10) and site-local
(fec0::/10). The site-local addresses have been deprecated [RFC3879] (fec0::/10). The site-local addresses have been deprecated [RFC3879]
but are discussed with unique local addresses in Appendix A. but are discussed with unique local addresses in Appendix A.
Link-local addresses should never be published in DNS (whether in Link-local addresses should never be published in DNS (whether in
forward or reverse tree), because they have only local (to the forward or reverse tree), because they have only local (to the
connected link) significance [I-D.durand-dnsop-dont-publish]. connected link) significance [I-D.durand-dnsop-dont-publish].
2.2 Temporary Addresses 2.2. Temporary Addresses
Temporary addresses defined in RFC3041 [RFC3041] (sometimes called Temporary addresses defined in RFC3041 [RFC3041] (sometimes called
"privacy addresses") use a random number as the interface identifier. "privacy addresses") use a random number as the interface identifier.
Having DNS AAAA records that are updated to always contain the Having DNS AAAA records that are updated to always contain the
current value of a node's temporary address would defeat the purpose current value of a node's temporary address would defeat the purpose
of the mechanism and is not recommended. However, it would still be of the mechanism and is not recommended. However, it would still be
possible to return a non-identifiable name (e.g., the IPv6 address in possible to return a non-identifiable name (e.g., the IPv6 address in
hexadecimal format), as described in [RFC3041]. hexadecimal format), as described in [RFC3041].
2.3 6to4 Addresses 2.3. 6to4 Addresses
6to4 [RFC3056] specifies an automatic tunneling mechanism which maps 6to4 [RFC3056] specifies an automatic tunneling mechanism which maps
a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48.
If the reverse DNS population would be desirable (see Section 7.1 for If the reverse DNS population would be desirable (see Section 7.1 for
applicability), there are a number of possible ways to do so. applicability), there are a number of possible ways to do so.
The main proposal [I-D.huston-6to4-reverse-dns] aims to design an The main proposal [I-D.huston-6to4-reverse-dns] aims to design an
autonomous reverse-delegation system that anyone being capable of autonomous reverse-delegation system that anyone being capable of
communicating using a specific 6to4 address would be able to set up a communicating using a specific 6to4 address would be able to set up a
reverse delegation to the corresponding 6to4 prefix. This could be reverse delegation to the corresponding 6to4 prefix. This could be
deployed by e.g., Regional Internet Registries (RIRs). This is a deployed by e.g., Regional Internet Registries (RIRs). This is a
practical solution, but may have some scalability concerns. practical solution, but may have some scalability concerns.
2.4 Other Transition Mechanisms 2.4. Other Transition Mechanisms
6to4 is mentioned as a case of an IPv6 transition mechanism requiring 6to4 is mentioned as a case of an IPv6 transition mechanism requiring
special considerations. In general, mechanisms which include a special considerations. In general, mechanisms which include a
special prefix may need a custom solution; otherwise, for example special prefix may need a custom solution; otherwise, for example
when IPv4 address is embedded as the suffix or not embedded at all, when IPv4 address is embedded as the suffix or not embedded at all,
special solutions are likely not needed. special solutions are likely not needed.
Note that it does not seem feasible to provide reverse DNS with Note that it does not seem feasible to provide reverse DNS with
another automatic tunneling mechanism, Teredo [I-D.huitema-v6ops- another automatic tunneling mechanism, Teredo [I-D.huitema-v6ops-
teredo]; this is because the IPv6 address is based on the IPv4 teredo]; this is because the IPv6 address is based on the IPv4
skipping to change at page 7, line 14 skipping to change at page 7, line 14
relatively short-lived. relatively short-lived.
3. Observed DNS Implementation Misbehaviour 3. Observed DNS Implementation Misbehaviour
Several classes of misbehaviour in DNS servers, load-balancers and Several classes of misbehaviour in DNS servers, load-balancers and
resolvers have been observed. Most of these are rather generic, not resolvers have been observed. Most of these are rather generic, not
only applicable to IPv6 -- but in some cases, the consequences of only applicable to IPv6 -- but in some cases, the consequences of
this misbehaviour are extremely severe in IPv6 environments and this misbehaviour are extremely severe in IPv6 environments and
deserve to be mentioned. deserve to be mentioned.
3.1 Misbehaviour of DNS Servers and Load-balancers 3.1. Misbehaviour of DNS Servers and Load-balancers
There are several classes of misbehaviour in certain DNS servers and There are several classes of misbehaviour in certain DNS servers and
load-balancers which have been noticed and documented [RFC4074]: some load-balancers which have been noticed and documented [RFC4074]: some
implementations silently drop queries for unimplemented DNS records implementations silently drop queries for unimplemented DNS records
types, or provide wrong answers to such queries (instead of a proper types, or provide wrong answers to such queries (instead of a proper
negative reply). While typically these issues are not limited to negative reply). While typically these issues are not limited to
AAAA records, the problems are aggravated by the fact that AAAA AAAA records, the problems are aggravated by the fact that AAAA
records are being queried instead of (mainly) A records. records are being queried instead of (mainly) A records.
The problems are serious because when looking up a DNS name, typical The problems are serious because when looking up a DNS name, typical
skipping to change at page 7, line 42 skipping to change at page 7, line 42
in some cases, IPv6 support in the software has even been disabled in some cases, IPv6 support in the software has even been disabled
due to these problems. due to these problems.
The solution is to fix or retire those misbehaving implementations, The solution is to fix or retire those misbehaving implementations,
but that is likely not going to be effective. There are some but that is likely not going to be effective. There are some
possible ways to mitigate the problem, e.g., by performing the possible ways to mitigate the problem, e.g., by performing the
lookups somewhat in parallel and reducing the timeout as long as at lookups somewhat in parallel and reducing the timeout as long as at
least one answer has been received; but such methods remain to be least one answer has been received; but such methods remain to be
investigated; slightly more on this is included in Section 5. investigated; slightly more on this is included in Section 5.
3.2 Misbehaviour of DNS Resolvers 3.2. Misbehaviour of DNS Resolvers
Several classes of misbehaviour have also been noticed in DNS Several classes of misbehaviour have also been noticed in DNS
resolvers [I-D.ietf-dnsop-bad-dns-res]. However, these do not seem resolvers [I-D.ietf-dnsop-bad-dns-res]. However, these do not seem
to directly impair IPv6 use, and are only referred to for to directly impair IPv6 use, and are only referred to for
completeness. completeness.
4. Recommendations for Service Provisioning using DNS 4. Recommendations for Service Provisioning using DNS
When names are added in the DNS to facilitate a service, there are When names are added in the DNS to facilitate a service, there are
several general guidelines to consider to be able to do it as several general guidelines to consider to be able to do it as
smoothly as possible. smoothly as possible.
4.1 Use of Service Names instead of Node Names 4.1. Use of Service Names instead of Node Names
It makes sense to keep information about separate services logically It makes sense to keep information about separate services logically
separate in the DNS by using a different DNS hostname for each separate in the DNS by using a different DNS hostname for each
service. There are several reasons for doing this, for example: service. There are several reasons for doing this, for example:
o It allows more flexibility and ease for migration of (only a part o It allows more flexibility and ease for migration of (only a part
of) services from one node to another, of) services from one node to another,
o It allows configuring different properties (e.g., TTL) for each o It allows configuring different properties (e.g., TTL) for each
service, and service, and
skipping to change at page 8, line 44 skipping to change at page 8, line 48
look up the mail via IMAP from "pobox.example.com", one could use look up the mail via IMAP from "pobox.example.com", one could use
e.g., "smtp.example.com" for SMTP (for both message submission and e.g., "smtp.example.com" for SMTP (for both message submission and
mail relaying between SMTP servers) and "imap.example.com" for IMAP. mail relaying between SMTP servers) and "imap.example.com" for IMAP.
Note that in the specific case of SMTP relaying, the server itself Note that in the specific case of SMTP relaying, the server itself
must typically also be configured to know all its names to ensure must typically also be configured to know all its names to ensure
loops do not occur. DNS can provide a layer of indirection between loops do not occur. DNS can provide a layer of indirection between
service names and where the service actually is, and using which service names and where the service actually is, and using which
addresses. (Obviously, when wanting to reach a specific node, one addresses. (Obviously, when wanting to reach a specific node, one
should use the hostname rather than a service name.) should use the hostname rather than a service name.)
4.2 Separate vs the Same Service Names for IPv4 and IPv6 4.2. Separate vs the Same Service Names for IPv4 and IPv6
The service naming can be achieved in basically two ways: when a The service naming can be achieved in basically two ways: when a
service is named "service.example.com" for IPv4, the IPv6-enabled service is named "service.example.com" for IPv4, the IPv6-enabled
service could either be added to "service.example.com", or added service could either be added to "service.example.com", or added
separately under a different name, e.g., in a sub-domain, like, separately under a different name, e.g., in a sub-domain, like,
"service.ipv6.example.com". "service.ipv6.example.com".
These two methods have different characteristics. Using a different These two methods have different characteristics. Using a different
name allows for easier service piloting, minimizing the disturbance name allows for easier service piloting, minimizing the disturbance
to the "regular" users of IPv4 service; however, the service would to the "regular" users of IPv4 service; however, the service would
skipping to change at page 9, line 24 skipping to change at page 9, line 26
suboptimal solution. Using the same service name is the "long-term" suboptimal solution. Using the same service name is the "long-term"
solution, but may degrade performance for those clients whose IPv6 solution, but may degrade performance for those clients whose IPv6
performance is lower than IPv4, or does not work as well (see performance is lower than IPv4, or does not work as well (see
Section 4.3 for more). Section 4.3 for more).
In most cases, it makes sense to pilot or test a service using In most cases, it makes sense to pilot or test a service using
separate service names, and move to the use of the same name when separate service names, and move to the use of the same name when
confident enough that the service level will not degrade for the confident enough that the service level will not degrade for the
users unaware of IPv6. users unaware of IPv6.
4.3 Adding the Records Only when Fully IPv6-enabled 4.3. Adding the Records Only when Fully IPv6-enabled
The recommendation is that AAAA records for a service should not be The recommendation is that AAAA records for a service should not be
added to the DNS until all of following are true: added to the DNS until all of following are true:
1. The address is assigned to the interface on the node. 1. The address is assigned to the interface on the node.
2. The address is configured on the interface. 2. The address is configured on the interface.
3. The interface is on a link which is connected to the IPv6 3. The interface is on a link which is connected to the IPv6
infrastructure. infrastructure.
skipping to change at page 10, line 10 skipping to change at page 10, line 14
The issues are not always so black-and-white. Usually it's important The issues are not always so black-and-white. Usually it's important
that the service offered using both protocols is of roughly equal that the service offered using both protocols is of roughly equal
quality, using the appropriate metrics for the service (e.g., quality, using the appropriate metrics for the service (e.g.,
latency, throughput, low packet loss, general reliability, etc.) -- latency, throughput, low packet loss, general reliability, etc.) --
this is typically very important especially for interactive or real- this is typically very important especially for interactive or real-
time services. In many cases, the quality of IPv6 connectivity may time services. In many cases, the quality of IPv6 connectivity may
not yet be equal to that of IPv4, at least globally -- this has to be not yet be equal to that of IPv4, at least globally -- this has to be
taken into consideration when enabling services. taken into consideration when enabling services.
4.4 The Use of TTL for IPv4 and IPv6 RRs 4.4. The Use of TTL for IPv4 and IPv6 RRs
The behaviour of DNS caching when different TTL values are used for The behaviour of DNS caching when different TTL values are used for
different RRsets of the same name calls for explicit discussion. For different RRsets of the same name calls for explicit discussion. For
example, let's consider two unrelated zone fragments: example, let's consider two unrelated zone fragments:
example.com. 300 IN MX foo.example.com. example.com. 300 IN MX foo.example.com.
foo.example.com. 300 IN A 192.0.2.1 foo.example.com. 300 IN A 192.0.2.1
foo.example.com. 100 IN AAAA 2001:db8::1 foo.example.com. 100 IN AAAA 2001:db8::1
... ...
child.example.com. 300 IN NS ns.child.example.com. child.example.com. 300 IN NS ns.child.example.com.
ns.child.example.com. 300 IN A 192.0.2.1 ns.child.example.com. 300 IN A 192.0.2.1
ns.child.example.com. 100 IN AAAA 2001:db8::1 ns.child.example.com. 100 IN AAAA 2001:db8::1
In the former case, we have "courtesy" additional data; in the In the former case, we have "courtesy" additional data; in the
latter, we have "critical" additional data. See more extensive latter, we have "critical" additional data. See more extensive
background discussion of additional data handling in Appendix B. background discussion of additional data handling in Appendix B.
4.4.1 TTL With Courtesy Additional Data 4.4.1. TTL With Courtesy Additional Data
When a caching resolver asks for the MX record of example.com, it When a caching resolver asks for the MX record of example.com, it
gets back "foo.example.com". It may also get back either one or both gets back "foo.example.com". It may also get back either one or both
of the A and AAAA records in the additional section. The resolver of the A and AAAA records in the additional section. The resolver
must explicitly query for both A and AAAA records [RFC2821]. must explicitly query for both A and AAAA records [RFC2821].
After 100 seconds, the AAAA record is removed from the cache(s) After 100 seconds, the AAAA record is removed from the cache(s)
because its TTL expired. It could be argued to be useful for the because its TTL expired. It could be argued to be useful for the
caching resolvers to discard the A record when the shorter TTL (in caching resolvers to discard the A record when the shorter TTL (in
this case, for the AAAA record) expires; this would avoid the this case, for the AAAA record) expires; this would avoid the
situation where there would be a window of 200 seconds when situation where there would be a window of 200 seconds when
incomplete information is returned from the cache. Further argument incomplete information is returned from the cache. Further argument
for discarding is that in the normal operation, the TTL values are so for discarding is that in the normal operation, the TTL values are so
high that very likely the incurred additional queries would not be high that very likely the incurred additional queries would not be
noticeable, compared to the obtained performance optimization. The noticeable, compared to the obtained performance optimization. The
behaviour in this scenario is unspecified. behaviour in this scenario is unspecified.
4.4.2 TTL With Critical Additional Data 4.4.2. TTL With Critical Additional Data
The difference to courtesy additional data is that the A/AAAA records The difference to courtesy additional data is that the A/AAAA records
served by the parent zone cannot be queried explicitly. Therefore served by the parent zone cannot be queried explicitly. Therefore
after 100 seconds the AAAA record is removed from the cache(s), but after 100 seconds the AAAA record is removed from the cache(s), but
the A record remains. Queries for the remaining 200 seconds the A record remains. Queries for the remaining 200 seconds
(provided that there are no further queries from the parent which (provided that there are no further queries from the parent which
could refresh the caches) only return the A record, leading to a could refresh the caches) only return the A record, leading to a
potential opererational situation with unreachable servers. potential opererational situation with unreachable servers.
Similar cache flushing strategies apply in this scenario; the record. Similar cache flushing strategies apply in this scenario; the
behaviour is likewise unspecified.
4.5 IPv6 Transport Guidelines for DNS Servers 4.5. IPv6 Transport Guidelines for DNS Servers
As described in Section 1.3 and [RFC3901], there should continue to As described in Section 1.3 and [RFC3901], there should continue to
be at least one authoritative IPv4 DNS server for every zone, even if be at least one authoritative IPv4 DNS server for every zone, even if
the zone has only IPv6 records. (Note that obviously, having more the zone has only IPv6 records. (Note that obviously, having more
servers with robust connectivity would be preferable, but this is the servers with robust connectivity would be preferable, but this is the
minimum recommendation; also see [RFC2182].) minimum recommendation; also see [RFC2182].)
5. Recommendations for DNS Resolver IPv6 Support 5. Recommendations for DNS Resolver IPv6 Support
When IPv6 is enabled on a node, there are several things to consider When IPv6 is enabled on a node, there are several things to consider
to ensure that the process is as smooth as possible. to ensure that the process is as smooth as possible.
5.1 DNS Lookups May Query IPv6 Records Prematurely 5.1. DNS Lookups May Query IPv6 Records Prematurely
The system library that implements the getaddrinfo() function for The system library that implements the getaddrinfo() function for
looking up names is a critical piece when considering the robustness looking up names is a critical piece when considering the robustness
of enabling IPv6; it may come in basically three flavours: of enabling IPv6; it may come in basically three flavours:
1. The system library does not know whether IPv6 has been enabled in 1. The system library does not know whether IPv6 has been enabled in
the kernel of the operating system: it may start looking up AAAA the kernel of the operating system: it may start looking up AAAA
records with getaddrinfo() and AF_UNSPEC hint when the system is records with getaddrinfo() and AF_UNSPEC hint when the system is
upgraded to a system library version which supports IPv6. upgraded to a system library version which supports IPv6.
skipping to change at page 13, line 10 skipping to change at page 13, line 16
performing DNS lookups only when a non-link-local address has been performing DNS lookups only when a non-link-local address has been
configured on any interface could be beneficial -- this would be an configured on any interface could be beneficial -- this would be an
indication that either the address has been configured either from a indication that either the address has been configured either from a
router advertisement, DHCPv6 [RFC3315], or manually. Each would router advertisement, DHCPv6 [RFC3315], or manually. Each would
indicate at least some form of IPv6 connectivity, even though there indicate at least some form of IPv6 connectivity, even though there
would not be guarantees of it. would not be guarantees of it.
These issues should be analyzed at more depth, and the fixes found These issues should be analyzed at more depth, and the fixes found
consensus on, perhaps in a separate document. consensus on, perhaps in a separate document.
5.2 Obtaining a List of DNS Recursive Resolvers 5.2. Obtaining a List of DNS Recursive Resolvers
In scenarios where DHCPv6 is available, a host can discover a list of In scenarios where DHCPv6 is available, a host can discover a list of
DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server" DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server"
option [RFC3646]. This option can be passed to a host through a option [RFC3646]. This option can be passed to a host through a
subset of DHCPv6 [RFC3736]. subset of DHCPv6 [RFC3736].
The IETF is considering the development of alternative mechanisms for The IETF is considering the development of alternative mechanisms for
obtaining the list of DNS recursive name servers when DHCPv6 is obtaining the list of DNS recursive name servers when DHCPv6 is
unavailable or inappropriate. No decision about taking on this unavailable or inappropriate. No decision about taking on this
development work has been reached as of this writing (Aug 2004) development work has been reached as of this writing (Aug 2004)
skipping to change at page 13, line 36 skipping to change at page 13, line 42
Advertisements to convey the information [I-D.jeong-dnsop-ipv6-dns- Advertisements to convey the information [I-D.jeong-dnsop-ipv6-dns-
discovery]. discovery].
Note that even though IPv6 DNS resolver discovery is a recommended Note that even though IPv6 DNS resolver discovery is a recommended
procedure, it is not required for dual-stack nodes in dual-stack 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 networks as IPv6 DNS records can be queried over IPv4 as well as
IPv6. Obviously, nodes which are meant to function without manual IPv6. Obviously, nodes which are meant to function without manual
configuration in IPv6-only networks must implement the DNS resolver configuration in IPv6-only networks must implement the DNS resolver
discovery function. discovery function.
5.3 IPv6 Transport Guidelines for Resolvers 5.3. IPv6 Transport Guidelines for Resolvers
As described in Section 1.3 and [RFC3901], the recursive 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 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- DNS server. Note that this requirement is also fulfilled by an IPv6-
only stub resolver pointing to a dual-stack recursive DNS resolver. only stub resolver pointing to a dual-stack recursive DNS resolver.
6. Considerations about Forward DNS Updating 6. Considerations about Forward DNS Updating
While the topic of how to enable updating the forward DNS, i.e., the 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 mapping from names to the correct new addresses, is not specific to
skipping to change at page 14, line 15 skipping to change at page 14, line 25
with the DNS name and the node which is allowed to update it to point with the DNS name and the node which is allowed to update it to point
to a new address. to a new address.
A more complex form of DNS updates -- adding a whole new name into a 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 DNS zone, instead of updating an existing name -- is considered out
of scope for this memo as it could require zone-wide authentication. 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 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 being explored with IPv4, and IPv6 does not seem to add much new in
that area. that area.
6.1 Manual or Custom DNS Updates 6.1. Manual or Custom DNS Updates
The DNS mappings can also be maintained by hand, in a semi-automatic The DNS mappings can also be maintained by hand, in a semi-automatic
fashion or by running non-standardized protocols. These are not fashion or by running non-standardized protocols. These are not
considered at more length in this memo. considered at more length in this memo.
6.2 Dynamic DNS 6.2. Dynamic DNS
Dynamic DNS updates (DDNS) [RFC2136] [RFC3007] is a standardized Dynamic DNS updates (DDNS) [RFC2136] [RFC3007] is a standardized
mechanism for dynamically updating the DNS. It works equally well mechanism for dynamically updating the DNS. It works equally well
with stateless address autoconfiguration (SLAAC), DHCPv6 or manual with stateless address autoconfiguration (SLAAC), DHCPv6 or manual
address configuration. It is important to consider how each of these address configuration. It is important to consider how each of these
behave if IP address-based authentication, instead of stronger behave if IP address-based authentication, instead of stronger
mechanisms [RFC3007], was used in the updates. mechanisms [RFC3007], was used in the updates.
1. manual addresses are static and can be configured 1. manual addresses are static and can be configured
skipping to change at page 15, line 29 skipping to change at page 15, line 38
Care should be observed when updating the addresses not to use longer Care should be observed when updating the addresses not to use longer
TTLs for addresses than are preferred lifetimes for the addresses, so TTLs for addresses than are preferred lifetimes for the addresses, so
that if the node is renumbered in a managed fashion, the amount of 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 stale DNS information is kept to the minimum. That is, if the
preferred lifetime of an address expires, the TTL of the record needs preferred lifetime of an address expires, the TTL of the record needs
be modified unless it was already done before the expiration. For be modified unless it was already done before the expiration. For
better flexibility, the DNS TTL should be much shorter (e.g., a half 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 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 start lowering the DNS TTL if it seems like the address has not been
renewed/refreshed in a while. Some discussion on how an renewed/refreshed in a while. Some discussion on how an
administrator could manage the DNS TTL is included in [I-D.ietf- administrator could manage the DNS TTL is included in [RFC4192]; this
v6ops-renumbering-procedure]; this could be applied to (smart) hosts could be applied to (smart) hosts as well.
as well.
7. Considerations about Reverse DNS Updating 7. Considerations about Reverse DNS Updating
Updating the reverse DNS zone may be difficult because of the split Updating the reverse DNS zone may be difficult because of the split
authority over an address. However, first we have to consider the authority over an address. However, first we have to consider the
applicability of reverse DNS in the first place. applicability of reverse DNS in the first place.
7.1 Applicability of Reverse DNS 7.1. Applicability of Reverse DNS
Today, some applications use reverse DNS to either look up some hints Today, some applications use reverse DNS to either look up some hints
about the topological information associated with an address (e.g. about the topological information associated with an address (e.g.
resolving web server access logs), or as a weak form of a security 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 check, to get a feel whether the user's network administrator has
"authorized" the use of the address (on the premises that adding a "authorized" the use of the address (on the premises that adding a
reverse record for an address would signal some form of reverse record for an address would signal some form of
authorization). authorization).
One additional, maybe slightly more useful usage is ensuring that the One additional, maybe slightly more useful usage is ensuring that the
skipping to change at page 16, line 27 skipping to change at page 16, line 35
reverse DNS records be updated. In many cases, it would just make reverse DNS records be updated. In many cases, it would just make
more sense to use proper mechanisms for security (or topological more sense to use proper mechanisms for security (or topological
information lookup) in the first place. At minimum, the applications information lookup) in the first place. At minimum, the applications
which use it as a generic authorization (in the sense that a record 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 exists at all) should be modified as soon as possible to avoid such
lookups completely. lookups completely.
The applicability is discussed at more length in [I-D.ietf-dnsop- The applicability is discussed at more length in [I-D.ietf-dnsop-
inaddr-required]. inaddr-required].
7.2 Manual or Custom DNS Updates 7.2. Manual or Custom DNS Updates
Reverse DNS can of course be updated using manual or custom methods. Reverse DNS can of course be updated using manual or custom methods.
These are not further described here, except for one special case. These are not further described here, except for one special case.
One way to deploy reverse DNS would be to use wildcard records, for 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). 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 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 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 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 site.example.com." Naturally, such a name could not be verified from
the forward DNS, but would at least provide some form of "topological the forward DNS, but would at least provide some form of "topological
information" or "weak authorization" if that is really considered to information" or "weak authorization" if that is really considered to
be useful. Note that this is not actually updating the DNS as such, 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 as the whole point is to avoid DNS updates completely by manually
configuring a generic name. configuring a generic name.
7.3 DDNS with Stateless Address Autoconfiguration 7.3. DDNS with Stateless Address Autoconfiguration
Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in
some regard, while being more difficult in another, as described some regard, while being more difficult in another, as described
below. below.
The address space administrator decides whether the hosts are trusted The address space administrator decides whether the hosts are trusted
to update their reverse DNS records or not. If they are trusted and to update their reverse DNS records or not. If they are trusted and
deployed at the same site (e.g., not across the Internet), a simple deployed at the same site (e.g., not across the Internet), a simple
address-based authorization is typically sufficient (i.e., check that address-based authorization is typically sufficient (i.e., check that
the DNS update is done from the same IP address as the record being the DNS update is done from the same IP address as the record being
skipping to change at page 18, line 5 skipping to change at page 18, line 14
One should note that Cryptographically Generated Addresses [RFC3972] One should note that Cryptographically Generated Addresses [RFC3972]
(CGAs) may require a slightly different kind of treatment. CGAs are (CGAs) may require a slightly different kind of treatment. CGAs are
addresses where the interface identifier is calculated from a public addresses where the interface identifier is calculated from a public
key, a modifier (used as a nonce), the subnet prefix, and other data. 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 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 periodically due to e.g., privacy reasons. As the CGA address is not
predicatable, a reverse record can only reasonably be inserted in the predicatable, a reverse record can only reasonably be inserted in the
DNS by the node which generates the address. DNS by the node which generates the address.
7.4 DDNS with DHCP 7.4. DDNS with DHCP
With DHCPv4, the reverse DNS name is typically already inserted to 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 the DNS that reflects to the name (e.g., "dhcp-67.example.com"). One
can assume similar practice may become commonplace with DHCPv6 as can assume similar practice may become commonplace with DHCPv6 as
well; all such mappings would be pre-configured, and would require no well; all such mappings would be pre-configured, and would require no
updating. updating.
If a more explicit control is required, similar considerations as If a more explicit control is required, similar considerations as
with SLAAC apply, except for the fact that typically one must update with SLAAC apply, except for the fact that typically one must update
a reverse DNS record instead of inserting one (if an address a reverse DNS record instead of inserting one (if an address
skipping to change at page 18, line 32 skipping to change at page 18, line 41
perform the DNS updates; see the implications in Section 6.2. perform the DNS updates; see the implications in Section 6.2.
If disused addresses were to be reassigned, host-based DDNS reverse If disused addresses were to be reassigned, host-based DDNS reverse
updates would need policy considerations for DNS record modification, updates would need policy considerations for DNS record modification,
as noted above. On the other hand, if disused address were not to be as noted above. On the other hand, if disused address were not to be
assigned, host-based DNS reverse updates would have similar assigned, host-based DNS reverse updates would have similar
considerations as SLAAC in Section 7.3. Server-based updates have considerations as SLAAC in Section 7.3. Server-based updates have
similar properties except that the janitorial process could be similar properties except that the janitorial process could be
integrated with DHCP address assignment. integrated with DHCP address assignment.
7.5 DDNS with Dynamic Prefix Delegation 7.5. DDNS with Dynamic Prefix Delegation
In cases where a prefix, instead of an address, is being used and 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 updated, one should consider what is the location of the server where
DDNS updates are made. That is, where the DNS server is located: DDNS updates are made. That is, where the DNS server is located:
1. At the same organization as the prefix delegator. 1. At the same organization as the prefix delegator.
2. At the site where the prefixes are delegated to. In this case, 2. At the site where the prefixes are delegated to. In this case,
the authority of the DNS reverse zone corresponding to the the authority of the DNS reverse zone corresponding to the
delegated prefix is also delegated to the site. delegated prefix is also delegated to the site.
skipping to change at page 19, line 28 skipping to change at page 19, line 38
address-based authentication might not be acceptable). In the first address-based authentication might not be acceptable). In the first
case, however, setting up and managing such relationships might be a case, however, setting up and managing such relationships might be a
lot more difficult. lot more difficult.
8. Miscellaneous DNS Considerations 8. Miscellaneous DNS Considerations
This section describes miscellaneous considerations about DNS which This section describes miscellaneous considerations about DNS which
seem related to IPv6, for which no better place has been found in seem related to IPv6, for which no better place has been found in
this document. this document.
8.1 NAT-PT with DNS-ALG 8.1. NAT-PT with DNS-ALG
The DNS-ALG component of NAT-PT mangles A records to look like AAAA The DNS-ALG component of NAT-PT mangles A records to look like AAAA
records to the IPv6-only nodes. Numerous problems have been records to the IPv6-only nodes. Numerous problems have been
identified with DNS-ALG [I-D.ietf-v6ops-natpt-to-exprmntl]. This is 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. a strong reason not to use NAT-PT in the first place.
8.2 Renumbering Procedures and Applications' Use of DNS 8.2. Renumbering Procedures and Applications' Use of DNS
One of the most difficult problems of systematic IP address One of the most difficult problems of systematic IP address
renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that renumbering procedures [RFC4192] is that an application which looks
an application which looks up a DNS name disregards information such up a DNS name disregards information such as TTL, and uses the result
as TTL, and uses the result obtained from DNS as long as it happens obtained from DNS as long as it happens to be stored in the memory of
to be stored in the memory of the application. For applications the application. For applications which run for a long time, this
which run for a long time, this could be days, weeks or even months; could be days, weeks or even months; some applications may be clever
some applications may be clever enough to organize the data enough to organize the data structures and functions in such a manner
structures and functions in such a manner that look-ups get refreshed that look-ups get refreshed now and then.
now and then.
While the issue appears to have a clear solution, "fix the While the issue appears to have a clear solution, "fix the
applications", practically this is not reasonable immediate advice; applications", practically this is not reasonable immediate advice;
the TTL information is not typically available in the APIs and the TTL information is not typically available in the APIs and
libraries (so, the advice becomes "fix the applications, APIs and libraries (so, the advice becomes "fix the applications, APIs and
libraries"), and a lot more analysis is needed on how to practically libraries"), and a lot more analysis is needed on how to practically
go about to achieve the ultimate goal of avoiding using the names go about to achieve the ultimate goal of avoiding using the names
longer than expected. longer than expected.
9. Acknowledgements 9. Acknowledgements
Some recommendations (Section 4.3, Section 5.1) about IPv6 service Some recommendations (Section 4.3, Section 5.1) about IPv6 service
provisioning were moved here from [I-D.ietf-v6ops-mech-v2] by Erik provisioning were moved here from [RFC4213] by Erik Nordmark and Bob
Nordmark and Bob Gilligan. Havard Eidnes and Michael Patton provided Gilligan. Havard Eidnes and Michael Patton provided useful feedback
useful feedback and improvements. Scott Rose, Rob Austein, Masataka and improvements. Scott Rose, Rob Austein, Masataka Ohta, and Mark
Ohta, and Mark Andrews helped in clarifying the issues regarding Andrews helped in clarifying the issues regarding additional data and
additional data and the use of TTL. Jefsey Morfin, Ralph Droms, the use of TTL. Jefsey Morfin, Ralph Droms, Peter Koch, Jinmei
Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and Tatuya, Iljitsch van Beijnum, Edward Lewis, and Rob Austein provided
Rob Austein provided useful feedback during the WG last call. Thomas useful feedback during the WG last call. Thomas Narten provided
Narten provided extensive feedback during the IESG evaluation. extensive feedback during the IESG evaluation.
10. Security Considerations 10. IANA Considerations
This memo includes no request to IANA.
11. Security Considerations
This document reviews the operational procedures for IPv6 DNS This document reviews the operational procedures for IPv6 DNS
operations and does not have security considerations in itself. operations and does not have security considerations in itself.
However, it is worth noting that in particular with Dynamic DNS However, it is worth noting that in particular with Dynamic DNS
Updates, security models based on the source address validation are Updates, security models based on the source address validation are
very weak and cannot be recommended -- they could only be considered very weak and cannot be recommended -- they could only be considered
in the environments where ingress filtering [RFC3704] has been in the environments where ingress filtering [RFC3704] has been
deployed. On the other hand, it should be noted that setting up an deployed. On the other hand, it should be noted that setting up an
authorization mechanism (e.g., a shared secret, or public-private authorization mechanism (e.g., a shared secret, or public-private
keys) between a node and the DNS server has to be done manually, and keys) between a node and the DNS server has to be done manually, and
may require quite a bit of time and expertise. may require quite a bit of time and expertise.
To re-emphasize what was already stated, the reverse+forward DNS To re-emphasize what was already stated, the reverse+forward DNS
check provides very weak security at best, and the only check provides very weak security at best, and the only
(questionable) security-related use for them may be in conjunction (questionable) security-related use for them may be in conjunction
with other mechanisms when authenticating a user. with other mechanisms when authenticating a user.
11. References 12. References
11.1 Normative References 12.1. Normative References
[I-D.ietf-dnsop-ipv6-dns-configuration] [I-D.ietf-dnsop-ipv6-dns-configuration]
Jeong, J., "IPv6 Host Configuration of DNS Server Jeong, J., "IPv6 Host Configuration of DNS Server
Information Approaches", Information Approaches",
draft-ietf-dnsop-ipv6-dns-configuration-06 (work in draft-ietf-dnsop-ipv6-dns-configuration-06 (work in
progress), May 2005. 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.
[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", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997. RFC 2136, April 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997. Specification", RFC 2181, July 1997.
skipping to change at page 22, line 38 skipping to change at page 22, line 45
[RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational [RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational
Guidelines", BCP 91, RFC 3901, September 2004. Guidelines", BCP 91, RFC 3901, September 2004.
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
Castro, "Application Aspects of IPv6 Transition", Castro, "Application Aspects of IPv6 Transition",
RFC 4038, March 2005. RFC 4038, March 2005.
[RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against
DNS Queries for IPv6 Addresses", RFC 4074, May 2005. DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
11.2 Informative References [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
12.2. Informative References
[I-D.durand-dnsop-dont-publish] [I-D.durand-dnsop-dont-publish]
Durand, A. and T. Chown, "To publish, or not to publish, Durand, A. and T. Chown, "To publish, or not to publish,
that is the question.", draft-durand-dnsop-dont-publish-00 that is the question.", draft-durand-dnsop-dont-publish-00
(work in progress), February 2005. (work in progress), February 2005.
[I-D.huitema-v6ops-teredo] [I-D.huitema-v6ops-teredo]
Huitema, C., "Teredo: Tunneling IPv6 over UDP through Huitema, C., "Teredo: Tunneling IPv6 over UDP through
NATs", draft-huitema-v6ops-teredo-05 (work in progress), NATs", draft-huitema-v6ops-teredo-05 (work in progress),
April 2005. April 2005.
[I-D.huston-6to4-reverse-dns] [I-D.huston-6to4-reverse-dns]
Huston, G., "6to4 Reverse DNS Delegation", Huston, G., "6to4 Reverse DNS Delegation",
draft-huston-6to4-reverse-dns-03 (work in progress), draft-huston-6to4-reverse-dns-03 (work in progress),
October 2004. October 2004.
[I-D.ietf-dhc-ddns-resolution] [I-D.ietf-dhc-ddns-resolution]
Stapp, M. and B. Volz, "Resolution of FQDN Conflicts among Stapp, M. and B. Volz, "Resolution of FQDN Conflicts among
DHCP Clients", draft-ietf-dhc-ddns-resolution-09 (work in DHCP Clients", draft-ietf-dhc-ddns-resolution-10 (work in
progress), June 2005. progress), September 2005.
[I-D.ietf-dhc-fqdn-option] [I-D.ietf-dhc-fqdn-option]
Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option", Stapp, M., "The DHCP Client FQDN Option",
draft-ietf-dhc-fqdn-option-10 (work in progress), draft-ietf-dhc-fqdn-option-11 (work in progress),
February 2005. September 2005.
[I-D.ietf-dnsext-dhcid-rr] [I-D.ietf-dnsext-dhcid-rr]
Stapp, M., Lemon, T., and A. Gustafsson, "A DNS RR for Stapp, M., "A DNS RR for Encoding DHCP Information (DHCID
encoding DHCP information (DHCID RR)", RR)", draft-ietf-dnsext-dhcid-rr-10 (work in progress),
draft-ietf-dnsext-dhcid-rr-09 (work in progress), September 2005.
February 2005.
[I-D.ietf-dnsop-bad-dns-res] [I-D.ietf-dnsop-bad-dns-res]
Larson, M. and P. Barber, "Observed DNS Resolution Larson, M. and P. Barber, "Observed DNS Resolution
Misbehavior", draft-ietf-dnsop-bad-dns-res-03 (work in Misbehavior", draft-ietf-dnsop-bad-dns-res-04 (work in
progress), October 2004. progress), July 2005.
[I-D.ietf-dnsop-inaddr-required] [I-D.ietf-dnsop-inaddr-required]
Senie, D., "Encouraging the use of DNS IN-ADDR Mapping", Senie, D., "Encouraging the use of DNS IN-ADDR Mapping",
draft-ietf-dnsop-inaddr-required-06 (work in progress), draft-ietf-dnsop-inaddr-required-07 (work in progress),
February 2005. August 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] [I-D.ietf-v6ops-natpt-to-exprmntl]
Aoun, C. and E. Davies, "Reasons to Move NAT-PT to Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
Experimental", draft-ietf-v6ops-natpt-to-exprmntl-01 (work Experimental", draft-ietf-v6ops-natpt-to-exprmntl-02 (work
in progress), July 2005. in progress), October 2005.
[I-D.ietf-v6ops-onlinkassumption] [I-D.ietf-v6ops-onlinkassumption]
Roy, S., "IPv6 Neighbor Discovery On-Link Assumption Roy, S., "IPv6 Neighbor Discovery On-Link Assumption
Considered Harmful", draft-ietf-v6ops-onlinkassumption-03 Considered Harmful", draft-ietf-v6ops-onlinkassumption-03
(work in progress), May 2005. (work in progress), May 2005.
[I-D.ietf-v6ops-v6onbydefault] [I-D.ietf-v6ops-v6onbydefault]
Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack
IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03
(work in progress), July 2004. (work in progress), July 2004.
[I-D.jeong-dnsop-ipv6-dns-discovery] [I-D.jeong-dnsop-ipv6-dns-discovery]
Jeong, J., "IPv6 DNS Configuration based on Router Jeong, J., "IPv6 Router Advertisement Option for DNS
Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-04 Configuration", draft-jeong-dnsop-ipv6-dns-discovery-05
(work in progress), February 2005. (work in progress), July 2005.
[I-D.ohta-preconfigured-dns] [I-D.ohta-preconfigured-dns]
Ohta, M., "Preconfigured DNS Server Addresses", Ohta, M., "Preconfigured DNS Server Addresses",
draft-ohta-preconfigured-dns-01 (work in progress), draft-ohta-preconfigured-dns-01 (work in progress),
February 2004. February 2004.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766, Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000. February 2000.
skipping to change at page 24, line 40 skipping to change at page 24, line 43
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying [RFC4025] Richardson, M., "A Method for Storing IPsec Keying
Material in DNS", RFC 4025, March 2005. Material in DNS", RFC 4025, March 2005.
Authors' Addresses [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
Alain Durand
SUN Microsystems, Inc.
17 Network circle UMPL17-202
Menlo Park, CA 94025
USA
Email: Alain.Durand@sun.com
Johan Ihren
Autonomica
Bellmansgatan 30
SE-118 47 Stockholm
Sweden
Email: johani@autonomica.se [RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third
Generation Partnership Project (3GPP) Networks", RFC 4215,
October 2005.
Pekka Savola [TC-TEST] Jinmei, T., "Thread "RFC2181 section 9.1: TC bit handling
CSC/FUNET and additional data" on DNSEXT mailing list, Message-Id:
Espoo
Finland
Email: psavola@funet.fi y7vek9j9hyo.wl%jinmei@isl.rdc.toshiba.co.jp", August
1st 2005, <http://ops.ietf.org/lists/namedroppers/
namedroppers.2005/msg01102.html>.
Appendix A. Unique Local Addressing Considerations for DNS Appendix A. Unique Local Addressing Considerations for DNS
Unique local addresses [I-D.ietf-ipv6-unique-local-addr] have Unique local addresses [RFC4193] have replaced the now-deprecated
replaced the now-deprecated site-local addresses [RFC3879]. From the site-local addresses [RFC3879]. From the perspective of the DNS, the
perspective of the DNS, the locally generated unique local addresses locally generated unique local addresses (LUL) and site-local
(LUL) and site-local addresses have similar properties. addresses have similar properties.
The interactions with DNS come in two flavors: forward and reverse The interactions with DNS come in two flavors: forward and reverse
DNS. DNS.
To actually use local addresses within a site, this implies the To actually use local addresses within a site, this implies the
deployment of a "split-faced" or a fragmented DNS name space, for 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 zones internal to the site, and the outsiders' view to it. The
procedures to achieve this are not elaborated here. The implication procedures to achieve this are not elaborated here. The implication
is that local addresses must not be published in the public DNS. is that local addresses must not be published in the public DNS.
To faciliate reverse DNS (if desired) with local addresses, the stub To faciliate reverse DNS (if desired) with local addresses, the stub
resolvers must look for DNS information from the local DNS servers, resolvers must look for DNS information from the local DNS servers,
not e.g. starting from the root servers, so that the local not e.g. starting from the root servers, so that the local
information may be provided locally. Note that the experience of information may be provided locally. Note that the experience of
private addresses in IPv4 has shown that the root servers get loaded private addresses in IPv4 has shown that the root servers get loaded
for requests for private address lookups in any case. This for requests for private address lookups in any case. This
requirement is discussed in [I-D.ietf-ipv6-unique-local-addr]. requirement is discussed in [RFC4193].
Appendix B. Behaviour of Additional Data in IPv4/IPv6 Environments Appendix B. Behaviour of Additional Data in IPv4/IPv6 Environments
DNS responses do not always fit in a single UDP packet. We'll 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 examine the cases which happen when this is due to too much data in
the Additional Section. the Additional Section.
B.1 Description of Additional Data Scenarios B.1. Description of Additional Data Scenarios
There are two kinds of additional data: There are two kinds of additional data:
1. "critical" additional data; this must be included in all 1. "critical" additional data; this must be included in all
scenarios, with all the RRsets, and scenarios, with all the RRsets, and
2. "courtesy" additional data; this could be sent in full, with only 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 a few RRsets, or with no RRsets, and can be fetched separately as
well, but at the cost of additional queries. well, but at the cost of additional queries.
skipping to change at page 27, line 10 skipping to change at page 26, line 46
When there is too much "courtesy" additional data, at least the non- When there is too much "courtesy" additional data, at least the non-
fitting RRsets should be removed [RFC2181]; however, as the fitting RRsets should be removed [RFC2181]; however, as the
additional data is not critical, even all of it could be safely additional data is not critical, even all of it could be safely
removed. removed.
When there is too much "critical" additional data, TC bit will have When there is too much "critical" additional data, TC bit will have
to be set, and the recipient should ignore the response and retry 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 using TCP; if some data were to be left in the UDP response, the
issue is which data could be retained. issue is which data could be retained.
However, the practise may differ from the specification. Testing and
code analysis of 3 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 TC bit
if the response would not otherwise fit.
Failing to discard the response with TC bit or omitting critical Failing to discard the response with TC bit or omitting critical
information but not setting TC bit lead to an unrecoverable problem. information but not setting TC bit lead to an unrecoverable problem.
Omitting only some of the RRsets if all would not fit (but not Omitting only some of the RRsets if all would not fit (but not
setting TC bit) leads to a performance problem. These are discussed setting TC bit) leads to a performance problem. These are discussed
in the next two subsections. in the next two subsections.
B.2 Which Additional Data to Keep, If Any? B.2. Which Additional Data to Keep, If Any?
If the implementation decides to keep as much data (whether If the implementation decides to keep as much data (whether
"critical" or "courtesy") as possible in the UDP responses, it might "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 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 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. IPv6, or return the A records if the query was done over IPv4.
However, this breaks the model of independence of DNS transport and However, this breaks the model of independence of DNS transport and
resource records, as noted in Section 1.2. resource records, as noted in Section 1.2.
With courtesy additional data, as long as enough RRsets will be With courtesy additional data, as long as enough RRsets will be
skipping to change at page 28, line 9 skipping to change at page 28, line 5
That is, leaving in some intelligently selected critical additional That is, leaving in some intelligently selected critical additional
data is a tradeoff between creating an optimization for those data is a tradeoff between creating an optimization for those
resolvers which ignore the "should discard" recommendation, and resolvers which ignore the "should discard" recommendation, and
causing a protocol problem by propagating inconsistent information causing a protocol problem by propagating inconsistent information
about "critical" records in the caches. about "critical" records in the caches.
Similarly, leaving in the complete courtesy additional data RRsets Similarly, leaving in the complete courtesy additional data RRsets
instead of removing all the RRsets is a performance tradeoff as instead of removing all the RRsets is a performance tradeoff as
described in the next section. described in the next section.
B.3 Discussion of the Potential Problems B.3. Discussion of the Potential Problems
As noted above, the temptation for omitting only some of the As noted above, the temptation for omitting only some of the
additional data could be problematic. This is discussed more below. additional data could be problematic. This is discussed more below.
For courtesy additional data, this causes a potential performance For courtesy additional data, this causes a potential performance
problem as this requires that the clients issue re-queries for the problem as this requires that the clients issue re-queries for the
potentially omitted RRsets. For critical additional data, this potentially omitted RRsets. For critical additional data, this
causes a potential unrecoverable problem if the response is not causes a potential unrecoverable problem if the response is not
discarded and the query not re-tried with TCP, as the nameservers discarded and the query not re-tried with TCP, as the nameservers
might be reachable only through the omitted RRsets. might be reachable only through the omitted RRsets.
If an implementation would look at the transport used for the query, If an implementation would look at the transport used for the query,
it is worth remembering that often the host using the records is it is worth remembering that often the host using the records is
different from the node requesting them from the authoritative DNS different from the node requesting them from the authoritative DNS
server (or even a caching resolver). So, whichever version the server (or even a caching resolver). So, whichever version the
requestor (e.g., a recursive server in the middle) uses makes no requestor (e.g., a recursive server in the middle) uses makes no
difference to the ultimate user of the records, whose transport difference to the ultimate user of the records, whose transport
capabilities might differ from those of the requestor. This might capabilities might differ from those of the requestor. This might
result in e.g., inappropriately returning A records to an IPv6-only result in e.g., inappropriately returning A records to an IPv6-only
node, going through a translation, or opening up another IP-level node, going through a translation, or opening up another IP-level
session (e.g., a PDP context [I-D.ietf-v6ops-3gpp-analysis]). session (e.g., a PDP context [RFC4215]). Therefore, at least in many
Therefore, at least in many scenarios, it would be very useful if the scenarios, it would be very useful if the information returned would
information returned would be consistent and complete -- or if that be consistent and complete -- or if that is not feasible, return no
is not feasible, return no misleading information but rather leave it misleading information but rather leave it to the client to query
to the client to query again. again.
The problem of too much additional data seems to be an operational The problem of too much additional data seems to be an operational
one: the zone administrator entering too many records which will be one: the zone administrator entering too many records which will be
returned either truncated (or missing some RRsets, depending on returned either truncated (or missing some RRsets, depending on
implementations) to the users. A protocol fix for this is using implementations) to the users. A protocol fix for this is using
EDNS0 [RFC2671] to signal the capacity for larger UDP packet sizes, EDNS0 [RFC2671] to signal the capacity for larger UDP packet sizes,
pushing up the relevant threshold. Further, DNS server pushing up the relevant threshold. Further, DNS server
implementations should rather omit courtesy additional data implementations should rather omit courtesy additional data
completely rather than including only some RRsets [RFC2181]. An completely rather than including only some RRsets [RFC2181]. An
operational fix for this is having the DNS server implementations operational fix for this is having the DNS server implementations
skipping to change at page 30, line 5 skipping to change at page 29, line 5
server implementations should warn of or disallow such zone server implementations should warn of or disallow such zone
configurations which are recursive or otherwise difficult to manage configurations which are recursive or otherwise difficult to manage
by the protocol. by the protocol.
Additionally, to avoid the case where an application would not get an Additionally, to avoid the case where an application would not get an
address at all due to some of courtesy additional data being omitted, address at all due to some of courtesy additional data being omitted,
the resolvers should be able to query the specific records of the the resolvers should be able to query the specific records of the
desired protocol, not just rely on getting all the required RRsets in desired protocol, not just rely on getting all the required RRsets in
the additional section. the additional section.
Intellectual Property Statement Authors' Addresses
Alain Durand
Comcast
150 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 (2005).
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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 30, line 29 skipping to change at page 30, line 29
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 70 change blocks. 
190 lines changed or deleted 203 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/