Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt

From: Brian Dickson <[email-masked]>
Date: Sun, 13 Mar 2011 00:06:10 -0400

On Wed, Feb 23, 2011 at 7:47 AM, Suzanne Woolf <[email-masked]> wrote:
>
> Colleagues,
>
> Per the announcement to the list last night, the -00 of the "aliases"
> problem statement has been posted to the i-d repository.
>
> Your comments are sought. It was pushed out this week to keep the
> discussion here going.
>
> It's a working draft and obviously needs a number of refinements on
> terminology and details, but the most important thing to establish at
> this point is whether it gets the overall landscape right.
>
> I hope we will have a -01 ready before Prague, so we can have a strong
> document by then and focus in the meeting on some decisions.
>
>
> best,
> Suzanne

(Thank you, Suzanne, and all other commentators, authors of related
drafts, and chairs for their diligence in getting this moved forward.)

This is definitely a good starting place, and I'll try to limit my
comments to proposed text for purposes of clarifying, adding analysis,
and including another proposed solution.

Comments follow below.

Brian

In Section 3.1, I think there would be benefit from addressing an
operational issue that distinguishes "client-side" from "server-side"
mechanisms, with xNAME being the former, and ZONE CLONE, CLONE, and
DS2 being examples of the latter.

Proposed text:

3.1.3 Aliased Zones Validation

In configuring traditional DNS zones, there are a number of tools
generally available for verifying that the authority server is
configured properly, from both above and below the zone cut.
These typically include a "config checker",  a "zone checker", and a
"delegation checker", which respectively ensure the metadata (causing
the zone to load), the data (the zone itself), and the relational
logic (delegation consistency and non-lameness) are correct (for some
meaning of "correct").
Since the presumption in the requirements document is that there will
be nontrivial numbers of "variant" zones, and zones with non-trivial
numbers of "variants" themselves, consideration for which mechanism is
used, and where, should be given to whether the mechanism supports
such checking.

For example, the xNAME solutions, as a general rule, do not inherently
provide means for non-trivial verification that the "target" of the
xNAME is valid. More precisely, that the target exists is something
which can only be determined empirically, and that the target might
cease to exist subsequent to the validation.

And as a counter-example, DS2 (and possibly one or both CLONE
proposals), being authority-server based solutions, necessarily
include automatic verification of the correctness of the "variants",
whenever the zone files or the server configuration files are modified
(and applied).

 ---

In section 4, additional text should draw attention to the
consequences of particular solutions, in terms of their effectiveness
in addressing scaling disparities introduced by the combination of
DNSSEC and Variants.

Proposed  text (bullet point(s)/sub-bullet-points?):

While DNSSEC is known already to produce modest additional
requirements on DNS operators, the combination of DNSSEC and Variants
together could potentially pose a significant cost, if care is not
used in making solutions which scale well available. Poor scaling
could be a barrier to entry in the use of DNSSEC for DNS users whose
locale requires (literally, or figuratively) the use of Variants.

 ---

In section 5, please also include reference to DS2.

Proposed text (sentences, paragraphs, and/or new sections):

 (text modified to read)
Names direction[BNAME], "Zone Clone", and "Zone Signature Re-Use [DS2]".

(new section)

5.3 Zone Signature Re-Use

   The proposal of "Zone Signature Re-Use" or "DS2" (the new RRTYPE), is a
   DNSSEC enhancement for an existing, but underused, alternative
   solution for providing for "alias" behavior across zones.  In this
scheme, a new
   RRtype, DS2, is specified; it exists at a zone cut, and is
   used to define the "canonical signer" of the zone content so that
   records in the child zone are validated as if they were in the
canonical signer's zone.

   This mechanism varies fundamentally from CNAME/DNAME/BNAME
   in that it uses a copy of (or alternatively, a link to) the
original zone, reachable by the
   name specified at the zone cut(s), and signed by the "canonical signer name"
   of the associated DS2 RR.  Its scope is the (variant) zone.

   Other than the DS2 itself, and the modification to validation of
RRSIGs, the idea of using zone cuts,
   and re-using zone contents or entire zone files, while moderately
novel, is already supported by the DNS specifications.
   Replacing CNAMEs and/or DNAMEs by zone cuts and having the children
of both the original name (the target) and the new alias,
   be the exact same zone file, is something that works today.

   The entire zone content (RDATA) of the original zone and all the
variants are the same, with only the
   prefix portion (the rightmost labels, or the zone owner name) on
the owner names of the zone RRs differing.
   This extends to include DNSSEC RRTYPEs. The DS2 directs validators
to use the "canonical signer name"
   in place of the "signer name" in the validation process. Since the
"signer name" is ALWAYS the zone owner name,
   this is a 1:1 replacement which introduces no additional security
issues per se, and the scope is precisely the child zone.
   The signer name of grand-children zones are specified either
implicitly (via DS) or explicitly (via DS2), and thus do not
   inherit from the child (i.e. the grand-child's parent) zone's DS2 RR.

   Like "Zone Clone", this scheme has the advantage that it allows a
DS2-signed zone to be used
   in all the same contexts as the canonical or underlying zone,
   including contexts where a CNAME or DNAME (or, presumably, a BNAME)
   cannot appear, such as in the RDATA of certain RRtypes.  Of the
   proposed DNS protocol mechanisms, it probably comes closest to the
   behavior some have requested as "equivalence," where none of the
   bundled or SHADOW names is canonical or preferred over the others.

  The operator effort, and level of skill, are remarkably modest. The
zone operator needs
  to configure the authority server to be authoritative for the
variants. The zone signing
  process is unchanged (once the zone is signed by one of the
variants). The registration
  of the DS in the parent zone(s) is replaced or augmented with the
DS2, whose parameters
  are literal copies of the original DS value, with the addition of
the primary variant name as the
  signer name in the DS2 record. (This is copy/paste level of difficulty.)

  There are operational benefits to DS2, in that the variants are
implemented by means of a zone cut.
  The authority server explicitly has all variants configured, and
thus the standard zone validation mechanisms are supported.
  The authority server has explicit knowledge of which variants exist
on the parent side (unlike xNAME targets).
  The performance impact of adding variants to a DNSSEC-signed zone,
in terms of RRSIG activity, is nil.
   Validators may optionally short-cut validation of variants RRSIGs,
once one of a variants' RRSIGs has been validated - it can be re-used.
   Since there is no "chaining", compared to xNAME processing, there
is no risk of excessive label counts, name lengths, or loops.
   The performance of all variants of a given number of labels/zones
can expect to be comparable, with an upper bound on the time needed
for resolution (if resolution succeeds).

---

From: Doug Barton <[email-masked]>
Date: Sat, 12 Mar 2011 23:37:14 -0800

As promised here are my suggestions for various minor changes, plus 
language for the CLONE method, if you're so inclined. :)  I realize that 
we're close to the deadline for -01 drafts (boy, do I realize it!) but 
here it is in any case.

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

--- draft-ietf-dnsext-aliasing-requirements-00.txt	2011-02-22 16:08:14.000000000 -0800
+++ draft-ietf-dnsext-aliasing-requirements-00-db.txt	2011-03-12 23:28:14.000000000 -0800
@@ -13,7 +13,7 @@
 
 Abstract
 
-   This document attempts to describe a set of issues that arises from
+   This document attempts to describe a set of issues that arise from
    the desire to treat a set or group of names as "aliases" of each
    other, "bundled," "variants," or "the same," which is problematic in
    terms of corresponding behavior for DNS labels and FQDNs.
@@ -23,8 +23,8 @@
    having identical meaning may sometimes require corresponding behavior
    in the underlying infrastructure, possibly in the DNS itself.  It's
    not clear how to accommodate this required behavior of such names in
-   DNS resolution; in particular, it's not clear when they are best
-   accommodated in registry practices for generating names for lookup in
+   DNS resolution. In particular, it's not clear where they are best
+   accommodated: In registry practices for generating names for lookup in
    the DNS, existing DNS protocol elements and behavior, existing
    application-layer mechanisms and practices, or some set of protocol
    elements or behavior not yet defined.  This document attempts to
@@ -172,7 +172,7 @@
 1.  Introduction
 
    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
    assumptions about how "names" or "words" work.  One aspect of this is
    the notion or expectation that multiple sets of names may be similar
@@ -190,10 +190,10 @@
    zones.  In some cases, these labels [RFC3743] are accompanied by the
    expectation that they are "equivalent" or should behave "the same,"
    often because these labels are derived from names or strings that
-   users consider "the same" in some languages.  Accordingly, Internet
+   users consider "the same." Accordingly, Internet
    users hope for such labels to behave in DNS contexts as they expect
    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
    "variants" in human scripts as codified in Unicode (or anywhere else)
@@ -227,7 +227,7 @@
 
    there are also administrative mechanisms available for manipulating
    databases underlying the generation and resolution of DNS names.
-   Registry operators have many mechanisms for working around DNS
+   Registry operators have many mechanisms for working around the DNS
    protocol in order to get behavior they want for names in DNS zones,
    and management of "aliases" is no exception.  However, it is not
    clear how much of the user and operator requirements for "aliases"
@@ -262,7 +262,7 @@
    that might be undertaken.
 
    We also review existing constructs (CNAME, DNAME) and proposed new
-   ones ("BNAME," "zone clones") against the proposed requirements.
+   ones ("BNAME," "CLONE," "zone clones") against the proposed requirements.
 
 1.2.  What this document does not do
 
@@ -354,7 +354,7 @@
    A further question arises with respect to how applications should
    interact with alias-specific DNS behavior.  A basic requirement would
    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
+   the DNS protocol in support of the desired "alias" behavior should not
    interfere with applications that expect to do such interpretation on
    their own.  This concern is based in the expectation that DNS is
    simple and predictable, operating strictly as infrastructure under
@@ -366,8 +366,8 @@
    how "variants" might behave as DNS names.  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
+   preference of users is important. Without such management of grouped
+   domain names security risks may be increased and the quality of the 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
@@ -406,7 +406,7 @@
    specify such "identical resolution" behavior:CNAME[RFC1034] which
    maps or redirects itself, and DNAME[RFC2672] which maps or redirects
    its descendants.  In the case of bundles or groups of names, however,
-   some operators have asserted they need identical DNS resolution at
+   some operators have asserted that they need identical DNS resolution at
    all levels' domain names, including the domain name itself and its
    descendants.  As alluded to above, registries are left with ad hoc
    provisioning and database management mechanisms for managing variant
@@ -426,7 +426,7 @@
    CJK language/script communities, is roughly this: One conceptual
    character can be identified with several different Code Points in
    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
    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
@@ -458,34 +458,31 @@
    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
    case mapping most DNS users take for granted, in which the uppercase
-   "A" is the variant of lowercase "a".  For example, the string ".COM"
+   "A" is the variant of lowercase "a".  By this definition, the string ".COM"
    can be considered a variant of ".com", and the corresponding DNS
    labels are treated as identical.  However, for the historical reasons
    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.
+   situations where it might be useful for IDNs. 
 
    At this writing, four Han script IDN TLDs are in the root, including
    two pairs comprising a Traditional Chinese name and its Simplified
    counterpart.  These operators will, in an ideal world, be able to
    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
 
-   In Greek, almost every word has the "tonos" accent sign, but where it
+   In written Greek almost every word has the "tonos" accent sign, but where it
    is placed (on which character) can vary.  Further, some words end in
-   a final sigma, which is represented differently to sigma appearing
+   a terminal sigma which is represented differently to sigma appearing
    elsewhere in the word.  If a registry wishes to be able to enforce
    the association among all of the domain names that correspond to a
    "word" in Greek, with all its possible Unicode strings, some
    mechanism must be used to enumerate the "variant" names and tie them
    together.  This makes sense from the human factors perspective, as
-   depending on how the user types something, results may include a
+   depending on how the user types something results may include a
    different domain to what was expected, although the user may have the
    firm belief that "the same word" was input in multiple cases.
 
@@ -513,10 +510,10 @@
 
    It's reasonable to pose the question at this point, without
    necessarily being able to answer it yet, of what is the ideal or
-   intended impact of solving the issue identified so far for registries
-   on applications and end users.  Ultimately, simplifying the
+   intended impact of solving the issues identified so far for registries,
+   applications, and end users.  Ultimately, simplifying the
    provisioning side may result in the same semantics as we have today
-   for zones maintained in parallel but for less work.  However, we
+   for zones maintained in parallel but with less work.  However, we
    later assert a proposed requirement that synthesizing the same record
    as a query would have obtained from an enumerated parallel tree isn't
    enough-- that the property of association or "sameness" we're
@@ -547,7 +544,7 @@
    2.  The desire for names on the Internet to act like words is often
        service-independent; users want to be able to use identical
        strings in the course of invoking multiple services that seem to
-       be related, such as going to a webpage and then sending email to
+       be related, such as going to a web page and then sending email to
        an address in "the same" domain (probably an FQDN).  It's been
        noted that people are very comfortable with a certain amount of
        fuzziness about "alternative spellings" and assorted other
@@ -596,7 +593,7 @@
 
    The most obvious way to provision multiple names as "the same" is to
    delegate each separately, and then maintain the contents of the
-   delegated zones together, from the same backend database or by some
+   delegated zones together, from the same back end database or by some
    similar mechanism.  This has the advantage of requiring no new
    technology; it can be done, and is done today, entirely with
    provisioning logic and registry policy.
@@ -604,9 +601,9 @@
    However, it doubles the work and the number of records required.  If
    provisioning isn't done carefully, errors can arise, leaving
    inconsistencies.  And provisioning multiple trees does nothing to
-   link the resulting names directly; there is no property of
+   link the resulting names directly. There is no property of
    "association" or isomorphism created in the DNS that corresponds to
-   user or application expectations for "sameness".  There is no way to
+   user or application expectations for "sameness."  There is no way to
    tell, from resolving a name in one tree, that it's part of a set or
    bundle of related names.
 
@@ -634,8 +631,8 @@
    the case of proposed mechanisms, we attempt to describe them below.
 
    Existing mechanisms besides the simple, straightforward provisioning
-   of zones that are identical except for the ownernames of
-   corresponding records include wildcards, CNAME, and DNAME.  See
+   of zones that are identical except for the owner names of
+   corresponding records include wild cards, CNAME, and DNAME.  See
    below, but here we note that they require special processing by the
    authority server in order to synthesize responses that are supposed
    to be the equivalent of simply providing the parallel zones by one-
@@ -717,7 +714,7 @@
    infrastructure protocol, for the long tail of deployment of
    significant protocol features.  Again, a feature can be designed to
    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.

@@ -759,6 +756,9 @@
        operations, any change undertaken to lower the cost to providers
        may be useful, but should not simply shift costs to DNS users,
        whether applications or end users.
+   6.  A proposed mechanism MUST provide a way to signal whether or
+       not a label is a "variant," a "preferred" label, or not; and
+       if it is what the preferred label and all variant labels are.

 5.  Possible Solutions
@@ -775,7 +775,7 @@
 
    In addition, there are new proposals for DNS protocol to support
    "aliases" in the DNS as part of the desired behavior of "variant"
-   names: Names direction[BNAME], and "Zone clone".
+   names: Names direction[BNAME], CLONE, and "Zone clone".

@@ -790,7 +790,7 @@
    mechanism existing or proposed to support "aliases" in the DNS
    requires that one name be designated as the "canonical" name
    ("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
    is via careful registry provisioning within and across domains.  In
    addition, the different "alias" mechanisms differ in subtle ways that
@@ -867,6 +867,31 @@
    compatibility to avoid harm to implementations that expect, and use,
    the old behavior.
 
+5.1.4.  CLONE
+
+The CLONE method proposes 2 new RRtypes, CLONE and CLONES. The first is
+designed to designate a given label as a CLONE of the preferred label.
+On the authoritative server side a preferred label can have CLONEs both
+within the zone, or as zone cuts. When an authoritative server receives
+a query for a label that is a CLONE it will respond "as if" the query
+had been for the preferred label. If the resolving name server sends the
+EDNS option that indicates it is CLONE-Aware the authoritative server
+will also send the CLONE RR which will allow the resolver to send future
+queries for the preferred label. This method allows the resolving name
+sever to validate DNSSEC signatures for the CLONE "as if" it had been
+the preferred label that had been queried for. With the addition of
+dynamic DNSSEC signing in the authoritative name server all benefits
+of the CLONE method can be derived simply from updating authoritative
+servers. The CLONES RRtype can be used to determine whether a given
+name is a CLONE, a preferred label, and what the other CLONE labels are.
+
+The advantages of the CLONE method include the flexibility to use it
+both as a zone cut, and within a zone. It also provides the option of
+full DNSSEC support without requiring updates to the massive installed
+base of resolving name servers. By not requiring copies of the preferred
+label/zone it reduces resources necessary for implementation on the
+authoritative server.
+
 5.2.  Zone Clone
 
    The proposal of "zone clone" or "dns shadow", is an alternative