DNS Extensions Working Group                                     S. Rose
Internet-Draft                                            VeriSign, Inc.                                                      NIST
Intended status: Standards Track                           W. Wijngaards
Expires: March 29, July 26, 2007                                        NLnet Labs
                                                      September 25, 2006
                                                        January 22, 2007

                 Update to DNAME Redirection
                 draft-ietf-dnsext-rfc2672bis-dname-00 in the DNS
                 draft-ietf-dnsext-rfc2672bis-dname-01

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, July 26, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006). IETF Trust (2007).

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  This is
   an update to the DNS protocol since DNAME's introduction has lead to a need to
   clarify several issues original specification in the DNAME specification.  These issues are
   discussed RFC 2672.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document.
   document are to be interpreted as described in RFC 2119 [RFC2119].

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  The DNAME Resource Record  . . . . . . . . . . . . . . . . . . .  3

   3.  DNAME according to RFC 2672 . . . . . . . . . . . .
     2.1.  Format . . . . . . 4
     3.1.  A DNAME in a Zone . . . . . . . . . . . . . . . . . . . . . 4
     3.2.  3
     2.2.  The DNAME in Responses  . . Substitution . . . . . . . . . . . . . . . . . .  4
     3.3.
     2.3.  Names next-to and below a DNAME Discussions in Other Documents  . record . . . . . . . . . .  5

   4.  Issues with
     2.4.  Compression of the DNAME record. . . . . . . . . . . . . .  5

   3.  Processing . . . . . . . . . . 5
     4.1.  DNAME as Delegation Tool  . . . . . . . . . . . . . . . . .  5
     4.2.  DNAME Apex is not Redirected Itself . . . .
     3.1.  Wildcards  . . . . . . . . 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 . . . . . . . . .  5
     3.2.  DNAME bit in NSEC type map . . . . . . . . . . . 6
     4.5.  DNSSEC . . . . .  6
     3.3.  CNAME synthesis  . . . . . . . . . . . . . . . . . . . . .  6
     4.6.  Signaling of DNAME Understanding
     3.4.  Processing . . . . . . . . . . . . . 6
     4.7.  A DNAME is not a Zone-cut . . . . . . . . . . . . . . . . .  6
     4.8.

   4.  DNAME and CIDR Blocks Discussions in in-addr.arpa . . . . Other Documents . . . . . . . 6
     4.9.  Name Compression in RDATA . . . . . .  7

   5.  Issues with DNAME  . . . . . . . . . . . 6
     4.10. Synthesized CNAME TTL=0 . . . . . . . . . . .  7
     5.1.  DNAME Apex not Redirected itself . . . . . . . 7
     4.11. Wildcarded DNAME . . . . . .  8
     5.2.  MX, NS and PTR Records Must Point to Target of DNAME . . .  8
     5.3.  NSEC3 and DNAME  . . . . . . . . . . . . 7
     4.12. NSEC3 and DNAME . . . . . . . . .  8
     5.4.  Validators Must Understand DNAME . . . . . . . . . . . . . 7
     4.13. PTR Records and  9
       5.4.1.  DNAME in Bitmap Causes Invalid Name Error  . . . . . .  9
       5.4.2.  Valid Name Error Response Involving DNAME in Bitmap  .  9
       5.4.3.  Response With Synthesized CNAME  . . . . . . . . . . .  9

   6.  IANA Considerations  . 7
     4.14. Small Corner Cases . . . . . . . . . . . . . . . . . . . . 7

   5.  IANA 10

   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10

   8.  Document History . . . 8

   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8

   7.  Acknowledgements 10

   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 8

   8. 11

   10. Normative References . . . . . . . . . . . . . . . . . . . . . 8 11

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

   This document is an update to the original specification of DNAME lies in redirection of name spaces.  An important
   use is finer control over delegation, where you want several names
   RFC 2672 [RFC2672], by Matt Crawford.  DNAME was conceived to
   be directed help
   with the problem of maintaining address-to-name mappings in a context
   of network renumbering.  So that with a careful set-up a renumbering
   event in the network causes no change to the same name server.  In other words, you would like authoritative server
   that has the address-to-name mappings.

   Other usage of DNAME lies in redirection of name spaces below several names to be mapped spaces.  Where a
   zone administrator want subtrees of the DNS to contain the same zone.
   information.  Examples in practice are classless reverse address
   space delegations and punycode alternates for domain spaces.  All the usage examples
   envisioned are really  DNAME
   is also used for the delegation redirection of multiple different names
   below a zone ENUM domains to another maintaining
   party.

   This update to the same sub-zone, even though the DNAME syntax
   permits more bizarre redirection patterns.

   [[editors note: In this version of does not change 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 wire format, or an update to the handling
   of DNAME specification.]] Resource Records by existing software.  Discussion is added
   on the problems that can be encountered when using DNAME.

2.  The DNAME Resource Record

2.1.  Format

   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.
   MUST be sent uncompressed [RFC3597].

   The DNAME RR causes type NS additional section processing.

2.2.  The DNAME is a singleton type, only one DNAME is allowed per name.  No
   resource records exist below a DNAME.

   CNAME and DNAME are not allowed together for the same name.  This is
   because no records are allowed next to a CNAME. Substitution

   DNAMEs cause a name substitution to happen to query names.  There are limits
   on  This is
   called The DNAME Substitution.  The suffix ownername of the descendants DNAME is
   replaced by the target of a the DNAME.  The owner name with a of the DNAME record (none allowed), and
   limits on record types allowed for is
   not itself redirected, only domain names below the owner name that has the DNAME, as
   well as loops that are possible due to DNAMEs.  These issues
   redirected.  Only whole labels 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. replaced.  A DNAME in a Zone

   x.  DNAME y. name 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 considered
   below x., such as foo.x., foo.bar.x., but not x. itself. the owner name if it has more labels than the owner name, and
   the labels of the owner name appear at the end of the name.  See the
   table of examples for common cases and corner cases.

   In the table below, the QNAME refers to the query name.  The owner is
   the DNAME RR allows RRs of other types owner domain name, and the target refers to be at x with the exception target of
   RRType CNAME.
   the DNAME record.  The result is the resulting name of performing the
   DNAME RR above does Substitution on the query name. "no match" means that the query
   did not allow a CNAME or other match the DNAME RRs at and thus no substitution is performed, the
   QNAME did not change.  The examples 'cyc' and 'shortloop' contain
   loops.

    QNAME            owner  DNAME   target         result
    ---------------- -------------- -------------- -----------------
    com.             example.com.   example.net.   <no match>
    example.com.     example.com.   example.net.   <no match>
    a.example.com.   example.com.   example.net.   a.example.net.
    a.b.example.com. example.com.   example.net.   a.b.example.net.
    ab.example.com.  b.example.com. example.net.   <no match>
    foo.example.com. example.com.   example.net.   foo.example.net.
    a.x.example.com. x.example.com. example.net.   a.example.net.
    a.example.com.   example.com.   y.example.net. a.y.example.net.
    cyc.example.com. example.com.   example.com.   cyc.example.com.
    cyc.example.com. example.com.   c.example.com. cyc.c.example.com.
    shortloop.x.x.   x.  So a             .              shortloop.x.
    shortloop.x.     x.             .              shortloop.

                    Table. DNAME RRset may only have one RR in it, Substitution Examples.

   It is possible for DNAMEs to form loops.  Just like CNAMEs can form
   loops.  DNAMEs and CNAMEs can chain together to form loops.  A single
   corner case DNAME can form a loop.  Resolvers and servers should be
   cautious in devoting resources to a query, but be aware that fairly
   long chains of DNAMEs may be valid.

   The domain name can get too long during substitution.  If this occurs
   the server returns an RCODE of YXDOMAIN [RFC2136].  The DNAME record
   and its signature are mutually exclusive.  DNAMEs are valid only included in the answer as proof for
   their CLASS.  For the
   YXDOMAIN (value 6) RCODE.

2.3.  Names next-to and below a different CLASS different DNAME record

   Other resource records are
   allowed.

   x.  DNAME y. does not allow anything to MUST NOT exist below x.  Thus, foo.x.,
   foo.bar.x are not allowed to have RRs.  Their contents are hidden and
   ignored. a DNAME.  To get their the
   contents for names below a DNAME, the DNAME redirection must be
   invoked and the resulting target queried.

3.2.  DNAME in Responses

   The  A server SHOULD refuse to
   load a zone that has data below a domain with a DNAME resource
   record.  Also a server SHOULD refuse to load a zone beneath a DNAME RR
   record from another zone.

   DNAME is always included in the answer section of a
   query. singleton type, only one DNAME is allowed per name.  The target
   owner name of the that has a DNAME, can only have one DNAME (y.) is RR, and no CNAME
   RRs can exist at that name.  These rules make sure that for a single
   domain name only one redirection exists, and thus no confusion which
   one to be sent uncompressed follow.  A server SHOULD refuse to old resolvers (so load a zone that violates
   these rules.

   These rules allow DNAME records to be queried through DNAME unaware
   caches.

2.4.  Compression of the DNAME record.

   The DNAME owner name 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 like any other owner name.
   The target DNAME RDATA compression.

   A CNAME RR record with TTL 0 is synthesized for old resolvers,
   specifically for the QNAME name of MUST NOT be sent out in the query.  DNSSEC [RFC4033],
   [RFC4034], [RFC4035] says compressed
   form, so that the synthesized CNAMEs do not have to
   be signed.  The DNAME has an RRSIG and a validating resolver can
   check be treated as an unknown type.

   Although the CNAMEs against previous specification talked about signaling to allow
   compression of the DNAME record. target name, no such signaling is done.  Signaling
   complicates the protocol unnecessarily.

   RFC2672 claims claimed that the EDNS 0 and less signals non-understanding version had a meaning for understanding
   of DNAME and DNAME target name compression.  This document updates
   RFC2672, there is no EDNS 1 and up may signal
   understanding. version signaling for DNAME.

3.  Processing

3.1.  Wildcards

   The EDNS DNSSEC-OK bit signals understanding use of
   DNAME.

3.3. DNAME Discussions in Other Documents

   In [RFC2181] as reference, in Section 10.3., some information conjunction with wildcards is
   pertinent, on MX and NS records.:

   10.3.  MX and NS discouraged
   [RFC4592].  Thus records (in RFC 2181) of the form "*.example.com DNAME
   example.net" SHOULD NOT be used.

   The domain name used as interaction between the value of a NS resource record, or part expansion of the value of a MX resource record must not be an alias.  Not only is wildcard and the specification clear on this point, but using an alias in either
   redirection 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 DNAME is non-deterministic.  Because the future other record
   types giving addressing information
   processing is non-deterministic, DNSSEC validating resolvers may not
   be acceptable.  It can also
   have other RRs, but never able to validate a CNAME RR.

   RFC 4592 [RFC4592] says wildcarded DNAME.

   A server MAY give a warning that DNAMEs are discouraged at wildcards.
   DNAMEs and CNAMEs can form loops. the behaviour is unspecified if such
   a wildcarded DNAME is discussed loaded.

3.2.  DNAME bit in RFC 3363, section 4, NSEC type map

   When a validator checks the NSEC RRs returned on A6 and DNAME. a name error
   response, it SHOULD check that the DNAME bit is
   NOT RECOMMENDED for use in not set.  If the
   DNAME bit is set then the ip6 reverse tree [RFC3363].  And from
   [RFC4294], all references to DNAME substitution should have been removed.  There
   needs to be done,
   but has not.  In the same vein, for a better clarification of no error/no data response the status of DNAME
   CNAME bit in RFC 3363
   which would the NSEC RR bitmap should not be to drop all constraints on having set.

3.3.  CNAME synthesis

   On the server side, the DNAME RRs in these
   zones.

4.  Issues with DNAME

   There are several issues on DNAME as specified RR record is always included in RFC 2672 [RFC2672].

4.1.  DNAME as Delegation Tool

   DNAMEs can be used as indirections, the goal
   answer section of these indirections is
   to mirror a part of query.  A CNAME RR record with TTL 0 is
   synthesized for old resolvers, specifically for the DNS domain tree QNAME in another part of the DNS
   domain tree.  This mirroring should be easy.  Alternative wording is
   query.  DNSSEC [RFC4033], [RFC4034], [RFC4035] says that the goal is to
   synthesized CNAME does not have to be signed.  The DNAME has an alias name for RRSIG
   and a part of validating resolver can check the domain tree.
   Running example is x DNAME y.  The extra point here is that CNAME against 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
   record and validate the DNAME apex RRs are
   answered with data at x not at y. record.

   The reason for the original
   decision was that in this way (without DNAME apex affected) one can
   have a DNAME at TTL of the zone apex, next synthesized CNAME record MAY be set to the SOA, NS records, TTL of the
   DNAME record.  This enables older caches store the CNAMEs without
   problem.  And use this to point zones under your operational control a
   need to other zones.  Hosting two identical zones re-query for example.  Another
   reason them.  This updates RFC2672 which stated the TTL
   had to be zero.

   It does not make sense for excluding the DNAME apex authoritative server to follow the
   chain of DNAMEs, CNAMEs and wildcards outside of the zone of the
   query, as modern resolvers will remove out-of-zone information from
   the answer.

   The EDNS DNSSEC-OK bit signals understanding of the DNAME record
   [RFC4034].  If set, the synthesized CNAME MAY be omitted, since it is that one can
   then query
   not signed and therefore not useful for the DNAME through RFC 1034 [RFC1034] caches.

4.3.  DNAME validation and a waste of
   bandwidth.  This is Always Included in Outgoing Packets.

   Old resolvers a change from RFC2672, which specified CNAMEs had
   to be synthesized for all EDNS0, or firewalls may drop packets with this unknown RR
   type.

4.4.  MX and NS Records Require that non-extended queries.

   Resolvers MUST be able to handle a synthesized CNAME TTL of zero or
   equal to the TTL of the corresponding DNAME in their RDATA is
      Canonical

   This record.  The TTL of zero
   means that the CNAME can be discarded immediately resolve, no CNAMEs no DNAMEs.  See after processing
   the
   reference answer.

   Servers MUST be able to RFC 2181, Section 10.3 above.  Also in RFC 1912
   [RFC1912], Section 2.4.

4.5.  DNSSEC

   For answer a name error response, query for a synthesized CNAME.  An
   answer containing the resolver synthesized CNAME cannot contain an error
   (since a CNAME has been followed), as per RFC 1034 CNAME rules.

3.4.  Processing

   TBD: An issue with some firewalls and middleboxes, and perhaps
   windows XP/2003 resolvers potentially responding badly to check the closest
   encloser NSEC DNAME
   records (dropping packets),
   TBD: Is this useful to make sure it has no specify?  Resolvers MUST be able to handle
   unsigned responses with only the CNAME, or with the DNAME bit set.  If only, or
   both CNAME and DNAME.  Resolvers that query with DNSSEC_OK MUST be
   able to handle signed responses with only the DNAME, or with the
   unsigned synthesized CNAME included.

   Caches MUST NOT allow data to be cached below a DNAME.  Except CNAME
   records or perhaps NSEC3 records and their signatures.  CNAME records
   below a DNAME had
   been present, that MUST be re-synthesized from the DNAME, or checked
   against the DNAME redirection should have been followed.

4.6.  Signaling record before sending them out.  This improves
   consistency of the DNAME Understanding

   Some mechanism to signal that CNAMEs need not be synthesized.  Also
   signal that and CNAME records below it.

4.  DNAME target compression can be used (if RDATA target Discussions in Other Documents

   In [RFC2181], in Section 10.3., the discussion on MX and NS records
   touches on redirection by CNAMEs, but this also holds for DNAMEs.

   Excerpt from 10.3.  MX and NS records (in RFC 2181).

           The domain name compression is allowed at all).  EDNS version seems used as the most
   obvious, states value of a NS resource record,
           or part of the rfc.  The gain value of a MX resource record must not be
           an alias.  Not only is compression 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 DNAME rname,
   and smaller response size.

4.7. 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 not a Zone-cut

   A discussed in RFC 3363, section 4, on A6 and DNAME.  DNAME is not a zone-cut.  You may want to
   NOT RECOMMENDED for use it as such in the IPv66 reverse tree [RFC3363].  And
   from [RFC4294], all references to DNAME should have been removed.
   There needs to mirror be a part better clarification of the DNS tree, but RFC 2672 status of DNAME is not usable because the
   apex is not redirected.

4.8. in
   RFC 3363 which would be to drop all constraints on having DNAME and CIDR Blocks RRs
   in in-addr.arpa

   Is these zones.

5.  Issues with DNAME the Way

   There are several issues 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 aware of servers only uncompressed is possible.  New
   version can still choose to use compressed or not.

   Clarify on compression proposal: Senders SHOULD NOT compress RDATA,
   receivers MUST be able to decompress, when the new version has been
   negotiated with about the EDNS bits.

4.10.  Synthesized CNAME TTL=0

   In use of DNAME.

5.1.  DNAME Apex not Redirected itself

   The owner name of a DNAME is not redirected itself.  The reason for
   the original specification, all synthesized CNAME RRs had decision was that in this way (without DNAME owner
   affected) one can have a TTL of
   0.  Due DNAME at the zone apex, next to DNSSEC TTL=0 interpretation had the SOA, NS
   records, without problem.  Then use this to be changed point queries to mean
   "keep as long as the query using this RRset is
   zone to other zones.  Hosting two identical zones for example, there
   still being
   processed".  What is the status of this CNAME?

   This could be synthesized CNAMEs should have a TTL equal need to duplicate the TTL
   of resource records at the DNAME.  This allows non-aware clients to cache zone apex.
   Another reason for excluding the CNAMEs and
   thus lightens DNAME owner from the load on authoritative servers.

4.11.  Wildcarded DNAME

   What should happen with a wildcard with RRtype DNAME, i.e.
   *.example.com
   substitution is that one can then query for the DNAME example.net. through RFC 4592 [RFC4592] discourages
   this.  Behaviour unspecified (strict interpretation
   1034 [RFC1034] caches.

   This means that DNAME does not mirror a zone completely, as it does
   not mirror the zone apex.  It can be used if the zone apex records
   are duplicated to provide a summary of RFC 2672 says the rest of the zone.

   The rules on DNAME RRs mean that for queries for which it is not allowed at the wildcard same domain
   name as NS records unless there is expanded, no also a SOA record there.  This
   means DNAME
   processing occurs, and for queries for the '*' label
   ('foo.*.example.com') RRs are not allowed at the parent side of a delegation
   point.  DNAME is followed.).

4.12.  NSEC3 allowed at a zone apex.

5.2.  MX, NS and DNAME

   NSEC3 uses hashing to obscure names.  This hashing can be expensive PTR Records Must Point to compute.  A zone that has Target of DNAME

   The names listed as target names of MX, NS and NSEC3 PTR records must be
   canonical hostnames.  This means no CNAME or DNAME redirection 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
   present during DNS lookup of the address records for the host.  This
   is discussed in RFC 2181 [RFC2181], section 10.3, and DNAME RFC 1912
   [RFC1912], section 2.4.

   The upshot of this is that although the lookup of a PTR records record can
   involve DNAMEs, the name listed in the reverse zone must have canonical names as their
   RDATA, like PTR record can not fall under
   a DNAME.  The same holds for NS and MX records.  The lookup process  For example, when
   punycode alternates for a zone use DNAME then the NS, MX and PTR
   records
   owner that point to that zone must use names may involve DNAME/CNAME records, but without punycode in
   their RDATA.  What must be done then is to have the lookup process
   for domain names with
   DNAME substitution already applied to it as the MX, NS, PTR data.
   These are valid canonical hostnames.

5.3.  NSEC3 and DNAME

   NSEC3 records RDATA names may not.  RFC 1912.  More problematic
   than NS and MX their signatures are allowed to exist below a
   DNAME.  This is because of the nature of NSEC3 RRs in operational sense, since DNSSEC, which
   creates hashed owner names that exist below the reverse zone may not apex.  This is an
   exception to the rule that there MUST NOT be any other RRs under a
   DNAME RR, if the control of DNAME RR exists at the zone operator.

4.14.  Small Corner Cases

   There are also some corner cases to discuss and clarify.  These are
   small issues, apex.

   TBD: This is a new issue, but additional examples can give more guidance to
   implementors. [[editors note: The following the same as the NSEC3 draft.

   Queries for NSEC3 owner names are redirected as if there were no such
   NSEC3 present.

   There is to be expanded]]
   1.  Example no significant extra hashing cost for NSEC3 signed zones
   when answering queries with DNAME substitution.

5.4.  Validators Must Understand DNAME

   Examples of why DNSSEC validators MUST understand DNAME.
   2.  Examples of

5.4.1.  DNAME in Bitmap Causes Invalid Name Error

   ;; Header: QR AA DO RCODE=3(NXDOMAIN)
   ;; Question
   foo.bar.example.com. IN A
   ;; Answer
   bar.example.com. NSEC dub.example.com. A DNAME
   bar.example.com. RRSIG NSEC [valid signature]

   If you receive this answer, then only by understanding that the DNAME name substitution. whole labels only, name
   bit means that foo.bar.example.com needed to have been redirected by
   the DNAME, the validator can get longer and shorter.  The '*' label is handled as a fixed
       string during substitution. apex see that it 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 BOGUS reply from an
   attacker, that collated existing records from the DNS to create a
   confusing reply.

   If the DNAME
       for such bit had not been set in the NSEC record above, then the
   answer would have validated as a correct name error response.

5.4.2.  Valid Name Error Response Involving DNAME in Bitmap

   ;; Header: QR AA DO RCODE=3(NXDOMAIN)
   ;; Question
   cee.example.com. IN A
   ;; Answer
   bar.example.com. NSEC dub.example.com. A DNAME
   bar.example.com. RRSIG NSEC [valid signature]

   If the query and follows had been cee.example.com as shown above, then this
   answer would have been validated, because 'cee' does not get
   redirected by 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 at 'bar'.

5.4.3.  Response With Synthesized CNAME
   ;; Header: QR AA DO RCODE=0(NOERROR)
   ;; Question
   foo.bar.example.com. IN A
   ;; Answer
   bar.example.com. DNAME x.  Loop: x bar.example.net.
   bar.example.com. RRSIG 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 [valid signature]
   foo.bar.example.com. CNAME foo.bar.example.net.

   The answer shown above has the synthesized CNAME included.  However,
   the CNAME has no signature, since the server cannot sign the keys
   online (it is a DNAME contains resource records, as slow operation and exposes the RFC requests.
   6.  Caches must not allow data signing key).  So it
   cannot be trusted.  It could be altered by an attacker to be cached below a DNAME.  CNAMES
       below a
   foo.bar.example.com CNAME bla.bla.example.  The DNAME record does
   have its signature included, since it does not change for every query
   name.  The validator must be re-synthesized from the DNAME, or checked
       against verify the DNAME if needed.

5. signature and then
   recursively resolve further to query for the foo.bar.example.net A
   record.

6.  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 original document and not this draft.

6. registered the
   DNAME Resource Record type code 39 (decimal).  No further action is
   required on the part of IANA.

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

   If a validating resolver accepts wildcarded DNAMEs, this creates
   security issues.  Since the processing of a wildcarded DNAME specification.  Any clarification or
   replacement RR type will have is non-
   deterministic and the CNAME that was substituted by the server has no
   signature, the resolver may choose a different security considerations.
   These will be stated result than what the
   server meant, and consequently end up at the wrong destination.  Use
   of wildcarded DNAMEs is discouraged in any case [RFC4592].

   A validating resolver MUST understand DNAME, according to [RFC4034].
   In Section 5.4 examples are given that illustrate this need.  These
   examples are shown with NSEC records, but similar cases exist for
   NSEC3.

8.  Document History

   00-01.  Small language issues.  Removed wording of 'delegation' for
   dname use to alias a following document.

7.  Acknowledgements whole zone from parent side (registration tool).
   Names under a DNAME are not canonical.  Synthesized CNAME is not
   signed.  Rewritten entirely as an update to the rfc.

9.  Acknowledgments

   The authors of this draft would like to acknowledge Matt Larson for
   beginning this effort to addres address the issues related to the DNAME RR
   type.

8.

10.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1912]  Barr, D., "Common DNS Operational and Configuration
              Errors", RFC 1912, February 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, April 1997.

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

   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
              (RR) Types", RFC 3597, September 2003.

   [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
   NIST
   100 Bureau Dr.
   Gaithersburg, MD  20899
   USA

   Phone: +1-703-948-3364 +1-301-975-8439
   Fax:   +1-...   +1-301-975-6238
   EMail: srose@verisign.com scottr@nist.gov

   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

Full Copyright Statement

   Copyright (C) The Internet Society (2006). IETF Trust (2007).

   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 SOCIETY, THE IETF TRUST 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).