Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt
Brian Dickson <brian.peter.dickson@gmail.com> Sun, 13 March 2011 04:04 UTC
Return-Path: <dnsext-bounces@ietf.org>
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E7CF3A6AC4; Sat, 12 Mar 2011 20:04:52 -0800 (PST)
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5BB93A67FC for <dnsext@core3.amsl.com>; Sat, 12 Mar 2011 20:04:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.562
X-Spam-Level:
X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RS-E1ElKiI9c for <dnsext@core3.amsl.com>; Sat, 12 Mar 2011 20:04:49 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 298EB3A6AC4 for <dnsext@ietf.org>; Sat, 12 Mar 2011 20:04:49 -0800 (PST)
Received: by fxm15 with SMTP id 15so2272285fxm.31 for <dnsext@ietf.org>; Sat, 12 Mar 2011 20:06:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gm/zxE9jpMj12K+SVj8zfgRJSDy+ARU8GY8/Fm6+cwE=; b=m/7bk0qQtEZUCKwxdS3a5TJxdJ2dKMmeWDdfsS4CO3CzFTM+4vJMEWdonlUoarh7v4 1+SVYrFOuAEcExZlLGOQghts4tYHatVQeZ9HdBWSsHz3gWma8zwDk+tRIz2/fCLxHI0b r4SSZHKljQ5eRHM+3CE6XjcVfJKrEzBcuqhg0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SJNvO/iV6k3PsqLY6fHU100KKB1HVjjwvIv36+KjV16VzQLwei8OU7Xye1wmTajRsi V6agy1FLTn1ezV6CsZmOO/vgMjh2Km86Dbw/ppG77QMRCpCrkX51WtLpy6EPFumHIMGQ 6XMKKLWif23WbTSOOx0LY3YBNluQjikTTxLJc=
MIME-Version: 1.0
Received: by 10.223.2.2 with SMTP id 2mr2205261fah.47.1299989170137; Sat, 12 Mar 2011 20:06:10 -0800 (PST)
Received: by 10.223.38.24 with HTTP; Sat, 12 Mar 2011 20:06:10 -0800 (PST)
In-Reply-To: <20110223114720.GA10740@bikeshed.isc.org>
References: <20110223001502.31614.56353.idtracker@localhost> <20110223114720.GA10740@bikeshed.isc.org>
Date: Sun, 13 Mar 2011 00:06:10 -0400
Message-ID: <AANLkTinO9mnFoJtPzKphCLojC1LeK9FyCGOsM5WiGcx=@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: Suzanne Woolf <woolf@isc.org>
Cc: dnsext@ietf.org
Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org
On Wed, Feb 23, 2011 at 7:47 AM, Suzanne Woolf <woolf@isc.org> 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). _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext
- [dnsext] I-D Action:draft-ietf-dnsext-aliasing-re… Internet-Drafts
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Suzanne Woolf
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Alex Bligh
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Ted Hardie
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Doug Barton
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Stephane Bortzmeyer
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Doug Barton
- Re: [dnsext] I-DAction:draft-ietf-dnsext-aliasing… George Barwood
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… John Levine
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Patrik Fältström
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Stephane Bortzmeyer
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Alex Bligh
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Paul Hoffman
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Dan Schlitt
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Paul Vixie
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Alex Bligh
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Alex Bligh
- [dnsext] How to bring discussion to a close (was:… Andrew Sullivan
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Niall O'Reilly
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Alex Bligh
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Stephane Bortzmeyer
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Niall O'Reilly
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Niall O'Reilly
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Alex Bligh
- Re: [dnsext] errata on RFC1034 for recursive alia… John Levine
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Niall O'Reilly
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Phillip Hallam-Baker
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Tony Finch
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Mark Andrews
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Tony Finch
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Tony Finch
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Mark Andrews
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Tony Finch
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Mark Andrews
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Phillip Hallam-Baker
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Tony Finch
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Alex Bligh
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Mark Andrews
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Mark Andrews
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Masataka Ohta
- [dnsext] errata on RFC1034 for recursive aliasing… Masataka Ohta
- Re: [dnsext] errata on RFC1034 for recursive alia… Mark Andrews
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Stephane Bortzmeyer
- Re: [dnsext] errata on RFC1034 for recursive alia… Andrew Sullivan
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Niall O'Reilly
- Re: [dnsext] errata on RFC1034 for recursive alia… Masataka Ohta
- Re: [dnsext] errata on RFC1034 for recursive alia… Andrew Sullivan
- Re: [dnsext] errata on RFC1034 for recursive alia… Paul Vixie
- Re: [dnsext] errata on RFC1034 for recursive alia… Masataka Ohta
- Re: [dnsext] errata on RFC1034 for recursive alia… Brian Dickson
- Re: [dnsext] errata on RFC1034 for recursive alia… Masataka Ohta
- [dnsext] pricing for equivalent localized domain … Masataka Ohta
- Re: [dnsext] pricing for equivalent localized dom… John Levine
- Re: [dnsext] errata on RFC1034 for recursive alia… Brian Dickson
- Re: [dnsext] pricing for equivalent localized dom… Masataka Ohta
- Re: [dnsext] errata on RFC1034 for recursive alia… Masataka Ohta
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Brian Dickson
- Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasin… Doug Barton