DNS Extensions Working Group S. Rose
Internet-Draft VeriSign, Inc.
Intended status: Standards Track W. Wijngaards
Expires: March 29, 2007 NLnet Labs
September 25, 2006
Update to DNAME Redirection
draft-ietf-dnsext-rfc2672bis-dname-00
Status of This Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 29, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
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
particular suffix are redirected to another part of the DNS. Changes
to the DNS protocol since DNAME's introduction has lead to a need to
clarify several issues in the DNAME specification. These issues are
discussed in this document.
Rose & Wijngaards Expires March 29, 2007 [Page 1]
Internet-Draft DNAME Redirection September 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . . 3
3. DNAME according to RFC 2672 . . . . . . . . . . . . . . . . . . 4
3.1. A DNAME in a Zone . . . . . . . . . . . . . . . . . . . . . 4
3.2. DNAME in Responses . . . . . . . . . . . . . . . . . . . . 4
3.3. DNAME Discussions in Other Documents . . . . . . . . . . . 5
4. Issues with DNAME . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. DNAME as Delegation Tool . . . . . . . . . . . . . . . . . 5
4.2. DNAME Apex is not Redirected Itself . . . . . . . . . . . . 5
4.3. DNAME is Always Included in Outgoing Packets. . . . . . . . 6
4.4. MX and NS Records Require that the DNAME in their
RDATA is Canonical . . . . . . . . . . . . . . . . . . . . 6
4.5. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.6. Signaling of DNAME Understanding . . . . . . . . . . . . . 6
4.7. A DNAME is not a Zone-cut . . . . . . . . . . . . . . . . . 6
4.8. DNAME and CIDR Blocks in in-addr.arpa . . . . . . . . . . . 6
4.9. Name Compression in RDATA . . . . . . . . . . . . . . . . . 6
4.10. Synthesized CNAME TTL=0 . . . . . . . . . . . . . . . . . . 7
4.11. Wildcarded DNAME . . . . . . . . . . . . . . . . . . . . . 7
4.12. NSEC3 and DNAME . . . . . . . . . . . . . . . . . . . . . . 7
4.13. PTR Records and DNAME . . . . . . . . . . . . . . . . . . . 7
4.14. Small Corner Cases . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Rose & Wijngaards Expires March 29, 2007 [Page 2]
Internet-Draft DNAME Redirection September 2006
1. Introduction
DNAME is a DNS Resource Record type. DNAME provides redirection from
a part of the DNS name tree to another part of the DNS name tree.
For example, given a query for foo.example.com and a DNAME from
example.com to example.net, the query would be redirected to
foo.example.net. With the same DNAME a query for foo.bar.example.com
is redirected to foo.bar.example.net.
The DNAME RR is similar to the CNAME RR in that it provides
redirection. But where the CNAME RR only provides redirection for
exactly one name, the DNAME RR provides redirection for all names in
a sub-tree of the DNS name tree.
The usage of DNAME lies in redirection of name spaces. An important
use is finer control over delegation, where you want several names to
be directed to the same name server. In other words, you would like
the name spaces below several names to be mapped to the same zone.
Examples in practice are classless reverse address space delegations
and punycode alternates for domain spaces. All the usage examples
envisioned are really for the delegation of multiple different names
below a zone to the same sub-zone, even though the DNAME syntax
permits more bizarre redirection patterns.
[[editors note: In this version of the draft, issues that have been
identified are discussed, and some ideas for proposals are put
forward. Later versions of this document will contain more formal
clarifications or an update to the DNAME specification.]]
2. The DNAME Resource Record
The DNAME RR has mnemonic DNAME and type code 39 (decimal).
The format of the DNAME record has not changed compared to RFC 2672.
DNAME has the following format:
<owner> <ttl> <class> DNAME <target>
The format is not class-sensitive. All fields are required. The
RDATA field target is a domain-name. The compression of the RDATA
field target name issue is covered in a later section.
The DNAME RR causes type NS additional section processing.
DNAME is a singleton type, only one DNAME is allowed per name. No
resource records exist below a DNAME.
Rose & Wijngaards Expires March 29, 2007 [Page 3]
Internet-Draft DNAME Redirection September 2006
CNAME and DNAME are not allowed together for the same name. This is
because no records are allowed next to a CNAME.
DNAMEs cause substitution to happen to query names. There are limits
on the descendants of a name with a DNAME record (none allowed), and
limits on record types allowed for the name that has the DNAME, as
well as loops that are possible due to DNAMEs. These issues are
explained more thoroughly in later sections.
3. DNAME according to RFC 2672
This section presents a clarification of what RFC 2672 says.
3.1. A DNAME in a Zone
x. DNAME y. is like having CNAMEs for all records with domain names
ending in .x to domain names ending in .y. The DNAME RR only impacts
labels below x., such as foo.x., foo.bar.x., but not x. itself. The
DNAME RR allows RRs of other types to be at x with the exception of
RRType CNAME. The DNAME RR above does not allow a CNAME or other
DNAME RRs at x. So a DNAME RRset may only have one RR in it, and
CNAMEs and DNAMEs are mutually exclusive. DNAMEs are valid only for
their CLASS. For a different CLASS different DNAME records are
allowed.
x. DNAME y. does not allow anything to exist below x. Thus, foo.x.,
foo.bar.x are not allowed to have RRs. Their contents are hidden and
ignored. To get their contents the DNAME must be invoked and the
resulting target queried.
3.2. DNAME in Responses
The DNAME RR record is always included in the answer section of a
query. The target name of the DNAME (y.) is to be sent uncompressed
to old resolvers (so the DNAME can be treated as an unknown type).
Compressed if possible. Thus servers must be able to read compressed
or uncompressed target names and write uncompressed names for old
resolvers. See issue on target RDATA compression.
A CNAME RR record with TTL 0 is synthesized for old resolvers,
specifically for the QNAME in the query. DNSSEC [RFC4033],
[RFC4034], [RFC4035] says that the synthesized CNAMEs do not have to
be signed. The DNAME has an RRSIG and a validating resolver can
check the CNAMEs against the DNAME record.
RFC2672 claims that EDNS 0 and less signals non-understanding of
DNAME and DNAME target name compression. EDNS 1 and up may signal
understanding. The EDNS DNSSEC-OK bit signals understanding of
Rose & Wijngaards Expires March 29, 2007 [Page 4]
Internet-Draft DNAME Redirection September 2006
DNAME.
3.3. DNAME Discussions in Other Documents
In [RFC2181] as reference, in Section 10.3., some information is
pertinent, on MX and NS records.:
10.3. MX and NS records (in RFC 2181)
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 an alias. Not only is
the specification clear on this point, but using an alias in either
of these positions neither works as well as might be hoped, nor well
fulfills the ambition that may have led to this approach. This
domain name must have as its value one or more address records.
Currently those will be A records, however in the future other record
types giving addressing information may be acceptable. It can also
have other RRs, but never a CNAME RR.
RFC 4592 [RFC4592] says that DNAMEs are discouraged at wildcards.
DNAMEs and CNAMEs can form loops.
DNAME is discussed in RFC 3363, section 4, on A6 and DNAME. DNAME is
NOT RECOMMENDED for use in the ip6 reverse tree [RFC3363]. And from
[RFC4294], all references to DNAME should have been removed. There
needs to be a better clarification of the status of DNAME in RFC 3363
which would be to drop all constraints on having DNAME RRs in these
zones.
4. Issues with DNAME
There are several issues on DNAME as specified in RFC 2672 [RFC2672].
4.1. DNAME as Delegation Tool
DNAMEs can be used as indirections, the goal of these indirections is
to mirror a part of the DNS domain tree in another part of the DNS
domain tree. This mirroring should be easy. Alternative wording is
that the goal is to have an alias name for a part of the domain tree.
Running example is x DNAME y. The extra point here is that the
mirroring is done at exactly a delegation point. There is a use for
this case.
4.2. DNAME Apex is not Redirected Itself
Since the x is not CNAME'd itself, queries for the DNAME apex RRs are
answered with data at x not at y. The reason for the original
decision was that in this way (without DNAME apex affected) one can
Rose & Wijngaards Expires March 29, 2007 [Page 5]
Internet-Draft DNAME Redirection September 2006
have a DNAME at the zone apex, next to the SOA, NS records, without
problem. And use this to point zones under your operational control
to other zones. Hosting two identical zones for example. Another
reason for excluding the DNAME apex from the DNAME is that one can
then query for the DNAME through RFC 1034 [RFC1034] caches.
4.3. DNAME is Always Included in Outgoing Packets.
Old resolvers or firewalls may drop packets with this unknown RR
type.
4.4. MX and NS Records Require that the DNAME in their RDATA is
Canonical
This means immediately resolve, no CNAMEs no DNAMEs. See the
reference to RFC 2181, Section 10.3 above. Also in RFC 1912
[RFC1912], Section 2.4.
4.5. DNSSEC
For a name error response, the resolver has to check the closest
encloser NSEC to make sure it has no DNAME bit set. If a DNAME had
been present, that DNAME redirection should have been followed.
4.6. Signaling of DNAME Understanding
Some mechanism to signal that CNAMEs need not be synthesized. Also
signal that DNAME target compression can be used (if RDATA target
name compression is allowed at all). EDNS version seems the most
obvious, states the rfc. The gain is compression of the DNAME rname,
and smaller response size.
4.7. A DNAME is not a Zone-cut
A DNAME is not a zone-cut. You may want to use it as such to mirror
a part of the DNS tree, but RFC 2672 DNAME is not usable because the
apex is not redirected.
4.8. DNAME and CIDR Blocks in in-addr.arpa
Is DNAME the Way to go for CIDR Blocks in in-addr.arpa? Should this
be addressed by this document?
4.9. Name Compression in RDATA
For old versions of servers only uncompressed is possible. New
version can still choose to use compressed or not.
Rose & Wijngaards Expires March 29, 2007 [Page 6]
Internet-Draft DNAME Redirection September 2006
Clarify on compression proposal: Senders SHOULD NOT compress RDATA,
receivers MUST be able to decompress, when the new version has been
negotiated with the EDNS bits.
4.10. Synthesized CNAME TTL=0
In the original specification, all synthesized CNAME RRs had a TTL of
0. Due to DNSSEC TTL=0 interpretation had to be changed to mean
"keep as long as the query using this RRset is still being
processed". What is the status of this CNAME?
This could be synthesized CNAMEs should have a TTL equal to the TTL
of the DNAME. This allows non-aware clients to cache the CNAMEs and
thus lightens the load on authoritative servers.
4.11. Wildcarded DNAME
What should happen with a wildcard with RRtype DNAME, i.e.
*.example.com DNAME example.net. RFC 4592 [RFC4592] discourages
this. Behaviour unspecified (strict interpretation of RFC 2672 says
that for queries for which the wildcard is expanded, no DNAME
processing occurs, and for queries for the '*' label
('foo.*.example.com') the DNAME is followed.).
4.12. NSEC3 and DNAME
NSEC3 uses hashing to obscure names. This hashing can be expensive
to compute. A zone that has DNAME and NSEC3 may have to do
additional hashing for NSEC3 lookups. More work needs to be done to
look into this and see what computational costs are involved.
4.13. PTR Records and DNAME
PTR records in the reverse zone must have canonical names as their
RDATA, like NS and MX records. The lookup process for PTR records
owner names may involve DNAME/CNAME records, but the lookup process
for PTR records RDATA names may not. RFC 1912. More problematic
than NS and MX in operational sense, since the reverse zone may not
be under the control of the zone operator.
4.14. Small Corner Cases
There are also some corner cases to discuss and clarify. These are
small issues, but additional examples can give more guidance to
implementors. [[editors note: The following is to be expanded]]
Rose & Wijngaards Expires March 29, 2007 [Page 7]
Internet-Draft DNAME Redirection September 2006
1. Example of why DNSSEC validators MUST understand DNAME.
2. Examples of the DNAME name substitution. whole labels only, name
can get longer and shorter. The '*' label is handled as a fixed
string during substitution. apex is not substituted. name can get
too long.
3. Corner case: queries for synthesized CNAME. Not a problem,
current algorithm already creates the CNAME again from the DNAME
for such a query and follows the chain of DNAME/CNAMEs. Server
reminded that it must return no error.
4. Corner case: loops with single DNAME record possible. Loop: x
DNAME y.x. Loop: x DNAME x. Loop: x DNAME "." for queries
qname=a.x.x
5. Servers must not allow zones to be loaded below a DNAME. This is
similar to requesting to not load a zone when a domain name below
a DNAME contains resource records, as the RFC requests.
6. Caches must not allow data to be cached below a DNAME. CNAMES
below a DNAME must be re-synthesized from the DNAME, or checked
against the DNAME if needed.
5. IANA Considerations
The main purpose of this draft is to discuss issues related to the
use of DNAME RRs in a DNS zone. The results of these discussions may
result in a new RR to augment or replace DNAME, which will require
IANA action. Any solutions that propose this will be contained in a
following document and not this draft.
6. Security Considerations
DNAME redirects queries elsewhere, which may impact security based on
policy and the security status of the zone with the DNAME and the
redirection zone's security status. This document only discusses
issues regarding the DNAME specification. Any clarification or
replacement RR type will have different security considerations.
These will be stated in a following document.
7. Acknowledgements
The authors of this draft would like to acknowledge Matt Larson for
beginning this effort to addres the issues related to the DNAME RR
type.
8. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1912] Barr, D., "Common DNS Operational and Configuration
Rose & Wijngaards Expires March 29, 2007 [Page 8]
Internet-Draft DNAME Redirection September 2006
Errors", RFC 1912, February 1996.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
RFC 2672, August 1999.
[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
Hain, "Representing Internet Protocol version 6 (IPv6)
Addresses in the Domain Name System (DNS)", RFC 3363,
August 2002.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
April 2006.
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
System", RFC 4592, July 2006.
Authors' Addresses
Scott Rose
VeriSign, Inc.
21345 Ridgetop Circle
Dulles, VA 20166-6503
USA
Phone: +1-703-948-3364
Fax: +1-...
EMail: srose@verisign.com
Rose & Wijngaards Expires March 29, 2007 [Page 9]
Internet-Draft DNAME Redirection September 2006
Wouter Wijngaards
NLnet Labs
Kruislaan 419
Amsterdam 1098 VA
The Netherlands
Phone: +31-20-888-4551
Fax: +31-20-888-4462
EMail: wouter@nlnetlabs.nl
Rose & Wijngaards Expires March 29, 2007 [Page 10]
Internet-Draft DNAME Redirection September 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Rose & Wijngaards Expires March 29, 2007 [Page 11]
