doc/draft/draft-ietf-dnsext-rfc2672bis-dname-19.txt

   1
   2
   3
   4 DNS Extensions Working Group                                     S. Rose
   5 Internet-Draft                                                      NIST
   6 Obsoletes: 2672 (if approved)                              W. Wijngaards
   7 Updates: 3363,4294                                            NLnet Labs
   8 (if approved)                                             April 20, 2010
   9 Intended status: Standards Track
  10 Expires: October 22, 2010
  11
  12
  13                  Update to DNAME Redirection in the DNS
  14                  draft-ietf-dnsext-rfc2672bis-dname-19
  15
  16 Abstract
  17
  18    The DNAME record provides redirection for a sub-tree of the domain
  19    name tree in the DNS system.  That is, all names that end with a
  20    particular suffix are redirected to another part of the DNS.  This is
  21    a revision of the original specification in RFC 2672, also aligning
  22    RFC 3363 and RFC 4294 with this revision.
  23
  24 Requirements Language
  25
  26    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  27    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  28    document are to be interpreted as described in RFC 2119 [RFC2119].
  29
  30 Status of This Memo
  31
  32    This Internet-Draft is submitted to IETF in full conformance with the
  33    provisions of BCP 78 and BCP 79.
  34
  35    Internet-Drafts are working documents of the Internet Engineering
  36    Task Force (IETF), its areas, and its working groups.  Note that
  37    other groups may also distribute working documents as Internet-
  38    Drafts.
  39
  40    Internet-Drafts are draft documents valid for a maximum of six months
  41    and may be updated, replaced, or obsoleted by other documents at any
  42    time.  It is inappropriate to use Internet-Drafts as reference
  43    material or to cite them other than as "work in progress."
  44
  45    The list of current Internet-Drafts can be accessed at
  46    http://www.ietf.org/ietf/1id-abstracts.txt.
  47
  48    The list of Internet-Draft Shadow Directories can be accessed at
  49    http://www.ietf.org/shadow.html.
  50
  51    This Internet-Draft will expire on October 22, 2010.
  52
  53
  54
  55 Rose & Wijngaards       Expires October 22, 2010                [Page 1]
  56 \f
  57 Internet-Draft              DNAME Redirection                 April 2010
  58
  59
  60 Copyright Notice
  61
  62    Copyright (c) 2010 IETF Trust and the persons identified as the
  63    document authors.  All rights reserved.
  64
  65    This document is subject to BCP 78 and the IETF Trust's Legal
  66    Provisions Relating to IETF Documents
  67    (http://trustee.ietf.org/license-info) in effect on the date of
  68    publication of this document.  Please review these documents
  69    carefully, as they describe your rights and restrictions with respect
  70    to this document.  Code Components extracted from this document must
  71    include Simplified BSD License text as described in Section 4.e of
  72    the Trust Legal Provisions and are provided without warranty as
  73    described in the BSD License.
  74
  75    This document may contain material from IETF Documents or IETF
  76    Contributions published or made publicly available before November
  77    10, 2008.  The person(s) controlling the copyright in some of this
  78    material may not have granted the IETF Trust the right to allow
  79    modifications of such material outside the IETF Standards Process.
  80    Without obtaining an adequate license from the person(s) controlling
  81    the copyright in such materials, this document may not be modified
  82    outside the IETF Standards Process, and derivative works of it may
  83    not be created outside the IETF Standards Process, except to format
  84    it for publication as an RFC or to translate it into languages other
  85    than English.
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111 Rose & Wijngaards       Expires October 22, 2010                [Page 2]
 112 \f
 113 Internet-Draft              DNAME Redirection                 April 2010
 114
 115
 116 Table of Contents
 117
 118    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
 119
 120    2.  The DNAME Resource Record  . . . . . . . . . . . . . . . . . .  4
 121      2.1.  Format . . . . . . . . . . . . . . . . . . . . . . . . . .  4
 122      2.2.  The DNAME Substitution . . . . . . . . . . . . . . . . . .  5
 123      2.3.  DNAME Owner Name Matching the QNAME  . . . . . . . . . . .  7
 124      2.4.  Names Next to and Below a DNAME Record . . . . . . . . . .  7
 125      2.5.  Compression of the DNAME record. . . . . . . . . . . . . .  7
 126
 127    3.  Processing . . . . . . . . . . . . . . . . . . . . . . . . . .  8
 128      3.1.  CNAME synthesis  . . . . . . . . . . . . . . . . . . . . .  8
 129      3.2.  Server algorithm . . . . . . . . . . . . . . . . . . . . .  9
 130      3.3.  Wildcards  . . . . . . . . . . . . . . . . . . . . . . . . 11
 131      3.4.  Acceptance and Intermediate Storage  . . . . . . . . . . . 11
 132
 133    4.  DNAME Discussions in Other Documents . . . . . . . . . . . . . 11
 134
 135    5.  Other Issues with DNAME  . . . . . . . . . . . . . . . . . . . 13
 136      5.1.  Canonical hostnames cannot be below DNAME owners . . . . . 13
 137      5.2.  Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 13
 138      5.3.  DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 13
 139        5.3.1.  Signed DNAME, Unsigned Synthesized CNAME . . . . . . . 13
 140        5.3.2.  DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 14
 141        5.3.3.  DNAME Chains as Strong as the Weakest Link . . . . . . 14
 142        5.3.4.  Validators Must Understand DNAME . . . . . . . . . . . 14
 143          5.3.4.1.  DNAME in Bitmap Causes Invalid Name Error  . . . . 14
 144          5.3.4.2.  Valid Name Error Response Involving DNAME in
 145                    Bitmap . . . . . . . . . . . . . . . . . . . . . . 15
 146          5.3.4.3.  Response With Synthesized CNAME  . . . . . . . . . 15
 147
 148    6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
 149
 150    7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
 151
 152    8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
 153
 154    9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
 155      9.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
 156      9.2.  Informative References . . . . . . . . . . . . . . . . . . 17
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167 Rose & Wijngaards       Expires October 22, 2010                [Page 3]
 168 \f
 169 Internet-Draft              DNAME Redirection                 April 2010
 170
 171
 172 1.  Introduction
 173
 174    DNAME is a DNS Resource Record type originally defined in RFC 2672
 175    [RFC2672].  DNAME provides redirection from a part of the DNS name
 176    tree to another part of the DNS name tree.
 177
 178    The DNAME RR and the CNAME RR [RFC1034] cause a lookup to
 179    (potentially) return data corresponding to a domain name different
 180    from the queried domain name.  The difference between the two
 181    resource records is that the CNAME RR directs the lookup of data at
 182    its owner to another single name, a DNAME RR directs lookups for data
 183    at descendants of its owner's name to corresponding names under a
 184    different (single) node of the tree.
 185
 186    Take for example, looking through a zone (see RFC 1034 [RFC1034],
 187    section 4.3.2, step 3) for the domain name "foo.example.com" and a
 188    DNAME resource record is found at "example.com" indicating that all
 189    queries under "example.com" be directed to "example.net".  The lookup
 190    process will return to step 1 with the new query name of
 191    "foo.example.net".  Had the query name been "www.foo.example.com" the
 192    new query name would be "www.foo.example.net".
 193
 194    This document is a revision of the original specification of DNAME in
 195    RFC 2672 [RFC2672].  DNAME was conceived to help with the problem of
 196    maintaining address-to-name mappings in a context of network
 197    renumbering.  With a careful set-up, a renumbering event in the
 198    network causes no change to the authoritative server that has the
 199    address-to-name mappings.  Examples in practice are classless reverse
 200    address space delegations.
 201
 202    Another usage of DNAME lies in aliasing of name spaces.  For example,
 203    a zone administrator may want sub-trees of the DNS to contain the
 204    same information.  Examples include punycode alternates for domain
 205    spaces.
 206
 207    This revision to DNAME does not change the wire format or the
 208    handling of DNAME Resource Records.  Discussion is added on problems
 209    that may be encountered when using DNAME.
 210
 211 2.  The DNAME Resource Record
 212
 213 2.1.  Format
 214
 215    The DNAME RR has mnemonic DNAME and type code 39 (decimal).  It is
 216    not class-sensitive.
 217
 218
 219
 220
 221
 222
 223 Rose & Wijngaards       Expires October 22, 2010                [Page 4]
 224 \f
 225 Internet-Draft              DNAME Redirection                 April 2010
 226
 227
 228    Its RDATA is comprised of a single field, <target>, which contains a
 229    fully qualified domain name that must be sent in uncompressed form
 230    [RFC1035], [RFC3597].  The <target> field MUST be present.  The
 231    presentation format of <target> is that of a domain name [RFC1035].
 232
 233            <owner> <ttl> <class> DNAME <target>
 234
 235    The effect of the DNAME RR is the substitution of the record's
 236    <target> for its owner name, as a suffix of a domain name.  This
 237    substitution is to be applied for all names below the owner name of
 238    the DNAME RR.  This substitution has to be applied for every DNAME RR
 239    found in the resolution process, which allows fairly lengthy valid
 240    chains of DNAME RRs.
 241
 242    Details of the substitution process, methods to avoid conflicting
 243    resource records, and rules for specific corner cases are given in
 244    the following subsections.
 245
 246 2.2.  The DNAME Substitution
 247
 248    When following RFC 1034 [RFC1034], section 4.3.2's algorithm's third
 249    step, "start matching down, label by label, in the zone" and a node
 250    is found to own a DNAME resource record a DNAME substitution occurs.
 251    The name being sought may be the original query name or a name that
 252    is the result of a CNAME resource record being followed or a
 253    previously encountered DNAME.  As in the case when finding a CNAME
 254    resource record or NS resource record set, the processing of a DNAME
 255    will happen prior to finding the desired domain name.
 256
 257    A DNAME substitution is performed by replacing the suffix labels of
 258    the name being sought matching the owner name of the DNAME resource
 259    record with the string of labels in the RDATA field.  The matching
 260    labels end with the root label in all cases.  Only whole labels are
 261    replaced.  See the table of examples for common cases and corner
 262    cases.
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279 Rose & Wijngaards       Expires October 22, 2010                [Page 5]
 280 \f
 281 Internet-Draft              DNAME Redirection                 April 2010
 282
 283
 284    In the table below, the QNAME refers to the query name.  The owner is
 285    the DNAME owner domain name, and the target refers to the target of
 286    the DNAME record.  The result is the resulting name after performing
 287    the DNAME substitution on the query name. "no match" means that the
 288    query did not match the DNAME and thus no substitution is performed
 289    and a possible error message is returned (if no other result is
 290    possible).  Thus every line contains one example substitution.  In
 291    the examples below, 'cyc' and 'shortloop' contain loops.
 292
 293     QNAME            owner  DNAME   target         result
 294     ---------------- -------------- -------------- -----------------
 295     com.             example.com.   example.net.   <no match>
 296     example.com.     example.com.   example.net.   [0]
 297     a.example.com.   example.com.   example.net.   a.example.net.
 298     a.b.example.com. example.com.   example.net.   a.b.example.net.
 299     ab.example.com.  b.example.com. example.net.   <no match>
 300     foo.example.com. example.com.   example.net.   foo.example.net.
 301     a.x.example.com. x.example.com. example.net.   a.example.net.
 302     a.example.com.   example.com.   y.example.net. a.y.example.net.
 303     cyc.example.com. example.com.   example.com.   cyc.example.com.
 304     cyc.example.com. example.com.   c.example.com. cyc.c.example.com.
 305     shortloop.x.x.   x.             .              shortloop.x.
 306     shortloop.x.     x.             .              shortloop.
 307
 308    [0] The result depends on the QTYPE.  If the QTYPE = DNAME, then
 309        the result is "example.com." else "<no match>"
 310
 311                    Table 1. DNAME Substitution Examples.
 312
 313    It is possible for DNAMEs to form loops, just as CNAMEs can form
 314    loops.  DNAMEs and CNAMEs can chain together to form loops.  A single
 315    corner case DNAME can form a loop.  Resolvers and servers should be
 316    cautious in devoting resources to a query, but be aware that fairly
 317    long chains of DNAMEs may be valid.  Zone content administrators
 318    should take care to insure that there are no loops that could occur
 319    when using DNAME or DNAME/CNAME redirection.
 320
 321    The domain name can get too long during substitution.  For example,
 322    suppose the target name of the DNAME RR is 250 octets in length
 323    (multiple labels), if an incoming QNAME that has a first label over 5
 324    octets in length, the result would be a name over 255 octets.  If
 325    this occurs the server returns an RCODE of YXDOMAIN [RFC2136].  The
 326    DNAME record and its signature (if the zone is signed) are included
 327    in the answer as proof for the YXDOMAIN (value 6) RCODE.
 328
 329
 330
 331
 332
 333
 334
 335 Rose & Wijngaards       Expires October 22, 2010                [Page 6]
 336 \f
 337 Internet-Draft              DNAME Redirection                 April 2010
 338
 339
 340 2.3.  DNAME Owner Name Matching the QNAME
 341
 342    Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its
 343    owner name; the owner name of a DNAME is not redirected itself.  The
 344    domain name that owns a DNAME record is allowed to have other
 345    resource record types at that domain name, except DNAMEs, CNAMEs or
 346    other types that have restrictions on what they can co-exist with.
 347    When there is a match of the QTYPE to a type (or types) also owned by
 348    the owner name the response is sourced from the owner name.  E.g., a
 349    QTYPE of ANY would return the (available) types at the owner name,
 350    not the target name.
 351
 352    DNAME RRs MUST NOT appear at the same owner name as an NS RR unless
 353    the owner name is the zone apex as this would constitute data below a
 354    zone cut.
 355
 356    If a DNAME record is present at the zone apex, there is still a need
 357    to have the customary SOA and NS resource records there as well.
 358    Such a DNAME cannot be used to mirror a zone completely, as it does
 359    not mirror the zone apex.
 360
 361    These rules also allow DNAME records to be queried through RFC 1034
 362    [RFC1034] compliant, DNAME-unaware caches.
 363
 364 2.4.  Names Next to and Below a DNAME Record
 365
 366    Resource records MUST NOT exist at any sub-domain of the owner of a
 367    DNAME RR.  To get the contents for names subordinate to that owner
 368    name, the DNAME redirection must be invoked and the resulting target
 369    queried.  A server MAY refuse to load a zone that has data at a sub-
 370    domain of a domain name owning a DNAME RR.  If the server does load
 371    the zone, those names below the DNAME RR will be occluded as
 372    described in RFC 2136 [RFC2136], section 7.18.  Also a server SHOULD
 373    refuse to load a zone subordinate to the owner of a DNAME record in
 374    the ancestor zone.  See Section 5.2 for further discussion related to
 375    dynamic update.
 376
 377    DNAME is a singleton type, meaning only one DNAME is allowed per
 378    name.  The owner name of a DNAME can only have one DNAME RR, and no
 379    CNAME RRs can exist at that name.  These rules make sure that for a
 380    single domain name only one redirection exists, and thus no confusion
 381    which one to follow.  A server SHOULD refuse to load a zone that
 382    violates these rules.
 383
 384 2.5.  Compression of the DNAME record.
 385
 386    The DNAME owner name can be compressed like any other owner name.
 387    The DNAME RDATA target name MUST NOT be sent out in compressed form,
 388
 389
 390
 391 Rose & Wijngaards       Expires October 22, 2010                [Page 7]
 392 \f
 393 Internet-Draft              DNAME Redirection                 April 2010
 394
 395
 396    so that a DNAME RR can be treated as an unknown type [RFC3597].
 397
 398    Although the previous DNAME specification [RFC2672] (that is
 399    obsoleted by this specification) talked about signaling to allow
 400    compression of the target name, such signaling has never been
 401    specified and this document also does not specify this signaling
 402    behavior.
 403
 404    RFC 2672 (obsoleted by this document) stated that the EDNS version
 405    had a meaning for understanding of DNAME and DNAME target name
 406    compression.  This document revises RFC 2672, in that there is no
 407    EDNS version signaling for DNAME.
 408
 409 3.  Processing
 410
 411    The DNAME RR causes type NS additional section processing.  This
 412    refers to action at step 6 of the server algorithm outlined in
 413    section 3.2.
 414
 415 3.1.  CNAME synthesis
 416
 417    When preparing a response, a server performing a DNAME substitution
 418    will in all cases include the relevant DNAME RR in the answer
 419    section.  Relevant includes the following cases:
 420
 421    1.  The DNAME is being employed as a substitution instruction.
 422
 423    2.  The DNAME itself matches the QTYPE and the owner name matches
 424        QNAME.
 425
 426    When the owner name name matches the QNAME and the QTYPE matches
 427    another type owned there, the DNAME is not included in the answer.
 428
 429    A CNAME RR with TTL equal to the corresponding DNAME RR is
 430    synthesized and included in the answer section when the DNAME is
 431    employed as a substitution instruction.  The owner name of the CNAME
 432    is the QNAME of the query.  The DNSSEC specification [RFC4033],
 433    [RFC4034], [RFC4035] says that the synthesized CNAME does not have to
 434    be signed.  The DNAME has an RRSIG and a validating resolver can
 435    check the CNAME against the DNAME record and validate the signature
 436    over the DNAME RR.
 437
 438    Servers MUST be able to answer a query for a synthesized CNAME.  Like
 439    other query types this invokes the DNAME, and synthesizes the CNAME
 440    into the answer.  If the server in question is a cache, the
 441    synthesized CNAME's TTL SHOULD be equal to the decremented TTL of the
 442    cached DNAME.
 443
 444
 445
 446
 447 Rose & Wijngaards       Expires October 22, 2010                [Page 8]
 448 \f
 449 Internet-Draft              DNAME Redirection                 April 2010
 450
 451
 452    Resolvers MUST be able to handle a synthesized CNAME TTL of zero or
 453    equal to the TTL of the corresponding DNAME record (as some older
 454    authoritative server implementations set the TTL of synthesized
 455    CNAMEs to zero).  A TTL of zero means that the CNAME can be discarded
 456    immediately after processing the answer.
 457
 458 3.2.  Server algorithm
 459
 460    Below is the server algorithm, which appeared in RFC 2672 Section
 461    4.1.
 462
 463    1.  Set or clear the value of recursion available in the response
 464        depending on whether the name server is willing to provide
 465        recursive service.  If recursive service is available and
 466        requested via the RD bit in the query, go to step 5, otherwise
 467        step 2.
 468
 469
 470    2.  Search the available zones for the zone which is the nearest
 471        ancestor to QNAME.  If such a zone is found, go to step 3,
 472        otherwise step 4.
 473
 474
 475    3.  Start matching down, label by label, in the zone.  The matching
 476        process can terminate several ways:
 477
 478
 479        A.  If the whole of QNAME is matched, we have found the node.
 480
 481            If the data at the node is a CNAME, and QTYPE does not match
 482            CNAME, copy the CNAME RR into the answer section of the
 483            response, change QNAME to the canonical name in the CNAME RR,
 484            and go back to step 1.
 485
 486            Otherwise, copy all RRs which match QTYPE into the answer
 487            section and go to step 6.
 488
 489
 490        B.  If a match would take us out of the authoritative data, we
 491            have a referral.  This happens when we encounter a node with
 492            NS RRs marking cuts along the bottom of a zone.
 493
 494            Copy the NS RRs for the sub-zone into the authority section
 495            of the reply.  Put whatever addresses are available into the
 496            additional section, using glue RRs if the addresses are not
 497            available from authoritative data or the cache.  Go to step
 498            4.
 499
 500
 501
 502
 503 Rose & Wijngaards       Expires October 22, 2010                [Page 9]
 504 \f
 505 Internet-Draft              DNAME Redirection                 April 2010
 506
 507
 508        C.  If at some label, a match is impossible (i.e., the
 509            corresponding label does not exist), look to see whether the
 510            last label matched has a DNAME record.
 511
 512            If a DNAME record exists at that point, copy that record into
 513            the answer section.  If substitution of its <target> for its
 514            <owner> in QNAME would overflow the legal size for a <domain-
 515            name>, set RCODE to YXDOMAIN [RFC2136] and exit; otherwise
 516            perform the substitution and continue.  The server MUST
 517            synthesize a CNAME record as described above and include it
 518            in the answer section.  Go back to step 1.
 519
 520            If there was no DNAME record, look to see if the "*" label
 521            exists.
 522
 523            If the "*" label does not exist, check whether the name we
 524            are looking for is the original QNAME in the query or a name
 525            we have followed due to a CNAME or DNAME.  If the name is
 526            original, set an authoritative name error in the response and
 527            exit.  Otherwise just exit.
 528
 529            If the "*" label does exist, match RRs at that node against
 530            QTYPE.  If any match, copy them into the answer section, but
 531            set the owner of the RR to be QNAME, and not the node with
 532            the "*" label.  If the data at the node with the "*" label is
 533            a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR
 534            into the answer section of the response changing the owner
 535            name to the QNAME, change QNAME to the canonical name in the
 536            CNAME RR, and go back to step 1.  Otherwise, Go to step 6.
 537
 538
 539    4.  Start matching down in the cache.  If QNAME is found in the
 540        cache, copy all RRs attached to it that match QTYPE into the
 541        answer section.  If QNAME is not found in the cache but a DNAME
 542        record is present at an ancestor of QNAME, copy that DNAME record
 543        into the answer section.  If there was no delegation from
 544        authoritative data, look for the best one from the cache, and put
 545        it in the authority section.  Go to step 6.
 546
 547
 548    5.  Use the local resolver or a copy of its algorithm to answer the
 549        query.  Store the results, including any intermediate CNAMEs and
 550        DNAMEs, in the answer section of the response.
 551
 552
 553    6.  Using local data only, attempt to add other RRs which may be
 554        useful to the additional section of the query.  Exit.
 555
 556
 557
 558
 559 Rose & Wijngaards       Expires October 22, 2010               [Page 10]
 560 \f
 561 Internet-Draft              DNAME Redirection                 April 2010
 562
 563
 564    Note that there will be at most one ancestor with a DNAME as
 565    described in step 4 unless some zone's data is in violation of the
 566    no-descendants limitation in section 3.  An implementation might take
 567    advantage of this limitation by stopping the search of step 3c or
 568    step 4 when a DNAME record is encountered.
 569
 570 3.3.  Wildcards
 571
 572    The use of DNAME in conjunction with wildcards is discouraged
 573    [RFC4592].  Thus records of the form "*.example.com DNAME
 574    example.net" SHOULD NOT be used.
 575
 576    The interaction between the expansion of the wildcard and the
 577    redirection of the DNAME is non-deterministic.  Because the
 578    processing is non-deterministic, DNSSEC validating resolvers may not
 579    be able to validate a wildcarded DNAME.
 580
 581    A server MAY give a warning that the behavior is unspecified if such
 582    a wildcarded DNAME is loaded.  The server MAY refuse it, refuse to
 583    load the zone or refuse dynamic updates.
 584
 585 3.4.  Acceptance and Intermediate Storage
 586
 587    Recursive caching name servers can encounter data at names below the
 588    owner name of a DNAME RR, due to a change at the authoritative server
 589    where data from before and after the change resides in the cache.
 590    This conflict situation is a transitional phase that ends when the
 591    old data times out.  The caching name server can opt to store both
 592    old and new data and treat each as if the other did not exist, or
 593    drop the old data, or drop the longer domain name.  In any approach,
 594    consistency returns after the older data TTL times out.
 595
 596    Recursive caching name servers MUST perform CNAME synthesis on behalf
 597    of clients.
 598
 599    If a recursive caching name server encounters a DNAME RR which
 600    contradicts information already in the cache (excluding CNAME
 601    records), it SHOULD NOT cache the DNAME RR, but it MAY cache the
 602    CNAME record received along with it, subject to the rules for CNAME.
 603
 604 4.  DNAME Discussions in Other Documents
 605
 606    In [RFC2181], in Section 10.3., the discussion on MX and NS records
 607    touches on redirection by CNAMEs, but this also holds for DNAMEs.
 608
 609
 610
 611
 612
 613
 614
 615 Rose & Wijngaards       Expires October 22, 2010               [Page 11]
 616 \f
 617 Internet-Draft              DNAME Redirection                 April 2010
 618
 619
 620    Excerpt from 10.3.  MX and NS records (in RFC 2181).
 621
 622            The domain name used as the value of a NS resource record,
 623            or part of the value of a MX resource record must not be
 624            an alias.  Not only is the specification clear on this
 625            point, but using an alias in either of these positions
 626            neither works as well as might be hoped, nor well fulfills
 627            the ambition that may have led to this approach.  This
 628            domain name must have as its value one or more address
 629            records.  Currently those will be A records, however in
 630            the future other record types giving addressing
 631            information may be acceptable.  It can also have other
 632            RRs, but never a CNAME RR.
 633
 634    The DNAME RR is discussed in RFC 3363, section 4, on A6 and DNAME.
 635    The opening premise of this section is demonstrably wrong, and so the
 636    conclusion based on that premise is wrong.  In particular, [RFC3363]
 637    deprecates the use of DNAME in the IPv6 reverse tree, which is then
 638    carried forward as a recommendation in [RFC4294].  Based on the
 639    experience gained in the meantime, [RFC3363] should be revised,
 640    dropping all constraints on having DNAME RRs in these zones.  This
 641    would greatly improve the manageability of the IPv6 reverse tree.
 642    These changes are made explicit below.
 643
 644    In [RFC3363], the paragraph
 645
 646      "The issues for DNAME in the reverse mapping tree appears to be
 647      closely tied to the need to use fragmented A6 in the main tree: if
 648      one is necessary, so is the other, and if one isn't necessary, the
 649      other isn't either.  Therefore, in moving RFC 2874 to experimental,
 650      the intent of this document is that use of DNAME RRs in the reverse
 651      tree be deprecated."
 652
 653    is to be replaced with the word "DELETED".
 654
 655    In [RFC4294], the reference to DNAME was left in as an editorial
 656    oversight.  The paragraph
 657
 658      "Those nodes are NOT RECOMMENDED to support the experimental A6 and
 659      DNAME Resource Records [RFC3363]."
 660
 661    is to be replaced by
 662
 663      "Those nodes are NOT RECOMMENDED to support the experimental
 664      A6 Resource Record [RFC3363]."
 665
 666
 667
 668
 669
 670
 671 Rose & Wijngaards       Expires October 22, 2010               [Page 12]
 672 \f
 673 Internet-Draft              DNAME Redirection                 April 2010
 674
 675
 676 5.  Other Issues with DNAME
 677
 678    There are several issues to be aware of about the use of DNAME.
 679
 680 5.1.  Canonical hostnames cannot be below DNAME owners
 681
 682    The names listed as target names of MX, NS, PTR and SRV [RFC2782]
 683    records must be canonical hostnames.  This means no CNAME or DNAME
 684    redirection may be present during DNS lookup of the address records
 685    for the host.  This is discussed in RFC 2181 [RFC2181], section 10.3,
 686    and RFC 1912 [RFC1912], section 2.4.  For SRV see RFC 2782 [RFC2782]
 687    page 4.
 688
 689    The upshot of this is that although the lookup of a PTR record can
 690    involve DNAMEs, the name listed in the PTR record can not fall under
 691    a DNAME.  The same holds for NS, SRV and MX records.  For example,
 692    when punycode alternates for a zone use DNAME then the NS, MX, SRV
 693    and PTR records that point to that zone must use names without
 694    punycode in their RDATA.  What must be done then is to have the
 695    domain names with DNAME substitution already applied to it as the MX,
 696    NS, PTR, SRV data.  These are valid canonical hostnames.
 697
 698 5.2.  Dynamic Update and DNAME
 699
 700    DNAME records can be added, changed and removed in a zone using
 701    dynamic update transactions.  Adding a DNAME RR to a zone occludes
 702    any domain names that may exist under the added DNAME.
 703
 704    A server MUST ignore a dynamic update message that attempts to add a
 705    non-DNAME/CNAME RR at a name that already has a DNAME RR associated
 706    with that name.  Otherwise, replace the DNAME RR with the DNAME (or
 707    CNAME) update RR.  This is similar behavior to dynamic updates to an
 708    owner name of a CNAME RR [RFC2136].
 709
 710 5.3.  DNSSEC and DNAME
 711
 712    The following subsections specify the behavior of implementations
 713    that understand both DNSSEC and DNAME (synthesis).
 714
 715 5.3.1.  Signed DNAME, Unsigned Synthesized CNAME
 716
 717    In any response, a signed DNAME RR indicates a non-terminal
 718    redirection of the query.  There might or might not be a server
 719    synthesized CNAME in the answer section; if there is, the CNAME will
 720    never be signed.  For a DNSSEC validator, verification of the DNAME
 721    RR and then checking that the CNAME was properly synthesized is
 722    sufficient proof.
 723
 724
 725
 726
 727 Rose & Wijngaards       Expires October 22, 2010               [Page 13]
 728 \f
 729 Internet-Draft              DNAME Redirection                 April 2010
 730
 731
 732 5.3.2.  DNAME Bit in NSEC Type Map
 733
 734    In any negative response, the NSEC or NSEC3 [RFC5155] record type bit
 735    map SHOULD be checked to see that there was no DNAME that could have
 736    been applied.  If the DNAME bit in the type bit map is set and the
 737    query name is a sub-domain of the closest encloser that is asserted,
 738    then DNAME substitution should have been done, but the substitution
 739    has not been done as specified.
 740
 741 5.3.3.  DNAME Chains as Strong as the Weakest Link
 742
 743    A response can contain a chain of DNAME and CNAME redirections.  That
 744    chain can end in a positive answer or a negative (no name error or no
 745    data error) reply.  Each step in that chain results in resource
 746    records added to the answer or authority section of the response.
 747    Only if all steps are secure can the AD bit be set for the response.
 748    If one of the steps is bogus, the result is bogus.
 749
 750 5.3.4.  Validators Must Understand DNAME
 751
 752    Below are examples of why DNSSEC validators MUST understand DNAME.
 753    In the examples below, SOA records, wildcard denial NSECs and other
 754    material not under discussion has been omitted or shortened.
 755
 756 5.3.4.1.  DNAME in Bitmap Causes Invalid Name Error
 757
 758    ;; Header: QR AA RCODE=3(NXDOMAIN)
 759    ;; OPT PSEUDOSECTION:
 760    ; EDNS: version: 0, flags: do; udp: 4096
 761
 762    ;; Question
 763    foo.bar.example.com. IN A
 764    ;; Authority
 765    bar.example.com. NSEC dub.example.com. A DNAME
 766    bar.example.com. RRSIG NSEC [valid signature]
 767
 768    If this is the received response, then only by understanding that the
 769    DNAME bit in the NSEC bitmap means that foo.bar.example.com needed to
 770    have been redirected by the DNAME, the validator can see that it is a
 771    BOGUS reply from an attacker that collated existing records from the
 772    DNS to create a confusing reply.
 773
 774    If the DNAME bit had not been set in the NSEC record above then the
 775    answer would have validated as a correct name error response.
 776
 777
 778
 779
 780
 781
 782
 783 Rose & Wijngaards       Expires October 22, 2010               [Page 14]
 784 \f
 785 Internet-Draft              DNAME Redirection                 April 2010
 786
 787
 788 5.3.4.2.  Valid Name Error Response Involving DNAME in Bitmap
 789
 790    ;; Header: QR AA RCODE=3(NXDOMAIN)
 791    ;; OPT PSEUDOSECTION:
 792    ; EDNS: version: 0, flags: do; udp: 4096
 793
 794    ;; Question
 795    cee.example.com. IN A
 796    ;; Authority
 797    bar.example.com. NSEC dub.example.com. A DNAME
 798    bar.example.com. RRSIG NSEC [valid signature]
 799
 800    This response has the same NSEC records as the example above, but
 801    with this query name (cee.example.com), the answer is validated,
 802    because 'cee' does not get redirected by the DNAME at 'bar'.
 803
 804 5.3.4.3.  Response With Synthesized CNAME
 805
 806    ;; Header: QR AA RCODE=0(NOERROR)
 807    ;; OPT PSEUDOSECTION:
 808    ; EDNS: version: 0, flags: do; udp: 4096
 809
 810    ;; Question
 811    foo.bar.example.com. IN A
 812    ;; Answer
 813    bar.example.com. DNAME bar.example.net.
 814    bar.example.com. RRSIG DNAME [valid signature]
 815    foo.bar.example.com. CNAME foo.bar.example.net.
 816
 817    The response shown above has the synthesized CNAME included.
 818    However, the CNAME has no signature, since the server does not sign
 819    online.  So this response cannot be trusted.  It could be altered by
 820    an attacker to be foo.bar.example.com CNAME bla.bla.example.  The
 821    DNAME record does have its signature included, since it does not
 822    change.  The validator must verify the DNAME signature and then
 823    recursively resolve further to query for the foo.bar.example.net A
 824    record.
 825
 826 6.  IANA Considerations
 827
 828    The DNAME Resource Record type code 39 (decimal) originally has been
 829    registered by [RFC2672].  IANA should update the DNS resource record
 830    registry to point to this document for RR type 39.
 831
 832 7.  Security Considerations
 833
 834    DNAME redirects queries elsewhere, which may impact security based on
 835    policy and the security status of the zone with the DNAME and the
 836
 837
 838
 839 Rose & Wijngaards       Expires October 22, 2010               [Page 15]
 840 \f
 841 Internet-Draft              DNAME Redirection                 April 2010
 842
 843
 844    redirection zone's security status.  For validating resolvers, the
 845    lowest security status of the links in the chain of CNAME and DNAME
 846    redirections is applied to the result.
 847
 848    If a validating resolver accepts wildcarded DNAMEs, this creates
 849    security issues.  Since the processing of a wildcarded DNAME is non-
 850    deterministic and the CNAME that was substituted by the server has no
 851    signature, the resolver may choose a different result than what the
 852    server meant, and consequently end up at the wrong destination.  Use
 853    of wildcarded DNAMEs is discouraged in any case [RFC4592].
 854
 855    A validating resolver MUST understand DNAME, according to [RFC4034].
 856    The examples in Section 5.3.4 illustrate this need.
 857
 858 8.  Acknowledgments
 859
 860    The authors of this draft would like to acknowledge Matt Larson for
 861    beginning this effort to address the issues related to the DNAME RR
 862    type.  The authors would also like to acknowledge Paul Vixie, Ed
 863    Lewis, Mark Andrews, Mike StJohns, Niall O'Reilly, Sam Weiler, Alfred
 864    Hoenes and Kevin Darcy for their review and comments on this
 865    document.
 866
 867 9.  References
 868
 869 9.1.  Normative References
 870
 871    [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
 872               STD 13, RFC 1034, November 1987.
 873
 874    [RFC1035]  Mockapetris, P., "Domain names - implementation and
 875               specification", STD 13, RFC 1035, November 1987.
 876
 877    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 878               Requirement Levels", BCP 14, RFC 2119, March 1997.
 879
 880    [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
 881               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
 882               RFC 2136, April 1997.
 883
 884    [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
 885               Specification", RFC 2181, July 1997.
 886
 887    [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
 888               specifying the location of services (DNS SRV)", RFC 2782,
 889               February 2000.
 890
 891    [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
 892
 893
 894
 895 Rose & Wijngaards       Expires October 22, 2010               [Page 16]
 896 \f
 897 Internet-Draft              DNAME Redirection                 April 2010
 898
 899
 900               (RR) Types", RFC 3597, September 2003.
 901
 902    [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
 903               Rose, "DNS Security Introduction and Requirements",
 904               RFC 4033, March 2005.
 905
 906    [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
 907               Rose, "Resource Records for the DNS Security Extensions",
 908               RFC 4034, March 2005.
 909
 910    [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
 911               Rose, "Protocol Modifications for the DNS Security
 912               Extensions", RFC 4035, March 2005.
 913
 914    [RFC4592]  Lewis, E., "The Role of Wildcards in the Domain Name
 915               System", RFC 4592, July 2006.
 916
 917    [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
 918               Security (DNSSEC) Hashed Authenticated Denial of
 919               Existence", RFC 5155, March 2008.
 920
 921 9.2.  Informative References
 922
 923    [RFC1912]  Barr, D., "Common DNS Operational and Configuration
 924               Errors", RFC 1912, February 1996.
 925
 926    [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection",
 927               RFC 2672, August 1999.
 928
 929    [RFC3363]  Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
 930               Hain, "Representing Internet Protocol version 6 (IPv6)
 931               Addresses in the Domain Name System (DNS)", RFC 3363,
 932               August 2002.
 933
 934    [RFC4294]  Loughney, J., "IPv6 Node Requirements", RFC 4294,
 935               April 2006.
 936
 937
 938
 939
 940
 941
 942
 943
 944
 945
 946
 947
 948
 949
 950
 951 Rose & Wijngaards       Expires October 22, 2010               [Page 17]
 952 \f
 953 Internet-Draft              DNAME Redirection                 April 2010
 954
 955
 956 Authors' Addresses
 957
 958    Scott Rose
 959    NIST
 960    100 Bureau Dr.
 961    Gaithersburg, MD  20899
 962    USA
 963
 964    Phone: +1-301-975-8439
 965    Fax:   +1-301-975-6238
 966    EMail: scottr.nist@gmail.com
 967
 968
 969    Wouter Wijngaards
 970    NLnet Labs
 971    Science Park 140
 972    Amsterdam  1098 XG
 973    The Netherlands
 974
 975    Phone: +31-20-888-4551
 976    EMail: wouter@nlnetlabs.nl
 977
 978
 979
 980
 981
 982
 983
 984
 985
 986
 987
 988
 989
 990
 991
 992
 993
 994
 995
 996
 997
 998
 999
1000
1001
1002
1003
1004
1005
1006
1007 Rose & Wijngaards       Expires October 22, 2010               [Page 18]
1008 \f