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

Paul Wouters <paul@xelerance.com> Wed, 09 March 2011 19:18 UTC

Return-Path: <paul@xelerance.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 E3C593A6A39 for <dnsext@core3.amsl.com>; Wed, 9 Mar 2011 11:18:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_27=0.6]
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 bUS35RkNme2g for <dnsext@core3.amsl.com>; Wed, 9 Mar 2011 11:18:49 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 051D33A680F for <dnsext@ietf.org>; Wed, 9 Mar 2011 11:18:49 -0800 (PST)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 6FB8BC54E; Wed, 9 Mar 2011 14:20:04 -0500 (EST)
Date: Wed, 9 Mar 2011 14:20:03 -0500 (EST)
From: Paul Wouters <paul@xelerance.com>
To: Miek Gieben <miek@miek.nl>
In-Reply-To: <20110309090536.GA9578@miek.nl>
Message-ID: <alpine.LFD.1.10.1103091412590.13711@newtla.xelerance.com>
References: <C99C3502.72B1%roy@nominet.org.uk> <alpine.LSU.2.00.1103082030190.5244@hermes-1.csi.cam.ac.uk> <72A22513B1644CFE9023189F93BFDD32@local> <20110309080006.GA23957@miek.nl> <758260B7B5B34599BA80D9BA5A3840C0@local> <20110309090536.GA9578@miek.nl>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: dnsext@ietf.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: Wed, 09 Mar 2011 19:18:50 -0000

On Wed, 9 Mar 2011, Miek Gieben wrote:

>> It gives the child zone proper control of the parent DS RRset.
>
> ...if the parent cooperates...

yeah, this is "triggers vs timers" all over again. I did not think there was any
broad concensus on that?

If the parent needs to do work, it might as well use the SEP flag in combination
with the revoke bit.

> Is this proposal aimed at TLDs or at smaller zones?

I think TLDs because "smaller zones" tend to have other administrative cuts,
not neccessarilly on the zone cut.

> Because for .nl we
> are just going to use EPP and let the registrar send in a DNSKEY which
> we will convert to a DS (so you can not even choose your own hash
> algo).

That is less of a concern then the dnsop <-> Registrar communication, which I
have the unfortunate experience of dealing with in non-standard ways precisely
for the DS record updating.

I don't think this issue is technical. SEP and Revoke is a fine solution,  but
an administrative one (parent does not want to kill child without a verified
authentication of child to keep the lawyers happy.

I don't see any method for automating the NS or Glue updates between child and
parent. If we'regoing to introduce new RRtypes for this communication, I'd
suggest tackling them all. And trust me, I'd love not to have to deal with
Registrar APIs in our products :P

Paul