draft-ietf-dnsext-aliasing-requirements-00.txt   draft-ietf-dnsext-aliasing-requirements-01.txt 
Network Working Group S. Woolf Network Working Group S. Woolf
Internet-Draft Internet Systems Consortium, Inc. Internet-Draft Internet Systems Consortium, Inc.
Intended status: Informational X. Lee Intended status: Informational X. Lee
Expires: August 26, 2011 CNNIC Expires: September 15, 2011 J. Yao
February 22, 2011 CNNIC
March 14, 2011
Problem Statement: DNS Resolution of Aliased Names Problem Statement: DNS Resolution of Aliased Names
draft-ietf-dnsext-aliasing-requirements-00.txt draft-ietf-dnsext-aliasing-requirements-01.txt
Abstract Abstract
This document attempts to describe a set of issues that arises from This document attempts to describe a set of issues that arises from
the desire to treat a set or group of names as "aliases" of each the desire to treat a set or group of names as "aliases" of each
other, "bundled," "variants," or "the same," which is problematic in other, "bundled," "variants," or "the same," which is problematic in
terms of corresponding behavior for DNS labels and FQDNs. terms of corresponding behavior for DNS labels and FQDNs.
With the emergence of internationalized domain names, among other With the emergence of internationalized domain names, among other
potential use cases, two or more names that users will regard as potential use cases, two or more names that users will regard as
skipping to change at page 1, line 47 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 26, 2011. This Internet-Draft will expire on September 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. What this document does . . . . . . . . . . . . . . . . . 5 1.1. What this document does . . . . . . . . . . . . . . . . . 5
1.2. What this document does not do . . . . . . . . . . . . . . 5 1.2. What this document does not do . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Registration of Domain Name Variants . . . . . . . . . . . 7 2.1. Registration of Domain Name Variants . . . . . . . . . . . 7
2.2. Identical DNS Resolution for Bundled DNS Names . . . . . . 8 2.2. Identical DNS Resolution for Bundled DNS Names . . . . . . 8
2.3. Character Variants . . . . . . . . . . . . . . . . . . . . 8 2.3. Character Variants . . . . . . . . . . . . . . . . . . . . 9
2.3.1. An example: Simplified and Traditional Chinese . . . . 9 2.3.1. An example: Simplified and Traditional Chinese . . . . 9
2.3.2. An example: Greek . . . . . . . . . . . . . . . . . . 9 2.3.2. An example: Greek . . . . . . . . . . . . . . . . . . 9
2.3.3. An Example: Arabic . . . . . . . . . . . . . . . . . . 10 2.3.3. An Example: Arabic . . . . . . . . . . . . . . . . . . 10
2.4. Use of Variants . . . . . . . . . . . . . . . . . . . . . 10 2.4. Use of Variants . . . . . . . . . . . . . . . . . . . . . 10
3. Operational Considerations . . . . . . . . . . . . . . . . . . 11 3. Operational Considerations . . . . . . . . . . . . . . . . . . 11
3.1. Zone Provisioning and Authority Servers . . . . . . . . . 11 3.1. Zone Provisioning and Authority Servers . . . . . . . . . 11
3.1.1. Provisioning of 'aliases' in the registry . . . . . . 11 3.1.1. Provisioning of 'aliases' in the registry . . . . . . 12
3.1.2. Impact of special mechanisms . . . . . . . . . . . . . 12 3.1.2. Impact of special mechanisms . . . . . . . . . . . . . 12
3.2. Recursive Resolvers . . . . . . . . . . . . . . . . . . . 12 3.2. Recursive Resolvers . . . . . . . . . . . . . . . . . . . 12
3.3. Applications . . . . . . . . . . . . . . . . . . . . . . . 13 3.3. Applications . . . . . . . . . . . . . . . . . . . . . . . 13
4. Proposed Requirements . . . . . . . . . . . . . . . . . . . . 14 4. Proposed Requirements . . . . . . . . . . . . . . . . . . . . 14
5. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 14 5. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Mapping or Redirection of Domain Names . . . . . . . . . . 15 5.1. Mapping or Redirection of Domain Names . . . . . . . . . . 16
5.1.1. Mapping itself . . . . . . . . . . . . . . . . . . . . 15 5.1.1. Mapping itself (CNAME) . . . . . . . . . . . . . . . . 16
5.1.2. Mapping its descendants . . . . . . . . . . . . . . . 15 5.1.2. Mapping its descendants . . . . . . . . . . . . . . . 16
5.1.3. Mapping itself and its descendants . . . . . . . . . . 16 5.1.3. Mapping itself and its descendants . . . . . . . . . . 17
5.2. Zone Clone . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2. Zone Clone . . . . . . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. draft-yao-dnsext-identical-resolution: Version 00 . . . . 18 9.1. draft-yao-dnsext-identical-resolution: Version 00 . . . . 19
9.2. draft-yao-dnsext-identical-resolution: Version 01 . . . . 18 9.2. draft-yao-dnsext-identical-resolution: Version 01 . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
As the Internet and the DNS have evolved beyond their original realms As the Internet and the DNS have evolved beyond their original realms
of use, a set of needs and expectations has appeared about how DNS of use, a set of needs and expectations has appeared about how DNS
labels behave that is informed significantly by common human labels behave that is informed significantly by common human
assumptions about how "names" or "words" work. One aspect of this is assumptions about how "names" or "words" work. One aspect of this is
the notion or expectation that multiple sets of names may be similar the notion or expectation that multiple sets of names may be similar
to a human user, and expected to behave "the same" or as "aliases" of to a human user, and expected to behave "the same" or as "aliases" of
one another, across multiple services and interactions. The DNS was one another, across multiple services and interactions. The DNS was
skipping to change at page 4, line 35 skipping to change at page 4, line 35
often because these labels are derived from names or strings that often because these labels are derived from names or strings that
users consider "the same" in some languages. Accordingly, Internet users consider "the same" in some languages. Accordingly, Internet
users hope for such labels to behave in DNS contexts as they expect users hope for such labels to behave in DNS contexts as they expect
the corresponding human constructs to behave, regardless of the the corresponding human constructs to behave, regardless of the
specific service (smtp, http, etc.) involved.. specific service (smtp, http, etc.) involved..
The general issues of what "the same" means, or of defining The general issues of what "the same" means, or of defining
"variants" in human scripts as codified in Unicode (or anywhere else) "variants" in human scripts as codified in Unicode (or anywhere else)
are well outside the scope of the DNS or the expertise of most of the are well outside the scope of the DNS or the expertise of most of the
people who work on it. They are matters for philosophers and people who work on it. They are matters for philosophers and
applications developers, respectively. However, to the extent that linguists, and for applications developers, respectively. However,
these issues can be specified as involving the resolution of names in to the extent that these issues can be specified as involving the
the DNS, it's reasonable to describe those expectations and attempt resolution of names in the DNS, it's reasonable to describe those
to accommodate them. expectations and attempt to accommodate them.
There is some existing technology defined in the DNS for behavior There is some existing technology defined in the DNS for behavior
that can be described as one name behaving "the same" as another. that can be described as one name behaving "the same" as another.
For a single node in the DNS tree, CNAME can be used to map one name For a single node in the DNS tree, CNAME can be used to map one name
as an "alias" to another, "canonical" name. If there is a need to as an "alias" to another, "canonical" name. If there is a need to
map a subtree of the DNS-- a zone, or a domain and its subdomains-- map a subtree of the DNS-- a zone, or a domain and its subdomains--
to another domain, DNAME has been defined to allow this behavior. to another domain, DNAME has been defined to allow this behavior.
However, there is no way currently defined to do both, as CNAME is However, there is no way currently defined to do both, as CNAME is
required to be the sole record at its node in the tree. Behavior required to be the sole record at its node in the tree. Behavior
that combines the characteristics of CNAME and DNAME is not currently that combines the characteristics of CNAME and DNAME is not currently
skipping to change at page 5, line 40 skipping to change at page 5, line 40
DNS "labels" from "words" (a human construct) and "strings" (which we DNS "labels" from "words" (a human construct) and "strings" (which we
use here as machine-readable constructs that nonetheless may not use here as machine-readable constructs that nonetheless may not
conform to DNS label constraints, such as IDNA U-labels). The conform to DNS label constraints, such as IDNA U-labels). The
distinctions among what humans type or see, what applications use, distinctions among what humans type or see, what applications use,
and what DNS stores and resolves are sometimes subtle but and what DNS stores and resolves are sometimes subtle but
particularly important. particularly important.
A list of broad requirements is proposed for any DNS protocol changes A list of broad requirements is proposed for any DNS protocol changes
that might be undertaken. that might be undertaken.
We also review existing constructs (CNAME, DNAME) and proposed new We also review existing technologies (CNAME, DNAME) and proposed new
ones ("BNAME," "zone clones") against the proposed requirements. ones ("BNAME," "zone clones") against the proposed requirements.
1.2. What this document does not do 1.2. What this document does not do
This document makes no attempt to solve or even describe This document makes no attempt to solve or even describe
"translation" of one name into another in the DNS, which is likely to "translation" of one name into another in the DNS, which is likely to
be impossible. "Translation" in general, or even the particular be impossible. "Translation" in general, or even the particular
problem of determining when or why two DNS labels (or even FQDNs) problem of determining when or why two DNS labels (or even FQDNs)
should be considered "the same", is simply not in scope for the DNS should be considered "the same", is simply not in scope for the DNS
protocol. We pre-suppose those decisions are made elsewhere and that protocol. We pre-suppose those decisions are made elsewhere and that
the DNS needs to deliver behavior in conformance with that external the DNS needs to deliver behavior in conformance with that external
decision. In particular, we're talking about creating a property or decision. In particular, we're talking about creating a property or
association among a set of DNS names as "sameness" or "alias-of", but association among a set of DNS names as "sameness" or "alias-of", but
the correspondence between that set and any set of human- or the correspondence between that set and any set of human- or
application-visible strings is created outside of the DNS database application-visible strings is created outside of the DNS database
and protocol. and protocol. Language Variant Tables (RFC3743) serve as guides for
registration policy, but the associations they create are basically
expressed only as policy about what can be registered, not visible to
DNS resolvers, applications, or users.
Accordingly, this document makes no comment on policy regarding when Accordingly, this document makes no comment on policy regarding when
two names are "the same," what restrictions should be placed on their two names are "the same," what restrictions should be placed on their
generation or use outside those imposed by the DNS protocol, or the generation or use outside those imposed by the DNS protocol, or the
ability of one approach over another to instantiate what a given user ability of one approach over another to instantiate what a given user
regards as "the same" for a language, script, culture, community, regards as "the same" for a language, script, culture, community,
application, encoding, or purpose. application, encoding, or purpose.
1.3. Terminology 1.3. Terminology
skipping to change at page 7, line 27 skipping to change at page 7, line 29
A further question arises with respect to how applications should A further question arises with respect to how applications should
interact with alias-specific DNS behavior. A basic requirement would interact with alias-specific DNS behavior. A basic requirement would
seem to be "First, do no harm," or in other words, any extensions to seem to be "First, do no harm," or in other words, any extensions to
DNS protocol in support of the desired "alias" behavior should not DNS protocol in support of the desired "alias" behavior should not
interfere with applications that expect to do such interpretation on interfere with applications that expect to do such interpretation on
their own. This concern is based in the expectation that DNS is their own. This concern is based in the expectation that DNS is
simple and predictable, operating strictly as infrastructure under simple and predictable, operating strictly as infrastructure under
the process of creating "the user experience," not as part of it. the process of creating "the user experience," not as part of it.
A key point in evaluating these questions is that DNS is a lookup-
based protocol. A DNS name either resolves, or not. There's no
search function in the DNS, no fuzzy match. It provides lookup on a
specified name. This is critically important because it means that
any work to define any kind of "sameness" that can't be expressed as
a lookup, such as selection among a set of candidate names for which
to return results, must be done elsewhere than in the DNS.
2.1. Registration of Domain Name Variants 2.1. Registration of Domain Name Variants
The introduction of IDN has provided a forcing function for defining To some degree, issues of "sameness" or creating an association among
how "variants" might behave as DNS names. It's generally conceded a set of names have existed around the use of domain names from the
that recognition and careful management of cases where multiple names beginning. Points where the behavior of DNS labels have collided
are associated together as "variants" in the expectation or with expectations around the behavior of words have included DNS
preference of users are important; without such management of grouped handling of case sensitivity, the kind of transformations a human
domain names, security risks may be increased and the quality of user expects to "just work" around "try-this.example" vs.
experience may be compromised. [RFC3743] developed by JET (Joint "trythis.example", and continuing frustration that "confusingly
Engineering Team) gives one possible solution of how to manage similar" names can be delegated to different parties by DNS
registration of a domain name, intended to be applied to the script registries. However, the introduction of IDN has provided a forcing
and usage common across Chinese, Japanese, and Korean users. function in that it has added visibility for a wider variety of
[RFC3743] proposed an algorithm which will allocate a group of names, issues along these lines, and possibly the urgency of dealing with
consisting of a domain name and its variants, to the same domain them for large numbers of users.
holder. It means that the domain holder will get control of the
domain name and its variants. [RFC4290] suggests the practice in A need has been identified in connection with the introduction of IDN
[RFC3743] to be used in registrations of internationalized domain for defining how "variants" might behave as DNS names. Specifically
defining "variant" is a matter for experts, but it's generally
conceded that recognition and careful management of cases where
multiple names are associated together as "variants" in the
expectation or preference of users are important; without such
management of grouped domain names, security risks may be increased
and the quality of user experience may be compromised. [RFC3743]
developed by JET (Joint Engineering Team) gives one possible solution
of how to manage registration of a domain name, intended to be
applied to the script and usage common across Chinese, Japanese, and
Korean users. [RFC3743] proposed an algorithm which will allocate a
group of names, consisting of a domain name and its variants, to the
same domain holder. It means that the domain holder will get control
of the domain name and its variants. [RFC4290] suggests the practice
in [RFC3743] to be used in registrations of internationalized domain
names. But [RFC3743] and [RFC4290] do not define how, exactly, these names. But [RFC3743] and [RFC4290] do not define how, exactly, these
bundles of names are to be treated by the registry or the DNS in bundles of names are to be treated by the registry or the DNS in
order to obtain the desired "identical" behavior. [RFC4690] said order to obtain the desired "identical" behavior. [RFC4690] said
that the "variant" model introduced in [RFC3743] and [RFC4290] can be that the "variant" model introduced in [RFC3743] and [RFC4290] can be
used by a registry to prevent the most negative consequences of used by a registry to prevent the most negative consequences of
possible confusion, by ensuring either that both names are registered possible confusion, by ensuring either that both names are registered
to the same party in a given domain or that one of them is completely to the same party in a given domain or that one of them is completely
prohibited. The principles described in [RFC3743], [RFC4290] and prohibited. The principles described in [RFC3743], [RFC4290] and
[RFC4690] have been accepted by many registries. But the technical [RFC4690] have been accepted by many registries. But the technical
details of how to guarantee that a bundle of domain names are details of how to guarantee that a bundle of domain names are
"identical" in the DNS remain unspecified. "identical" in the DNS remain unspecified.
2.2. Identical DNS Resolution for Bundled DNS Names 2.2. Identical DNS Resolution for Bundled DNS Names
To some extent, the desired behavior can be described: "identical DNS To some extent, the desired behavior can be described: "identical DNS
resolution" means that the process of resolving two domain names will resolution" means that the process of resolving two domain names will
end with the same result, in most cases the same IP address. In the end with the same result, in most cases the same IP address. In the
history of DNS protocol development, there have been two attempts to history of DNS protocol development, there have been two attempts to
skipping to change at page 8, line 36 skipping to change at page 9, line 13
the addition of new ones in the DNS protocol. the addition of new ones in the DNS protocol.
2.3. Character Variants 2.3. Character Variants
Many defined scripts as used in many different languages have Many defined scripts as used in many different languages have
"character variants" included. There is no uniform definition of "character variants" included. There is no uniform definition of
variants, and in fact their characteristics differ widely, but it's variants, and in fact their characteristics differ widely, but it's
possible to define some. For example, the definition of variant possible to define some. For example, the definition of variant
characters in the JET Guidelines [RFC3743], intended for use with the characters in the JET Guidelines [RFC3743], intended for use with the
CJK language/script communities, is roughly this: One conceptual CJK language/script communities, is roughly this: One conceptual
character can be identified with several different Code Points in character can be identified with several different code points in
character sets for computer use. In UNICODE definitions of some character sets for computer use. In UNICODE definitions of some
scripts, including Han (chinese), some characters can be identified scripts, including Han (chinese), some characters can be identified
as "compatibility variants" of another character, which usually as "compatibility variants" of another character, which usually
implies that the first can be remapped to the second without the loss implies that the first can be remapped to the second without the loss
of any meaning. In this document, variant characters are two or more of any meaning. In this document, variant characters are two or more
characters that may be similar in appearance or identical in meaning characters that may be similar in appearance or identical in meaning
(similarity in appearance is not required by the definition but often (similarity in appearance is not required by the definition but often
occurs). occurs).
With the introduction of IDNs in the DNS, perhaps most prominently in With the introduction of IDNs in the DNS, perhaps most prominently in
skipping to change at page 9, line 13 skipping to change at page 9, line 37
Cyrillic, and others. Cyrillic, and others.
2.3.1. An example: Simplified and Traditional Chinese 2.3.1. An example: Simplified and Traditional Chinese
For example, the IDN TLD "China"(U+4E2D U+56FD) and its variant For example, the IDN TLD "China"(U+4E2D U+56FD) and its variant
(U+4E2D U+570B) are in the root today. The first one (U+4E2D U+56FD) (U+4E2D U+570B) are in the root today. The first one (U+4E2D U+56FD)
can be considered the "original" IDN TLD and the second one (U+4E2D can be considered the "original" IDN TLD and the second one (U+4E2D
U+570B) can be considered the IDN TLD "variant". Ideally, it should U+570B) can be considered the IDN TLD "variant". Ideally, it should
be possible to treat the original IDN TLD and its IDN TLD variant as be possible to treat the original IDN TLD and its IDN TLD variant as
"identical" for purposes of DNS resolution, in a way similar to the "identical" for purposes of DNS resolution, in a way similar to the
case mapping most DNS users take for granted, in which the uppercase case mapping most DNS users take for granted. However, this analogy
"A" is the variant of lowercase "a". For example, the string ".COM" is a bit perilous, and turns out to be hard to use as a guide to what
can be considered a variant of ".com", and the corresponding DNS behavior is actually desirable, not least because it's not fully
labels are treated as identical. However, for the historical reasons consistent even within the DNS.
already discussed, and technical reasons having to do with the
underpinnings of the IDNAbis protocol (ref: IDNAbis rationale),
there's no generalization of the "case" mapping available for
situations where it might be useful for IDNs. In addition, it's
perilous because DNS rules around "case insensitivity" and "case
preservation" are not intuitively consistent; for example, case
folding is done for comparison but not for compression.
At this writing, four Han script IDN TLDs are in the root, including At this writing, four Han script IDN TLDs are in the root, including
two pairs comprising a Traditional Chinese name and its Simplified two pairs comprising a Traditional Chinese name and its Simplified
counterpart. These operators will, in an ideal world, be able to counterpart. These operators will, in an ideal world, be able to
share some operational experience around implementation of registry share some operational experience around implementation of registry
policy regarding managing multiple DNS trees as "the same" policy regarding managing multiple DNS trees as "the same"
2.3.2. An example: Greek 2.3.2. An example: Greek
In Greek, almost every word has the "tonos" accent sign, but where it In Greek, almost every word has the "tonos" accent sign, but where it
skipping to change at page 13, line 40 skipping to change at page 14, line 8
Currently HTTP has such an ability, but it's considered awkward to Currently HTTP has such an ability, but it's considered awkward to
use and does not help writers or users of other application use and does not help writers or users of other application
protocols. protocols.
An important characteristic of such a solution for applications, An important characteristic of such a solution for applications,
however, is that the writer and user be able to tell when such a however, is that the writer and user be able to tell when such a
mechanism was invoked in the DNS, to avoid interference among mechanism was invoked in the DNS, to avoid interference among
multiple possible ways to find "aliases" and compare them. This in multiple possible ways to find "aliases" and compare them. This in
turn implies a fair amount of complexity to be inflicted not only on turn implies a fair amount of complexity to be inflicted not only on
DNS protocol but also on API/library writers seeking to use such new DNS protocol but also on API/library writers seeking to use such new
facilities. facilities, particularly given the caution above that DNS is a lookup
protocol and must be given precise sequences of bits to look up.
Another characteristic of an "aliases" mechanism of interest to Another characteristic of an "aliases" mechanism of interest to
application writers is the difficulty, and therefore the likely speed application writers is the difficulty, and therefore the likely speed
and breadth of deployment, of such a DNS-based mechanism for and breadth of deployment, of such a DNS-based mechanism for
canonicalizing aliased names. DNS is notorious, as an aging canonicalizing aliased names. DNS is notorious, as an aging
infrastructure protocol, for the long tail of deployment of infrastructure protocol, for the long tail of deployment of
significant protocol features. Again, a feature can be designed to significant protocol features. Again, a feature can be designed to
be fairly easy to deploy, but without an incentive such as faster be fairly easy to deploy, but without an incentive such as faster
application development or more secure applications, it stlil may not application development or more secure applications, it still may not
see wide uptake even after it's present in current code bases. see wide uptake even after it's present in current code bases.
An additional assumption often made needs to be examined here, as
well: that applications, and applications writers, have
straightforward, well-defined ways of interacting with the DNS, into
which new functionality can obviously and straightforwardly be added.
This can be true, as in the case of a query for a specific RRtype at
an unambiguously determined name by an application designed to find
and take advantage of the data represented in records of that RRtype.
However, it does not have to be, and often isn't: there's no standard
DNS API, and no standard abstraction for applications to interact
with the DNS. There is confusion about how to use DNS effectively,
and over the actual behavior of existing "alias" mechanisms such as
CNAME. Adding new technology is likely to be accompanied by
challenges not only in getting it deployed to the installed base, but
in getting its uses clearly documented for applications writers.
4. Proposed Requirements 4. Proposed Requirements
These observations and examples, along with general discussion to These observations and examples, along with general discussion to
date, lead to the following tentative set of actual requirements. date, lead to the following tentative set of actual requirements.
1. Any mechanism proposed in the DNS to support "aliases" or 1. Any mechanism proposed in the DNS to support "aliases" or
multiple names as "the same" MUST be workable for DNSSEC- signed multiple names as "the same" MUST be workable for DNSSEC- signed
zones. zones.
2. Any mechanism proposed in the DNS to support "aliases" or 2. Any mechanism proposed in the DNS to support "aliases" or
multiple names as "the same" MUST be "backwards compatible," in multiple names as "the same" MUST be "backwards compatible," in
skipping to change at page 15, line 19 skipping to change at page 16, line 7
("preferred" in the terminology of the JET variant mechanism) and any ("preferred" in the terminology of the JET variant mechanism) and any
others bundled with it are to be considered "variants" or "aliases". others bundled with it are to be considered "variants" or "aliases".
The only known way to enforce a symmetrical or equivalent association The only known way to enforce a symmetrical or equivalent association
is via careful registry provisioning within and across domains. In is via careful registry provisioning within and across domains. In
addition, the different "alias" mechanisms differ in subtle ways that addition, the different "alias" mechanisms differ in subtle ways that
have to be carefully reviewed against the desired behavior of the DNS have to be carefully reviewed against the desired behavior of the DNS
in support of different types of "variants". in support of different types of "variants".
5.1. Mapping or Redirection of Domain Names 5.1. Mapping or Redirection of Domain Names
5.1.1. Mapping itself 5.1.1. Mapping itself (CNAME)
It was recognized as part of the original specification of the DNS It was recognized as part of the original specification of the DNS
that a host can have many names; in fact this expectation predates that a host can have many names; in fact this expectation predates
the DNS, referring to the earlier specification of host names. In the DNS, referring to the earlier specification of host names. In
the simplest case for "aliases", Internet users need these multiple the simplest case for "aliases", Internet users need these multiple
names to be resolved to the same IP address by a DNS server. The names to be resolved to the same IP address by a DNS server. The
CNAME record [RFC1034], where "CNAME" is an abbreviation for CNAME record [RFC1034], where "CNAME" is an abbreviation for
"Canonical Name", is a way to designate aliases of the "real" or "Canonical Name", is a way to designate aliases of the "real" or
canonical name of a host. In some cases, CNAME can be used to canonical name of a host. In some cases, CNAME can be used to
produce the necessary association a bundle of variant domain names. produce the necessary association a bundle of variant domain names.
But the CNAME only maps itself, not its descendants; in fact it is But the CNAME only maps itself, not its descendants; in fact it is
defined to not have descendants, as it is the only name at a node in defined to not have descendants, as it is the only name at a node in
the DNS tree and can't exist at the same name as delegation. In the the DNS tree and can't exist at the same name as delegation. In the
case of IDN variants, however, it is often desirable that the name case of IDN variants, however, it is often desirable that the name
map both itself and its descendants. map both itself and its descendants.
In terms, however, of deployment and availability, it's useful to
note that CNAME is already part of the installed base of DNS
authority servers and intermediate mode resolvers. Using it for this
purpose requires description of how to do it and how it behaves, but
that already is available. There are no issues of uptake or
backwards compatibility or new code or new documentation.
5.1.2. Mapping its descendants 5.1.2. Mapping its descendants
In order to maintain the address-to-name mappings in a context of In order to maintain the address-to-name mappings in a context of
network renumbering, a DNAME record or Delegation Name record defined network renumbering, a DNAME record or Delegation Name record defined
by [RFC2672] was invented to create an alias for all its subdomains. by [RFC2672] was invented to create an alias for all its subdomains.
In contrast, the CNAME record creates an alias only of a single name In contrast, the CNAME record creates an alias only of a single name
(and not of its subdomains). As with the CNAME record, the DNS (and not of its subdomains). As with the CNAME record, the DNS
lookup will continue by retrying the lookup with the new name. If a lookup will continue by retrying the lookup with the new name. If a
DNS resolver sends a query without EDNS[EDNS0], or with EDNS version DNS resolver sends a query without EDNS[EDNS0], or with EDNS version
0, then a name server synthesizes a CNAME record to simulate the 0, then a name server synthesizes a CNAME record to simulate the
semantics of the DNAME record. A DNAME record is very much like the semantics of the DNAME record. A DNAME record is very much like the
CNAME record, but while the CNAME record only applies for one name, CNAME record, but while the CNAME record only applies for one name,
with a DNAME record one can create aliases for all the records for with a DNAME record one can create aliases for all the records for
its subdomain. its subdomain.
DNAME is can be considered slightly less widely deployed than CNAME
for the EDNS0 compatibility reason described above, but it's been
defined in the DNS for quite some time, and includes a backwards
compatibility mechanism in the CNAME synthesis just described, so use
of DNAME does not rely on deployment of resolver code capable of
special processing for DNAME; it relies entirely on authority server
capability.
5.1.3. Mapping itself and its descendants 5.1.3. Mapping itself and its descendants
Bundling of "variant" strings or names as domain names, possibly Bundling of "variant" strings or names as domain names, possibly
along with other use cases not yet identified, require the ability to along with other use cases not yet identified, require the ability to
map a whole tree of the domain space to another domain. The current map a whole tree of the domain space to another domain. The current
DNS protocols do not support this function. A new DNS resource DNS protocols do not support this function. A new DNS resource
record [BNAME] has been proposed to deal with this problem. record [BNAME] has been proposed to deal with this problem.
The advantage of BNAME is that it would enable a class of "aliasing" The advantage of BNAME is that it would enable a class of "aliasing"
behavior that some operators find desirable, particularly in behavior that some operators find desirable, particularly in
skipping to change at page 16, line 31 skipping to change at page 17, line 31
Alternatively, a proposal has been made that would leave CNAME as Alternatively, a proposal has been made that would leave CNAME as
already specified, but eliminating the constraint that a CNAME must already specified, but eliminating the constraint that a CNAME must
be alone at a node in the DNS tree. This would avoid any coding and be alone at a node in the DNS tree. This would avoid any coding and
deployment overhead associated with new RRtypes, while obtaining the deployment overhead associated with new RRtypes, while obtaining the
desired behavior. Concerns expressed about it, however, include the desired behavior. Concerns expressed about it, however, include the
possible (but not yet specified) effort required for backwards possible (but not yet specified) effort required for backwards
compatibility to avoid harm to implementations that expect, and use, compatibility to avoid harm to implementations that expect, and use,
the old behavior. the old behavior.
Both of these mechanisms would require both authority server and
resolver changes to enable the new capability.
5.2. Zone Clone 5.2. Zone Clone
The proposal of "zone clone" or "dns shadow", is an alternative The proposal of "zone clone" or "dns shadow", is an alternative
solution for a higher level of support than the DNS currently solution for a higher level of support than the DNS currently
provides for "alias" behavior across zones. In this scheme, a new provides for "alias" behavior across zones. In this scheme, a new
RRtype, SHADOW, is specified; it can exist at a zone apex and can be RRtype, SHADOW, is specified; it can exist at a zone apex and can be
used to define "clones" or "shadows" of the zone content so that used to define "clones" or "shadows" of the zone content so that
records in the zone are reachable via lookups from multiple records in the zone are reachable via lookups from multiple
delegations. This mechanism varies fundamentally from CNAME/DNAME/ delegations. This mechanism varies fundamentally from CNAME/DNAME/
BNAME in that it creates a local copy on each cooperating BNAME in that it creates a local copy on each cooperating
skipping to change at line 909 skipping to change at page 22, line 4
Phone: +1 650 423 1333 Phone: +1 650 423 1333
Email: woolf@isc.org Email: woolf@isc.org
Xiaodong LEE Xiaodong LEE
CNNIC CNNIC
No.4 South 4th Street, Zhongguancun No.4 South 4th Street, Zhongguancun
Beijing Beijing
Phone: +86 10 58813020 Phone: +86 10 58813020
Email: lee@cnnic.cn Email: lee@cnnic.cn
Jiankang YAO
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing
Phone: +86 10 58813007
Email: yaojk@cnnic.cn
 End of changes. 23 change blocks. 
59 lines changed or deleted 112 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/