draft-ietf-dnsext-rfc2672bis-dname-22.txt   draft-ietf-dnsext-rfc2672bis-dname-23.txt 
DNS Extensions Working Group S. Rose DNS Extensions Working Group S. Rose
Internet-Draft NIST Internet-Draft NIST
Obsoletes: 2672 (if approved) W. Wijngaards Obsoletes: 2672 (if approved) W. Wijngaards
Updates: 3363,4294 NLnet Labs Updates: 3363,4294 (if approved) NLnet Labs
(if approved) May 2, 2011 Intended status: Standards Track June 24, 2011
Intended status: Standards Track Expires: December 26, 2011
Expires: November 3, 2011
Update to DNAME Redirection in the DNS Update to DNAME Redirection in the DNS
draft-ietf-dnsext-rfc2672bis-dname-22 draft-ietf-dnsext-rfc2672bis-dname-23
Abstract Abstract
The DNAME record provides redirection for a sub-tree of the domain The DNAME record provides redirection for a sub-tree of the domain
name tree in the DNS system. That is, all names that end with a name tree in the DNS system. That is, all names that end with a
particular suffix are redirected to another part of the DNS. This is particular suffix are redirected to another part of the DNS. This is
a revision of the original specification in RFC 2672, also aligning a revision to the original specification in RFC 2672 as well as
RFC 3363 and RFC 4294 with this revision. updating RFC 3363 and RFC 4294 to align with this revision.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 43 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on November 3, 2011. This Internet-Draft will expire on December 26, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 21 skipping to change at page 3, line 21
2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 5 2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 5
2.3. DNAME Owner Name Matching the QNAME . . . . . . . . . . . 7 2.3. DNAME Owner Name Matching the QNAME . . . . . . . . . . . 7
2.4. Names Next to and Below a DNAME Record . . . . . . . . . . 7 2.4. Names Next to and Below a DNAME Record . . . . . . . . . . 7
2.5. Compression of the DNAME record. . . . . . . . . . . . . . 7 2.5. Compression of the DNAME record. . . . . . . . . . . . . . 7
3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. CNAME synthesis . . . . . . . . . . . . . . . . . . . . . 8 3.1. CNAME synthesis . . . . . . . . . . . . . . . . . . . . . 8
3.2. Server algorithm . . . . . . . . . . . . . . . . . . . . . 9 3.2. Server algorithm . . . . . . . . . . . . . . . . . . . . . 9
3.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4. Acceptance and Intermediate Storage . . . . . . . . . . . 11 3.4. Acceptance and Intermediate Storage . . . . . . . . . . . 11
3.4.1. Resolver Algorithm . . . . . . . . . . . . . . . . . . 11
4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 11 4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 12
5. Other Issues with DNAME . . . . . . . . . . . . . . . . . . . 13 5. Other Issues with DNAME . . . . . . . . . . . . . . . . . . . 14
5.1. Canonical hostnames cannot be below DNAME owners . . . . . 13 5.1. Canonical hostnames cannot be below DNAME owners . . . . . 14
5.2. Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 13 5.2. Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 14
5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 13 5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 14
5.3.1. Signed DNAME, Unsigned Synthesized CNAME . . . . . . . 13 5.3.1. Signed DNAME, Unsigned Synthesized CNAME . . . . . . . 14
5.3.2. DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 14 5.3.2. DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 15
5.3.3. DNAME Chains as Strong as the Weakest Link . . . . . . 14 5.3.3. DNAME Chains as Strong as the Weakest Link . . . . . . 15
5.3.4. Validators Must Understand DNAME . . . . . . . . . . . 14 5.3.4. Validators Must Understand DNAME . . . . . . . . . . . 15
5.3.4.1. DNAME in Bitmap Causes Invalid Name Error . . . . 14 5.3.4.1. DNAME in Bitmap Causes Invalid Name Error . . . . 15
5.3.4.2. Valid Name Error Response Involving DNAME in 5.3.4.2. Valid Name Error Response Involving DNAME in
Bitmap . . . . . . . . . . . . . . . . . . . . . . 15 Bitmap . . . . . . . . . . . . . . . . . . . . . . 16
5.3.4.3. Response With Synthesized CNAME . . . . . . . . . 15 5.3.4.3. Response With Synthesized CNAME . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. Examples of DNAME Use in a Zone . . . . . . . . . . . . . . . 16
6.1. Organizational Renaming . . . . . . . . . . . . . . . . . 16
6.2. Classless Delegation of Shorter Prefixes . . . . . . . . . 17
6.3. Network Renumbering Support . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
DNAME is a DNS Resource Record type originally defined in RFC 2672 DNAME is a DNS Resource Record type originally defined in RFC 2672
[RFC2672]. DNAME provides redirection from a part of the DNS name [RFC2672]. DNAME provides redirection from a part of the DNS name
tree to another part of the DNS name tree. tree to another part of the DNS name tree.
The DNAME RR and the CNAME RR [RFC1034] cause a lookup to The DNAME RR and the CNAME RR [RFC1034] cause a lookup to
(potentially) return data corresponding to a domain name different (potentially) return data corresponding to a domain name different
from the queried domain name. The difference between the two from the queried domain name. The difference between the two
skipping to change at page 4, line 40 skipping to change at page 4, line 40
renumbering. With a careful set-up, a renumbering event in the renumbering. With a careful set-up, a renumbering event in the
network causes no change to the authoritative server that has the network causes no change to the authoritative server that has the
address-to-name mappings. Examples in practice are classless reverse address-to-name mappings. Examples in practice are classless reverse
address space delegations. address space delegations.
Another usage of DNAME lies in aliasing of name spaces. For example, Another usage of DNAME lies in aliasing of name spaces. For example,
a zone administrator may want sub-trees of the DNS to contain the a zone administrator may want sub-trees of the DNS to contain the
same information. Examples include punycode alternates for domain same information. Examples include punycode alternates for domain
spaces. spaces.
This revision to DNAME does not change the wire format or the This update to DNAME does not change the wire format or the handling
handling of DNAME Resource Records. Discussion is added on problems of DNAME Resource Records. Discussion is added on problems that may
that may be encountered when using DNAME. be encountered when using DNAME.
2. The DNAME Resource Record 2. The DNAME Resource Record
2.1. Format 2.1. Format
The DNAME RR has mnemonic DNAME and type code 39 (decimal). It is The DNAME RR has mnemonic DNAME and type code 39 (decimal). It is
not class-sensitive. not class-sensitive.
Its RDATA is comprised of a single field, <target>, which contains a Its RDATA is comprised of a single field, <target>, which contains a
fully qualified domain name that must be sent in uncompressed form fully qualified domain name that must be sent in uncompressed form
skipping to change at page 8, line 23 skipping to change at page 8, line 23
had a meaning for understanding of DNAME and DNAME target name had a meaning for understanding of DNAME and DNAME target name
compression. This document revises RFC 2672, in that there is no compression. This document revises RFC 2672, in that there is no
EDNS version signaling for DNAME. EDNS version signaling for DNAME.
3. Processing 3. Processing
3.1. CNAME synthesis 3.1. CNAME synthesis
When preparing a response, a server performing a DNAME substitution When preparing a response, a server performing a DNAME substitution
will in all cases include the relevant DNAME RR in the answer will in all cases include the relevant DNAME RR in the answer
section. Relevant includes the following cases: section. Relevant cases includes the following:
1. The DNAME is being employed as a substitution instruction. 1. The DNAME is being employed as a substitution instruction.
2. The DNAME itself matches the QTYPE and the owner name matches 2. The DNAME itself matches the QTYPE and the owner name matches
QNAME. QNAME.
When the owner name name matches the QNAME and the QTYPE matches When the owner name name matches the QNAME and the QTYPE matches
another type owned there, the DNAME is not included in the answer. another type owned there, the DNAME is not included in the answer.
A CNAME RR with TTL equal to the corresponding DNAME RR is A CNAME RR with TTL equal to the corresponding DNAME RR is
synthesized and included in the answer section when the DNAME is synthesized and included in the answer section when the DNAME is
employed as a substitution instruction. The owner name of the CNAME employed as a substitution instruction. The owner name of the CNAME
is the QNAME of the query. The DNSSEC specification [RFC4033], is the QNAME of the query. The DNSSEC specification [RFC4033],
[RFC4034], [RFC4035] says that the synthesized CNAME does not have to [RFC4034], [RFC4035] says that the synthesized CNAME does not have to
be signed. The DNAME has an RRSIG and a validating resolver can be signed. The signed DNAME has an RRSIG and a validating resolver
check the CNAME against the DNAME record and validate the signature can check the CNAME against the DNAME record and validate the
over the DNAME RR. signature over the DNAME RR.
Servers MUST be able to answer a query for a synthesized CNAME. Like Servers MUST be able to answer a query for a synthesized CNAME. Like
other query types this invokes the DNAME, and synthesizes the CNAME other query types this invokes the DNAME, and then the server
into the answer. If the server in question is a cache, the synthesizes the CNAME and places it into the answer section. If the
synthesized CNAME's TTL SHOULD be equal to the decremented TTL of the server in question is a cache, the synthesized CNAME's TTL SHOULD be
cached DNAME. equal to the decremented TTL of the cached DNAME.
Resolvers MUST be able to handle a synthesized CNAME TTL of zero or Resolvers MUST be able to handle a synthesized CNAME TTL of zero or
equal to the TTL of the corresponding DNAME record (as some older equal to the TTL of the corresponding DNAME record (as some older
authoritative server implementations set the TTL of synthesized authoritative server implementations set the TTL of synthesized
CNAMEs to zero). A TTL of zero means that the CNAME can be discarded CNAMEs to zero). A TTL of zero means that the CNAME can be discarded
immediately after processing the answer. immediately after processing the answer.
3.2. Server algorithm 3.2. Server algorithm
Below is the server algorithm, which appeared in RFC 2672 Section Below is the server algorithm, which appeared in RFC 2672 Section
skipping to change at page 11, line 35 skipping to change at page 11, line 35
where data from before and after the change resides in the cache. where data from before and after the change resides in the cache.
This conflict situation is a transitional phase that ends when the This conflict situation is a transitional phase that ends when the
old data times out. The caching name server can opt to store both old data times out. The caching name server can opt to store both
old and new data and treat each as if the other did not exist, or old and new data and treat each as if the other did not exist, or
drop the old data, or drop the longer domain name. In any approach, drop the old data, or drop the longer domain name. In any approach,
consistency returns after the older data TTL times out. consistency returns after the older data TTL times out.
Recursive caching name servers MUST perform CNAME synthesis on behalf Recursive caching name servers MUST perform CNAME synthesis on behalf
of clients. of clients.
If a recursive caching name server encounters a DNAME RR which If a recursive caching name server encounters a DNSSEC validated
contradicts information already in the cache (excluding CNAME DNAME RR which contradicts information already in the cache
records), it SHOULD NOT cache the DNAME RR, but it MAY cache the (excluding CNAME records), it SHOULD cache the DNAME RR, but it MAY
CNAME record received along with it, subject to the rules for CNAME. cache the CNAME record received along with it, subject to the rules
for CNAME. If the DNAME RR cannot be validated via DNSSEC (i.e. not
BOGUS, but not able to validate), the recursive caching server SHOULD
NOT cache the DNAME RR but MAY cache the CNAME record received along
with it, subject to the rules of CNAME.
3.4.1. Resolver Algorithm
A resolver algorithm likewise changes to handle DNAME processing.
The complete algorithm becomes:
1. See if the answer is in local information or can be synthesized
from a cached DNAME, and if so return it to the client.
2. Find the best servers to ask.
3. Send queries until one returns a response.
4. Analyze the response, either:
A. If the response answers the question or contains a name
error, cache the data as well as returning it back to the
client.
B. If the response contains a better delegation to other
servers, cache the delegation information, and go to step 2.
C. If the response shows a CNAME and that is not the answer
itself, cache the CNAME, change the SNAME to the canonical
name in the CNAME RR and go to step 1.
D. If the response shows a DNAME and that is not the answer
itself, cache the DNAME (upon successful DNSSEC validation if
the client is a validating resolver). If substitution of the
DNAME's target name for its owner name in the SNAME would
overflow the legal size for a domain name, return an
implementation-dependent error to the application; otherwise
perform the substitution and go to step 1.
E. If the response shows a server failure or other bizarre
contents, delete the server from the SLIST and go back to
step 3.
4. DNAME Discussions in Other Documents 4. DNAME Discussions in Other Documents
In [RFC2181], in Section 10.3., the discussion on MX and NS records In [RFC2181], in Section 10.3., the discussion on MX and NS records
touches on redirection by CNAMEs, but this also holds for DNAMEs. touches on redirection by CNAMEs, but this also holds for DNAMEs.
Excerpt from 10.3. MX and NS records (in RFC 2181). Excerpt from 10.3. MX and NS records (in RFC 2181).
The domain name used as the value of a NS resource record, The domain name used as the value of a NS resource record,
or part of the value of a MX resource record must not be or part of the value of a MX resource record must not be
skipping to change at page 12, line 24 skipping to change at page 13, line 24
records. Currently those will be A records, however in records. Currently those will be A records, however in
the future other record types giving addressing the future other record types giving addressing
information may be acceptable. It can also have other information may be acceptable. It can also have other
RRs, but never a CNAME RR. RRs, but never a CNAME RR.
The DNAME RR is discussed in RFC 3363, section 4, on A6 and DNAME. The DNAME RR is discussed in RFC 3363, section 4, on A6 and DNAME.
The opening premise of this section is demonstrably wrong, and so the The opening premise of this section is demonstrably wrong, and so the
conclusion based on that premise is wrong. In particular, [RFC3363] conclusion based on that premise is wrong. In particular, [RFC3363]
deprecates the use of DNAME in the IPv6 reverse tree, which is then deprecates the use of DNAME in the IPv6 reverse tree, which is then
carried forward as a recommendation in [RFC4294]. Based on the carried forward as a recommendation in [RFC4294]. Based on the
experience gained in the meantime, [RFC3363] should be revised, experience gained in the meantime, [RFC3363] is revised, dropping all
dropping all constraints on having DNAME RRs in these zones. This constraints on having DNAME RRs in these zones. This would greatly
would greatly improve the manageability of the IPv6 reverse tree. improve the manageability of the IPv6 reverse tree. These changes
These changes are made explicit below. are made explicit below.
In [RFC3363], the paragraph In [RFC3363], the paragraph
"The issues for DNAME in the reverse mapping tree appears to be "The issues for DNAME in the reverse mapping tree appears to be
closely tied to the need to use fragmented A6 in the main tree: if closely tied to the need to use fragmented A6 in the main tree: if
one is necessary, so is the other, and if one isn't necessary, the one is necessary, so is the other, and if one isn't necessary, the
other isn't either. Therefore, in moving RFC 2874 to experimental, other isn't either. Therefore, in moving RFC 2874 to experimental,
the intent of this document is that use of DNAME RRs in the reverse the intent of this document is that use of DNAME RRs in the reverse
tree be deprecated." tree be deprecated."
skipping to change at page 15, line 43 skipping to change at page 16, line 43
The response shown above has the synthesized CNAME included. The response shown above has the synthesized CNAME included.
However, the CNAME has no signature, since the server does not sign However, the CNAME has no signature, since the server does not sign
online. So this response cannot be trusted. It could be altered by online. So this response cannot be trusted. It could be altered by
an attacker to be foo.bar.example.com CNAME bla.bla.example. The an attacker to be foo.bar.example.com CNAME bla.bla.example. The
DNAME record does have its signature included, since it does not DNAME record does have its signature included, since it does not
change. The validator must verify the DNAME signature and then change. The validator must verify the DNAME signature and then
recursively resolve further to query for the foo.bar.example.net A recursively resolve further to query for the foo.bar.example.net A
record. record.
6. IANA Considerations 6. Examples of DNAME Use in a Zone
Below are some examples of the use of DNAME in a zone. These
examples are by no means exhaustive.
6.1. Organizational Renaming
If an organization with domain name FROBOZZ.EXAMPLE.NET became part
of an organization with domain name ACME.EXAMPLE.COM, it might ease
transition by placing information such as this in its old zone.
frobozz.example.net. DNAME frobozz-division.acme.example.com.
MX 10 mailhub.acme.example.com.
The response to an extended recursive query for
www.frobozz.example.net would contain, in the answer section, the
DNAME record shown above and the relevant RRs for www.frobozz-
division.acme.example.com.
If an organization wants to have aliases for names, for a different
spelling or language, the same example applies. Note that the MX RR
at the zone apex is not redirected and has to be repeated in the
target zone. Also note that the services at mailhub or www.frobozz-
division.acme.example.com. have to recognize and handle the aliases.
6.2. Classless Delegation of Shorter Prefixes
The classless scheme for in-addr.arpa delegation [RFC2317] can be
extended to prefixes shorter than 24 bits by use of the DNAME record.
For example, the prefix 192.0.8.0/22 can be delegated by the
following records.
$ORIGIN 0.192.in-addr.arpa.
8/22 NS ns.slash-22-holder.example.com.
8 DNAME 8.8/22
9 DNAME 9.8/22
10 DNAME 10.8/22
11 DNAME 11.8/22
A typical entry in the resulting reverse zone for some host with
address 192.0.9.33 might be
$ORIGIN 8/22.0.192.in-addr.arpa.
33.9 PTR somehost.slash-22-holder.example.com.
The same advisory remarks concerning the choice of the "/" character
apply here as in [RFC2317] .
6.3. Network Renumbering Support
If IPv4 network renumbering were common, maintenance of address space
delegation could be simplified by using DNAME records instead of NS
records to delegate.
$ORIGIN new-style.in-addr.arpa.
189.190 DNAME in-addr.example.net.
$ORIGIN in-addr.example.net.
188 DNAME in-addr.customer.example.com.
$ORIGIN in-addr.customer.example.
1 PTR www.customer.example.com
2 PTR mailhub.customer.example.com.
; etc ...
This would allow the address space 190.189.0.0/16 assigned to the ISP
"example.net" to be changed without the necessity of altering the
zone files describing the use of that space by the ISP and its
customers.
Renumbering IPv4 networks is currently so arduous a task that
updating the DNS is only a small part of the labor, so this scheme
may have a low value. But it is hoped that in IPv6 the renumbering
task will be quite different and the DNAME mechanism may play a
useful part.
7. IANA Considerations
The DNAME Resource Record type code 39 (decimal) originally has been The DNAME Resource Record type code 39 (decimal) originally has been
registered by [RFC2672]. IANA should update the DNS resource record registered by [RFC2672]. IANA should update the DNS resource record
registry to point to this document for RR type 39. registry to point to this document for RR type 39.
7. Security Considerations 8. Security Considerations
DNAME redirects queries elsewhere, which may impact security based on DNAME redirects queries elsewhere, which may impact security based on
policy and the security status of the zone with the DNAME and the policy and the security status of the zone with the DNAME and the
redirection zone's security status. For validating resolvers, the redirection zone's security status. For validating resolvers, the
lowest security status of the links in the chain of CNAME and DNAME lowest security status of the links in the chain of CNAME and DNAME
redirections is applied to the result. redirections is applied to the result.
If a validating resolver accepts wildcarded DNAMEs, this creates If a validating resolver accepts wildcarded DNAMEs, this creates
security issues. Since the processing of a wildcarded DNAME is non- security issues. Since the processing of a wildcarded DNAME is non-
deterministic and the CNAME that was substituted by the server has no deterministic and the CNAME that was substituted by the server has no
signature, the resolver may choose a different result than what the signature, the resolver may choose a different result than what the
server meant, and consequently end up at the wrong destination. Use server meant, and consequently end up at the wrong destination. Use
of wildcarded DNAMEs is discouraged in any case [RFC4592]. of wildcarded DNAMEs is discouraged in any case [RFC4592].
A validating resolver MUST understand DNAME, according to [RFC4034]. A validating resolver MUST understand DNAME, according to [RFC4034].
The examples in Section 5.3.4 illustrate this need. The examples in Section 5.3.4 illustrate this need.
8. Acknowledgments 9. Acknowledgments
The authors of this draft would like to acknowledge Matt Larson for The authors of this draft would like to acknowledge Matt Larson for
beginning this effort to address the issues related to the DNAME RR beginning this effort to address the issues related to the DNAME RR
type. The authors would also like to acknowledge Paul Vixie, Ed type. The authors would also like to acknowledge Paul Vixie, Ed
Lewis, Mark Andrews, Mike StJohns, Niall O'Reilly, Sam Weiler, Alfred Lewis, Mark Andrews, Mike StJohns, Niall O'Reilly, Sam Weiler, Alfred
Hoenes and Kevin Darcy for their review and comments on this Hoenes and Kevin Darcy for their review and comments on this
document. document.
9. References 10. References
9.1. Normative References 10.1. Normative References
[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.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-
ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003. (RR) Types", RFC 3597, September 2003.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
skipping to change at page 17, line 25 skipping to change at page 20, line 15
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, March 2005.
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
System", RFC 4592, July 2006. System", RFC 4592, July 2006.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008. Existence", RFC 5155, March 2008.
9.2. Informative References 10.2. Informative References
[RFC1912] Barr, D., "Common DNS Operational and Configuration [RFC1912] Barr, D., "Common DNS Operational and Configuration
Errors", RFC 1912, February 1996. Errors", RFC 1912, February 1996.
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
RFC 2672, August 1999. RFC 2672, August 1999.
[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
Hain, "Representing Internet Protocol version 6 (IPv6) Hain, "Representing Internet Protocol version 6 (IPv6)
Addresses in the Domain Name System (DNS)", RFC 3363, Addresses in the Domain Name System (DNS)", RFC 3363,
 End of changes. 25 change blocks. 
51 lines changed or deleted 176 lines changed or added

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