Re: [DNSOP] CDS and/or CDNSKEY

Doug Barton <dougb@dougbarton.us> Tue, 08 October 2013 18:48 UTC

Return-Path: <dougb@dougbarton.us>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBD521E80A6 for <dnsop@ietfa.amsl.com>; Tue, 8 Oct 2013 11:48:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdSdNmBeete3 for <dnsop@ietfa.amsl.com>; Tue, 8 Oct 2013 11:48:39 -0700 (PDT)
Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id D54F421E80B6 for <dnsop@ietf.org>; Tue, 8 Oct 2013 11:48:39 -0700 (PDT)
Received: from [IPv6:2001:470:d:5e7:3479:3991:40da:8b9] (unknown [IPv6:2001:470:d:5e7:3479:3991:40da:8b9]) by dougbarton.us (Postfix) with ESMTPSA id 8147B22B78 for <dnsop@ietf.org>; Tue, 8 Oct 2013 18:48:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1381258119; bh=49NCvzAy0WPQTrVosOXpwQgWB4r+trI0A3B8e5/F5WY=; h=Date:From:To:Subject:References:In-Reply-To; b=rw47ESVDcLCgnyDf2Je+C7nLNpa1VH9cDJi+/hO+QRj85BiOa/arJUswPOP06midD q4xuslrnin5paleajc83KIV6JuRbvoCeI2lGlbnr41CRUmIAXAdfvR/aR5h7OSonDa B4rGA3kJ+lQZhlk2bInjb/1W4CqLZFbyrBrbEmek=
Message-ID: <52545387.2010607@dougbarton.us>
Date: Tue, 08 Oct 2013 11:48:39 -0700
From: Doug Barton <dougb@dougbarton.us>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: dnsop <dnsop@ietf.org>
References: <5243DCAB.80507@nlnetlabs.nl> <311D023E-9425-416E-B3E6-96F3347F162B@kumari.net> <52451D58.5040107@nlnetlabs.nl> <FC382AE9-C360-47B3-B1B6-35276C624AAC@kumari.net> <524D9B65.30704@teamaol.com> <52543899.3090801@dougbarton.us> <alpine.LFD.2.10.1310081408570.7675@bofh.nohats.ca>
In-Reply-To: <alpine.LFD.2.10.1310081408570.7675@bofh.nohats.ca>
X-Enigmail-Version: 1.5.2
OpenPGP: id=1A1ABC84
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [DNSOP] CDS and/or CDNSKEY
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Oct 2013 18:48:44 -0000

On 10/08/2013 11:13 AM, Paul Wouters wrote:
> On Tue, 8 Oct 2013, Doug Barton wrote:
>
>> What's actually missing is a signaling mechanism from the child to the
>> parent.
>
> Google for "timers versus triggers". We had that discussion years ago.

I know, I've followed the thing from the beginning. :)

> It ended up in a stalemate and we continued on the bases that we should
> put the message in the zone because there was no agreement on how or
> whom should do the work when.

I understand that you (and a few others) are highly motivated to create 
something in this space. However I think a reasonable conclusion from 
the stalemates that have arisen from all of the previous attempts over 
the years would be, "There is no agreement on how to proceed, so we 
should not proceed."

> By putting the data in the, a zone reload
> can trigger a push, and a parent can do a check based on its own timers.

But have we any evidence that if created, this mechanism will be used? I 
personally don't subscribe to the "If we build it, they will come" 
school of engineering. We have too many counterexamples in the DNS already.

> Additionally, any other type of trigger signaling needs some new port
> that's not port 53 or some parental server that is not the production
> TLD server to answer to the trigger. TLDs weren't willing to do either.
>
> So I disagree. We do not need a new signaling mechanism.

I think what we disagree on is the overall utility of the project 
(again, with all due respect to the good intentions of those 
involved/interested).

Doug