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

[Brian Dickson <[e-mail]>]

On Wed, Feb 23, 2011 at 7:47 AM, Suzanne Woolf <[e-mail]> 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).