dnsext                                                    D. Barton, Ed.
Internet-Draft                                             GridFury, LLC
Intended status: Standards Track                          March 14, 2011
Expires: September 15, 2011


       Cloning Domain Name System (DNS) Labels for Fun and Profit
            draft-barton-clone-dns-labels-fun-profit-01.txt

Abstract

   This document describes a method for making one or more Domain Name
   System (DNS) labels behave in the DNS "as if" they were actually an
   entirely different label.  E.g., the delegee for the example.org zone
   could define bar.example.org to be a CLONE of foo.example.org.  This
   method is designed to meet the needs of those managing
   Internationalized Domain Name (IDN) zones that have been determined
   to be semantically similar, and therefore should be treated "as if"
   they were identical.  This method can also be used more generally to
   handle situations where either CNAME or DNAME Resource Records are
   currently being used.

   A key design goal for the CLONE method is that all of the semantic
   benefits are available by updating only the authoritative servers for
   the zone.  Domain managers who want to support DNSSEC for the CLONEd
   labels/zones may do so with dynamic signing of the CLONEs, or rely on
   users being behind a CLONE-Aware resolving name server.

Foreword

   [RFC Editor, please remove this Section at publication time.
   Thanks.]

   This is my first draft, please be gentle. :) I'm definitely open to
   the possibility that there are better ways to accomplish the concepts
   presented herein.  I'm sure that there are a non-zero number of
   errors in the formatting, references, etc.  Also Sections 2 and 3 may
   be under-specified, unclear, or unworkable.  So please don't be
   afraid to offer (constructive) criticism.

   TODO:

      Update/add/improve references?

      Add/improve examples?

   Revision History:




Barton                 Expires September 15, 2011               [Page 1]


Internet-Draft             Cloning DNS Labels                 March 2011


   1.  -00 Initial version

   2.  -01 Minor textual edits, add support for dynamic signing, clarify
       CLONE labels that are not zone cuts

Requirements Language

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

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on September 15, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.









Barton                 Expires September 15, 2011               [Page 2]


Internet-Draft             Cloning DNS Labels                 March 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  CLONE Overview . . . . . . . . . . . . . . . . . . . . . .  5
       1.2.1.  Common And Non-DNSSEC Cases  . . . . . . . . . . . . .  5
       1.2.2.  DNSSEC . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  The Authoritative Name Server  . . . . . . . . . . . . . . . .  5
     2.1.  Parent Zone File . . . . . . . . . . . . . . . . . . . . .  6
       2.1.1.  CLONE  . . . . . . . . . . . . . . . . . . . . . . . .  6
       2.1.2.  CLONES . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.2.  Child Authoritative Server Configuration . . . . . . . . .  7
     2.3.  Query Response For Labels That Are CLONEs  . . . . . . . .  7
       2.3.1.  DNSSEC For The Parent Of A Zone Cut  . . . . . . . . .  7
       2.3.2.  DNSSEC For The Dynamic-Signing Child . . . . . . . . .  7
       2.3.3.  DNSSEC For Other Authoritative Servers . . . . . . . .  8
     2.4.  Query Response For CLONE And CLONES Resource Records . . .  8
   3.  The CLONE-Aware Resolving Name Server  . . . . . . . . . . . .  8
     3.1.  CARNS DNSSEC Behavior For "Typical" Queries  . . . . . . .  9
     3.2.  CARNS Behavior for DNSSEC Resource Record Queries  . . . .  9
   4.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.1.  Non-CARNS  . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.2.  CARNS - First Query For CLONE  . . . . . . . . . . . . . . 10
     4.3.  CARNS - Second Query For CLONE . . . . . . . . . . . . . . 10
     4.4.  CLONES Response  . . . . . . . . . . . . . . . . . . . . . 10
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13



















Barton                 Expires September 15, 2011               [Page 3]


Internet-Draft             Cloning DNS Labels                 March 2011


1.  Introduction

   The DNS was initially designed and implemented during a period when
   the American Standard Code for Information Interchange [ASCII] text
   was the lingua franca, and certain assumptions about the
   characteristic behavior of ASCII text, and how it is commonly
   understood in written form, were baked into the protocol.  For
   example, while the following may not be stylistically appealing on
   the printed page; not only would all of the following be handled the
   same by the DNS, there would not be any confusion that all of the
   following representations refer to the same hostname:

   o  example.org

   o  Example.Org

   o  eXaMpLe.oRg

   o  EXAMPLE.ORG

   Because of the way that Internationalized Domain Names (IDNs)
   [RFC5890] work it is not possible for the DNS to provide the same
   level(s) or type(s) of equivalence for different Unicode Code Points
   that upper and lower case ASCII letters enjoy.  Furthermore, there
   are unique issues with Unicode representations of DNS labels that
   have no equivalents in ASCII text.  More information about the
   problems that this document attempts to provide a solution for can be
   found in DNS Resolution of Aliased Names
   [I-D.ietf-dnsext-aliasing-requirements].

   In addition to solving the DNS part of the problem of IDN
   equivalence, being able to use a more complete solution to the
   problem of "aliasing" DNS labels than CNAMEs [RFC1035] and DNAMEs
   [RFC2672] currently provide also has appeal.

1.1.  Terminology

   There is some feeling in the IDN community that a DNS solution for
   IDN equivalence must treat (and consider) all versions of a label as
   truly equal.  However this document describes a procedure that relies
   on one version of a label being configured in the familiar way, and
   the CLONE(s) configured in a way that refers to the traditionally
   configured label.  Therefore this document will adopt the term used
   in the Joint Engineering Team (JET) Guidelines [RFC3743] and refer to
   the label configured in the typical way as the "preferred" label.
   While on the one hand it is easy to see how a solution that treats
   all versions of the label as truly equal would be desirable, this
   document intentionally sacrifices the goal of true equality in the



Barton                 Expires September 15, 2011               [Page 4]


Internet-Draft             Cloning DNS Labels                 March 2011


   interest of providing a solution that can get the maximum possible
   benefit available to the largest number of end users while requiring
   only that the authoritative name servers are upgraded.  It will
   ultimately be up to the community to decide whether this is a
   sacrifice worth making.

   The terms "authoritative name server" and "resolving name server" are
   used with their commonly understood meanings.  A CLONE-Aware
   Resolving Name Server will hereinafter be referred to as a CARNS.

1.2.  CLONE Overview

1.2.1.  Common And Non-DNSSEC Cases

   There are two sides of the CLONE method, the authoritative and
   resolving name servers.  For clients that are not aware of the CLONE
   RR the authoritative server will simply respond "as if" the query for
   a CLONE label had actually been for the preferred name.  When a CARNS
   queries the authoritative server it will send an EDNS [RFC2671]
   option that indicates that it is CLONE-Aware.  The authoritative
   server will then add the CLONE Resource Record (RR) to the ANSWER
   section, which will include the preferred label.  From then on when
   queries come into the CARNS for the CLONE it can in turn query the
   authoritative server for the preferred label, and respond to its
   querier "as if" the query had been for the preferred label.

   This method also makes it possible to have CLONEs for more than one
   label at a given level in the DNS.

   The CLONES RR is intended to aid application developers by making it
   easier to know when a given label has one or more other labels that
   are configured as part of the same "bundle."

1.2.2.  DNSSEC

   An authoritative server may utilize what is commonly known as
   "dynamic signing" to handle DNSSEC [RFC4035] signatures for the CLONE
   labels.  Those zone managers who do not wish to (or cannot) utilize
   the dynamic signing method can rely on the end user being behind a
   CARNS, which when querying for a CLONE label can perform DNSSEC
   validation on the preferred version.


2.  The Authoritative Name Server







Barton                 Expires September 15, 2011               [Page 5]


Internet-Draft             Cloning DNS Labels                 March 2011


2.1.  Parent Zone File

2.1.1.  CLONE

   At any level of the DNS tree above the root itself ('.') a label MAY
   be specified as a CLONE.  For example:

   clone1 CLONE preferred

   In this example "preferred" would be the preferred label, "clone1"
   would be the CLONE.  Multiple CLONES MAY be defined for the same
   preferred label.  The RDATA for the CLONE RR MUST be either a valid
   DNS label, or a valid hostname that is also served by the same
   authoritative name server.  Compliant authoritative server
   implementations MUST generate a user error when attempting to load a
   zone that contains a CLONE RR with RDATA that is not served by that
   authoritative name server.

   Other than the DS RR for CLONEs whose preferred label is a zone cut,
   the CLONE label MUST NOT have any other data associated with it.  An
   authoritative name server above the zone cut (the "parent") MAY allow
   configuration of a DS record for a label that is a CLONE of the
   preferred label that is itself the point of the zone cut.  For
   example:

      preferred NS ns1.preferred

      preferred DS 123456789ABCDEF

      clone1 CLONE preferred

      clone1 DS FEDCBA987654321

   Compliant authoritative server implementations MUST generate a user
   error when attempting to load a zone that contains both a CLONE and
   any other RR (other than DS for a CLONE zone cut) for the same label.

2.1.2.  CLONES

   The CLONES RR is used to list the preferred label and all of its
   CLONEs.  If the zone does not contain a CLONES RR for the preferred
   label a compliant authoritative server MUST synthesize one at the
   time that the zone is loaded.  If the CLONES RR is already present in
   the zone (perhaps because the zone has been signed) the server MUST
   verify that it is correct.  Compliant implementations MUST generate a
   user error when attempting to load a zone that contains an incorrect
   CLONES RR.




Barton                 Expires September 15, 2011               [Page 6]


Internet-Draft             Cloning DNS Labels                 March 2011


2.2.  Child Authoritative Server Configuration

   If the preferred label is a delegation point, and the delegee wishes
   to answer for the CLONE label(s), the authoritative name server for
   the child zone with the preferred label MUST be configured for the
   CLONE(s).  An example that uses a BIND-style syntax follows, but this
   document is not attempting to specify how implementors perform this
   configuration.

   zone "clone1.example.org" { clone preferred.example.org; [ dnskey
   <key>; ] };

   Behavior of child authoritative servers which configure real zones
   for labels that the parent created as CLONEs of a preferred label is
   undefined.

2.3.  Query Response For Labels That Are CLONEs

   When a compliant authoritative name server implementation receives a
   query for a label or zone that is a CLONE, the server MUST respond
   "as if" it had received the query for the preferred label.  In the
   example above if the name server receives any query for
   clone1.example.org other than the CLONE or CLONES RRs, or as
   described below the DS or DNSKEY RRs, it MUST respond "as if" the
   query had been for preferred.example.org.

   If the authoritative name server receives the CLONE-Aware EDNS option
   it MUST add the CLONE RR to the ANSWER section of the query response
   with the preferred label as the RDATA.  This is similar to the
   behavior when the QNAME is a CNAME and the same server is
   authoritative for the canonical label.  If the DO bit is set in the
   query the server MUST include the RRSIG(s) for the CLONE RR itself.

2.3.1.  DNSSEC For The Parent Of A Zone Cut

   When the authoritative server which is the parent at a zone cut
   answers a query for a CLONE label when the querier sets the DO bit,
   and the CLONE label has a DS RR, a compliant server MUST return all
   records "as if" the QNAME had been the preferred label, except for
   the DS record; and the server MUST return the DS record of the CLONE
   with the appropriate RRSIGs.  This behavior is independent of the
   presence of the CLONE-Aware EDNS option.

2.3.2.  DNSSEC For The Dynamic-Signing Child

   For the authoritative server which is the child below a zone cut for
   the preferred label, when all of the following are true:




Barton                 Expires September 15, 2011               [Page 7]


Internet-Draft             Cloning DNS Labels                 March 2011


   o  The server is configured to do dynamic DNSSEC signatures

   o  The query has the DO bit set

   o  The CLONE has a DNSKEY configured

   the compliant implementation MUST return the answer for the CLONE
   zone "as if" the query had been for the preferred label, except that
   it MUST return the DNSKEY for the CLONE zone instead of the DNSKEY
   for the preferred label, and it MUST generate dynamic RRSIGs for all
   answers, signed with the CLONE's DNSKEY.  This behavior is
   independent of the presence of the CLONE-Aware EDNS option.

2.3.3.  DNSSEC For Other Authoritative Servers

   If the conditions in 2.3.1 or 2.3.2 are not met an authoritative
   server which receives a query which does not include the CLONE-Aware
   EDNS option MUST NOT return DNSSEC-related records along with the
   response, regardless of whether the DO bit was set in the query.  If
   the server receives both the DO bit and the CLONE-Aware EDNS option
   it MUST return the DNSSEC records for the answer "as if" the QNAME
   were the preferred label.

   The behavior described in this Section is relevant whether or not the
   preferred label is a zone cut.

2.4.  Query Response For CLONE And CLONES Resource Records

   When a compliant authoritative name server receives a query for the
   CLONE RR with a label that is a CLONE as the QNAME it MUST return an
   ANSWER with the preferred label as the RDATA.  When a compliant
   server receives a CLONE query for a label that is not a CLONE it MUST
   return RCODE 0 (No error).

   When a compliant server receives a query for the CLONES RR with a
   label that is a CLONE or a preferred label as the QNAME it MUST
   return an ANSWER with the preferred label listed first in the RDATA,
   followed by all of the labels that are configured as a CLONE of the
   preferred label.  If the label in the QNAME is neither a preferred
   label nor a CLONE the server MUST return RCODE 0 (No error).


3.  The CLONE-Aware Resolving Name Server

   When sending queries a compliant CARNS MUST send the EDNS option for
   CLONE-Aware.  When a compliant CARNS receives a query response which
   contains a CLONE RR as described in Section 2.3 it MUST "transform"
   future queries for hostnames or labels which it knows contain CLONE



Barton                 Expires September 15, 2011               [Page 8]


Internet-Draft             Cloning DNS Labels                 March 2011


   labels to the preferred version(s).  However regardless of whether
   the CARNS knows that a hostname it is queried for contains a CLONE
   label or not, the response to its client MUST be for the same QNAME
   it was queried for.

3.1.  CARNS DNSSEC Behavior For "Typical" Queries

   When a CARNS receives a response to a query that originally contained
   one or more CLONE labels that is signed with DNSSEC it MAY indicate
   that the response is authentic by setting the AD bit if all other
   conditions for setting it are otherwise met (i.e., the DO bit was set
   in the query originally received by the CARNS, etc.).  Local policy
   SHALL be the determining factor for whether to set the AD bit in the
   query response for the hostname which contains one or more CLONE
   labels if it were otherwise appropriate to do so.

3.2.  CARNS Behavior for DNSSEC Resource Record Queries

   When a CARNS receives a direct query for a DNSSEC-related RR for a
   hostname that contains one or more CLONE labels (e.g., RRSIG, DNSKEY,
   etc.), and those RRs are not configured as described in Sections
   2.3.1 and 2.3.2, it MUST return RCODE 0 (No answer) and include the
   CLONE RR with the preferred label as RDATA in the ADDITIONAL section
   of the response


4.  Examples

   Assuming a zone example.org with the following records:

   preferred A 192.0.2.1

   clone1 CLONE preferred

   clone2 CLONE preferred

4.1.  Non-CARNS

   +---+                      +-----------+                      +---+
   | S | clone1.example.org A |           | clone1.example.org A | A |
   | t |--------------------->| Non-CARNS |--------------------->| u |
   | u |                      |           |                      | t |
   | b |     192.0.2.1        |           |      192.0.2.1       | h |
   |   |<---------------------|           |<---------------------|   |
   +---+                      +-----------+                      +---+






Barton                 Expires September 15, 2011               [Page 9]


Internet-Draft             Cloning DNS Labels                 March 2011


4.2.  CARNS - First Query For CLONE

   +---+                      +---+                             +---+
   |   |                      |   |     clone1.example.org A    |   |
   | S | clone1.example.org A | C |     CLONE-Aware ENDS Opt    | A |
   | t |--------------------->| A |---------------------------->| u |
   | u |                      | R |                             | t |
   | b |                      | N |          192.0.2.1          | h |
   |   |     192.0.2.1        | S |    clone1 CLONE preferred   |   |
   |   |<---------------------|   |<----------------------------|   |
   +---+                      +---+                             +---+

4.3.  CARNS - Second Query For CLONE

   +---+                      +---+                             +---+
   |   |                      | C |   preferred.example.org A   |   |
   | S | clone1.example.org A | A |     CLONE-Aware ENDS Opt    | A |
   | t |--------------------->| R |---------------------------->| u |
   | u |                      | N |                             | t |
   | b |     192.0.2.1        | S |         192.0.2.1           | h |
   |   |<---------------------|   |<----------------------------|   |
   +---+                      +---+                             +---+

4.4.  CLONES Response

 +---+                                                             +---+
 | C |                                                             |   |
 | A |                 clone1.example.org CLONES                   | A |
 | R |------------------------------------------------------------>| u |
 | N |                                                             | t |
 | S | preferred.example.org clone1.example.org clone2.example.org | h |
 |   |<------------------------------------------------------------|   |
 +---+                                                             +---+


5.  IANA Considerations

   This document requests that the IANA assign the Resource Record (RR)
   Type Codes [RFC1035], [I-D.ietf-dnsext-5395bis] 77 and 88 to the
   CLONE and CLONES RRs, respectively; and the EDNS0 Option [RFC2671] 11
   for CLONE-Aware.


6.  Security Considerations

   There are currently (at least) two widely used solutions to the
   equivalence problem at the zone level.  For both of these solutions
   the preferred label and all of the variations need to be delegated,



Barton                 Expires September 15, 2011              [Page 10]


Internet-Draft             Cloning DNS Labels                 March 2011


   usually to the same set of name servers.  The obvious, albeit
   potentially the most difficult method of keeping the zones "the same"
   is to create multiple zone files that contain records that are
   identical to the extent possible.  This solution allows for the
   possibility of having DNSKEY records for each zone, thereby allowing
   each label's zone to be signed.

   The other solution that takes advantage of identical delegation is to
   use the exact same "generic" zone file for multiple zones.  This
   method provides for DNSSEC configuration in the typical way for the
   preferred label, but does not allow different DNSKEY records for the
   other labels in the same "bundle."  The records in the preferred
   version of the zone can be signed, but validation would fail for the
   other labels since the DNSKEY record would not be for that zone.
   This behavior is similar to the CLONE solution in the absence of both
   dynamic signing at the authoritative level and a validating CARNS.

   For parents (such as TLD registries) that allow the delegee/
   registrant to choose what method of "bundling" semantically similar
   labels to use, the techniques described in this document do not
   reduce security in any way.  The delegee can either decide as a
   matter of local policy that the DNSSEC capability of the CLONE
   technique is sufficient, or they can choose to have the non-preferred
   versions of the label delegated and maintain separate zone files.  In
   a context where the delegee is required to accept the CLONE option
   DNSSEC validation for the non-preferred versions of the label can be
   provided without relying on end users being behind a CARNS by
   utilizing dynamic signing.

   No negative security implications for the CLONE or CLONES RRs
   themselves are known, other than the possibility that the CLONES RR
   could be used as a Distributed Denial Of Service amplifier if it
   contained a sufficiently large ANSWER section.  It is envisioned that
   in certain contexts being able to verify that the non-preferred
   versions of a label have been listed as CLONEs rather than using some
   other method of "aliasing" (such as delegation, CNAME, etc.) could be
   beneficial.


7.  Acknowledgements

   I would like to thank all of the participants in the dnsext and dnsop
   working groups who discussed and fleshed out the ideas this document
   is responding to.  Particularly Suzanne Woolf and Xiaodong LEE for
   producing the Problem Statement
   [I-D.ietf-dnsext-aliasing-requirements] that this document is trying
   to provide a solution for; both for their diligent work on the topic,
   and for making it much simpler for me to write my Introduction.  I



Barton                 Expires September 15, 2011              [Page 11]


Internet-Draft             Cloning DNS Labels                 March 2011


   would also like to thank Nicholas Weaver for pushing me hard to think
   about how dynamic DNSSEC could fit into the CLONE idea.


8.  References

8.1.  Normative References

   [I-D.ietf-dnsext-5395bis]
              3rd, D., "Domain Name System (DNS) IANA Considerations",
              draft-ietf-dnsext-5395bis-03 (work in progress),
              January 2011.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

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

   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
              RFC 2671, August 1999.

   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection",
              RFC 2672, August 1999.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, March 2005.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, August 2010.

8.2.  Informative References

   [ASCII]    American National Standards Institute (formerly United
              States of America Standards Institute), "USA Code for
              Information Interchange", ANSI X3.4-1968, 1968.

   [I-D.ietf-dnsext-aliasing-requirements]
              Woolf, S. and X. Lee, "Problem Statement: DNS Resolution
              of Aliased Names",
              draft-ietf-dnsext-aliasing-requirements-00 (work in
              progress), February 2011.

   [RFC3743]  Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint
              Engineering Team (JET) Guidelines for Internationalized
              Domain Names (IDN) Registration and Administration for



Barton                 Expires September 15, 2011              [Page 12]


Internet-Draft             Cloning DNS Labels                 March 2011


              Chinese, Japanese, and Korean", RFC 3743, April 2004.


Author's Address

   Douglas Barton (editor)
   GridFury, LLC
   11901 Santa Monica Boulevard, Unit 612
   Los Angeles, CA  90025
   USA

   Email: dougb@dougbarton.us







































Barton                 Expires September 15, 2011              [Page 13]