Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th

"Stephan Lagerholm" <stephan.lagerholm@secure64.com> Thu, 10 March 2011 19:54 UTC

Return-Path: <stephan.lagerholm@secure64.com>
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 525F43A680F for <dnsext@core3.amsl.com>; Thu, 10 Mar 2011 11:54:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level:
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 qe6TNCrSJkyJ for <dnsext@core3.amsl.com>; Thu, 10 Mar 2011 11:54:14 -0800 (PST)
Received: from zimbra.secure64.com (unknown [64.92.221.189]) by core3.amsl.com (Postfix) with ESMTP id 328273A67FF for <dnsext@ietf.org>; Thu, 10 Mar 2011 11:54:14 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id 47E1FB8386; Thu, 10 Mar 2011 12:49:13 -0700 (MST)
X-Virus-Scanned: amavisd-new at secure64.com
Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alYJOSBDvngE; Thu, 10 Mar 2011 12:49:10 -0700 (MST)
Received: from exchange.secure64.com (exchange.secure64.com [192.168.254.250]) by zimbra.secure64.com (Postfix) with ESMTPSA id BCE72B8377; Thu, 10 Mar 2011 12:49:10 -0700 (MST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1299786550; bh=npUYOMXB69xxvunowTn1Pcn7uVo+3BoKYlI/LM6o0Jw=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:References:From:To; b=ngBnVhLlNHBOq/xEK569M SNSYBDHc3ReTqAGQQRJL5M/MMmI4rTGSMh1c9SIPmMoHNU5FDBp2M10qF4Ifq8bgdEo COzjbyqvMCatFhIRbolfb3aD9aPsSlZFAQ1p9aU4q6IjuIXX3Qzkc2MRMElzFICzXg1 sMIhaNVSPUjXS2HQ=
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 10 Mar 2011 12:48:30 -0700
Message-ID: <DD056A31A84CFC4AB501BD56D1E14BBB9CC7FC@exchange.secure64.com>
In-Reply-To: <3D41A425A17444EA8EEE8C78DD18D3E9@local>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [dnsext] CDS RRTYPE review - Comments period end Mar 29th
Thread-Index: Acve8UHx3Xib/gBNRxqv7Fl+UvAeLwAahOqA
References: <C99C3502.72B1%roy@nominet.org.uk> <alpine.LSU.2.00.1103082030190.5244@hermes-1.csi.cam.ac.uk><20110309133017.GA19809@odin.mars.sol><4D778C86.4020105@ogud.com> <DD056A31A84CFC4AB501BD56D1E14BBB9CC7CB@exchange.secure64.com> <3D41A425A17444EA8EEE8C78DD18D3E9@local>
From: "Stephan Lagerholm" <stephan.lagerholm@secure64.com>
To: "George Barwood" <george.barwood@blueyonder.co.uk>, "Olafur Gudmundsson" <ogud@ogud.com>, <dnsext@ietf.org>, "Mark Andrews" <marka@isc.org>
Subject: Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th
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>
X-List-Received-Date: Thu, 10 Mar 2011 19:54:15 -0000

George B and Mark A,

>In either case the software that signs zones has to be updated.

If adding a new flag to DNSKEY and if the software already supports the
DNSKEY RR with arbitrary flags, then no update is needed. For example, I
could use an old version of ISC dig and still make sense out of the
DNSKEY record even if a new flag was added. But I had to upgrade ISC dig
if I wanted to figure out details about the CDS record.

>If the output is in text format, the generic text format of RFC3597
section 5
>may be used if the serving software for the master server has not been
updated.

The RDATA field would still just be a "blob". How would I for example be
able to verify the Key Tag, Algorithm or Digest Type field unless the
software you are using is programmed to understand that the format the
same as for the DS record?

>The software for secondary servers does not need to be updated in any
case,
>assuming it implements RFC3597 ( that is it can handle unknown types ),
>which is of course the case for all mainstream implementations.

Agreed, I'm taking about software that interacts with humans and try to
display something meaningful for them (provisioning system, IPAM,
debugging tools, etc)

(For the record, I'm positive to this draft other than using a new RR
type. I would rather like to see an "embryonic" flag to the DNSKEY
similar to what the revoked flag is doing for old keys is RFC5011)

/S