Internet DRAFT - draft-barton-clone-dns-labels-fun-profit
draft-barton-clone-dns-labels-fun-profit
dnsext D. Barton, Ed.
Internet-Draft GridFury, LLC
Intended status: Standards Track September 14, 2011
Expires: March 17, 2012
Cloning Domain Name System (DNS) Labels for Fun and Profit
draft-barton-clone-dns-labels-fun-profit-02.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 March 17, 2012 [Page 1]
Internet-Draft Cloning DNS Labels September 2011
1. -00 Initial version
2. -01 Minor textual edits, add support for dynamic signing, clarify
CLONE labels that are not zone cuts
3. -02 Bump date to avoid expiry
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 March 17, 2012.
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 March 17, 2012 [Page 2]
Internet-Draft Cloning DNS Labels September 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 March 17, 2012 [Page 3]
Internet-Draft Cloning DNS Labels September 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 March 17, 2012 [Page 4]
Internet-Draft Cloning DNS Labels September 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 March 17, 2012 [Page 5]
Internet-Draft Cloning DNS Labels September 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 March 17, 2012 [Page 6]
Internet-Draft Cloning DNS Labels September 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 March 17, 2012 [Page 7]
Internet-Draft Cloning DNS Labels September 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 March 17, 2012 [Page 8]
Internet-Draft Cloning DNS Labels September 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 March 17, 2012 [Page 9]
Internet-Draft Cloning DNS Labels September 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 March 17, 2012 [Page 10]
Internet-Draft Cloning DNS Labels September 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 March 17, 2012 [Page 11]
Internet-Draft Cloning DNS Labels September 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 March 17, 2012 [Page 12]
Internet-Draft Cloning DNS Labels September 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 March 17, 2012 [Page 13]
