[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (RFC 2672) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 RFC 6672

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

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on March 29, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   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

   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


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

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

4.4.  MX and NS Records Require that the DNAME in their RDATA is

   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
   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

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

   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

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

   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


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Rose & Wijngaards        Expires March 29, 2007                [Page 11]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/