dnsext D. Barton, Ed.
Internet-Draft GridFury, LLC
Intended status: Standards Track March 7, 2011
Expires: September 8, 2011
Cloning Domain Name System (DNS) Labels for Fun and Profit
draft-barton-clone-dns-labels-fun-profit-00.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 currently either CNAME or DNAME Resource
Records are being used.
A key design goal for the CLONE method is that except for DNSSEC
support all of the semantic benefits are available by updating the
authoritative servers for the zone. Therefore unless DNSSEC support
for the CLONEd zones is required there is no dependency on end 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 8, 2011 [Page 1]
Internet-Draft Cloning DNS Labels March 2011
1. -00 Initial version
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 8, 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 8, 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
2. The Authoritative Name Server . . . . . . . . . . . . . . . . 5
2.1. Parent Zone File . . . . . . . . . . . . . . . . . . . . . 5
2.2. Child Authoritative Server Configuration . . . . . . . . . 6
2.3. Query Response For CLONE Labels . . . . . . . . . . . . . 6
2.4. Query Response For CLONE And CLONES Resource Records . . . 7
3. The CLONE-Aware Resolving Name Server . . . . . . . . . . . . 7
3.1. CARNS DNSSEC Behavior For "Typical" Queries . . . . . . . 7
3.2. CARNS Behavior for DNSSEC Resource Record Queries . . . . 7
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Non-CARNS . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. CARNS - First Query For CLONE . . . . . . . . . . . . . . 8
4.3. CARNS - Second Query For CLONE . . . . . . . . . . . . . . 8
4.4. CLONES Response . . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Barton Expires September 8, 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 8, 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
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. In this
way if the preferred label is signed with DNSSEC [RFC4035] a CARNS
can perform DNSSEC validation on the response.
This method also makes it possible to have CLONEs for more than one
label in a given hostname.
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."
2. The Authoritative Name Server
2.1. Parent Zone File
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
Barton Expires September 8, 2011 [Page 5]
Internet-Draft Cloning DNS Labels March 2011
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.
The CLONE label MUST NOT have any other data associated with it.
Compliant authoritative server implementations MUST generate a user
error when attempting to load a zone that contains both a CLONE and
other RDATA for the same label.
The CLONES RR is used to list the preferred label and all of its
CLONES. It MUST NOT be defined in the zone file. Compliant
implementations MUST generate a user error when attempting to load a
zone that contains a CLONES RR.
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 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; };
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 CLONE Labels
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 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.
If a compliant server does not receive the CLONE-Aware EDNS option it
MUST NOT return DNSSEC-related records (such as RRSIG) along with the
response, regardless of whether the DO bit was set in the query.
Barton Expires September 8, 2011 [Page 6]
Internet-Draft Cloning DNS Labels March 2011
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 QDATA 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 QDATA it MUST
return an ANSWER with the preferred label listed first in the RDATA,
followed by all of labels that are configured as a CLONE of the
preferred label. If the label in the QDATA is neither a preferred
label or 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
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 QDATA
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.) 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
Barton Expires September 8, 2011 [Page 7]
Internet-Draft Cloning DNS Labels March 2011
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 |
| |<---------------------| |<---------------------| |
+---+ +-----------+ +---+
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 | CLONE RR clone1 > 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
Barton Expires September 8, 2011 [Page 8]
Internet-Draft Cloning DNS Labels March 2011
+---+ +---+
| 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,
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 zone to be signed. The other solution that takes advantage of
identical delegation is to use the exact same zone file for multiple
zones. This method provides the same capability for DNSSEC
compatibility as the CLONE method. The preferred label can be
signed, but validation would fail for the other labels since the
DNSKEY record would not be for that zone.
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 forced to accept the CLONE option
DNSSEC validation for the non-preferred versions of the label will be
limited to resolving name servers that are CLONE-Aware.
No negative security implications for the CLONE or CLONES RRs
themselves are known. It is envisioned that in certain contexts
Barton Expires September 8, 2011 [Page 9]
Internet-Draft Cloning DNS Labels March 2011
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. References
7.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.
7.2. Informative References
[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
Chinese, Japanese, and Korean", RFC 3743, April 2004.
Barton Expires September 8, 2011 [Page 10]
Internet-Draft Cloning DNS Labels March 2011
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 8, 2011 [Page 11]