Re: [dnsext] DS digest downgrade

Wes Hardaker <wjhns1@hardakers.net> Wed, 23 March 2011 14:05 UTC

Return-Path: <wjhns1@hardakers.net>
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 8F8683A691A for <dnsext@core3.amsl.com>; Wed, 23 Mar 2011 07:05:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 ld1cU4rv8wxj for <dnsext@core3.amsl.com>; Wed, 23 Mar 2011 07:05:37 -0700 (PDT)
Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id D003A3A6915 for <dnsext@ietf.org>; Wed, 23 Mar 2011 07:05:37 -0700 (PDT)
Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 77F122096A; Wed, 23 Mar 2011 07:06:50 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Andrew Sullivan <ajs@shinkuro.com>
References: <AB3F9CFB9B6948139A2BE01269B399D5@local> <20110321222521.83729D084D9@drugs.dv.isc.org> <51C21B4C57014630B72B50B919271C89@local> <sdr59zutf9.fsf@wjh.hardakers.net> <20110322143213.GU87529@shinkuro.com>
Date: Wed, 23 Mar 2011 07:06:50 -0700
In-Reply-To: <20110322143213.GU87529@shinkuro.com> (Andrew Sullivan's message of "Tue, 22 Mar 2011 10:32:13 -0400")
Message-ID: <sdipvavslh.fsf@wjh.hardakers.net>
User-Agent: Gnus/5.110012 (No Gnus v0.12) Emacs/23.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Cc: dnsext@ietf.org
Subject: Re: [dnsext] DS digest downgrade
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: Wed, 23 Mar 2011 14:05:38 -0000

>>>>> On Tue, 22 Mar 2011 10:32:13 -0400, Andrew Sullivan <ajs@shinkuro.com> said:

>> T+3: someone queries for the example.tld DS and gets a DS record set
>> with the SHA1 DS for the new key.  And a TTL picked by ???
>> [multiple options exist here].

AS> I don't see why multiple options exist there.  The DS record is
AS> authoritative data at the parent, and nowhere else.  Therefore, it is
AS> the job of the parent and nobody else to set the TTL.

Because some upstreams let the user pick the TTL of the DS, wise or not.

Now, you're right it is the parent's responsibility...  But some
outsource that to the child.

AS> Certainly, if I ran the circus, that's how I'd do it.

I think you'd run a fine circus Andrew.

>> If a parent only allows updating of a single DS record at a time,

AS> It does seem to me that it would be a wise idea to provide operational
AS> advice

I agree, it would.
-- 
Wes Hardaker
Cobham Analytic Solutions