Re: [DNSOP] Fwd: New Version Notificationfor draft-mekking-dnsop-auto-cpsync-00

Wolfgang Nagele <wnagele@ripe.net> Tue, 29 June 2010 14:43 UTC

Return-Path: <wnagele@ripe.net>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B68E3A6A34 for <dnsop@core3.amsl.com>; Tue, 29 Jun 2010 07:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.11
X-Spam-Level:
X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11]
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 5hI2MW4UmLrg for <dnsop@core3.amsl.com>; Tue, 29 Jun 2010 07:43:31 -0700 (PDT)
Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id B1FC53A6850 for <dnsop@ietf.org>; Tue, 29 Jun 2010 07:43:30 -0700 (PDT)
Received: from dodo.ripe.net ([193.0.1.102]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <wnagele@ripe.net>) id 1OTc2B-0006JH-4E; Tue, 29 Jun 2010 16:43:40 +0200
Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=guest-66.ripe.net) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from <wnagele@ripe.net>) id 1OTc2A-0000f9-W7; Tue, 29 Jun 2010 16:43:35 +0200
Message-ID: <4C2A0696.7080204@ripe.net>
Date: Tue, 29 Jun 2010 16:43:34 +0200
From: Wolfgang Nagele <wnagele@ripe.net>
Organization: RIPE NCC
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5
MIME-Version: 1.0
To: Stephan Lagerholm <stephan.lagerholm@secure64.com>
References: <4C29F2FA.1000907@nlnetlabs.nl> <4C29FE8F.6030002@nlnetlabs.nl> <DD056A31A84CFC4AB501BD56D1E14BBB826B70@exchange.secure64.com>
In-Reply-To: <DD056A31A84CFC4AB501BD56D1E14BBB826B70@exchange.secure64.com>
X-Enigmail-Version: 1.0.1
OpenPGP: id=7072CBC7; url=x-hkp://pgpkeys.pca.dfn.de
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-RIPE-Signature: 13a8e87b1b31202db532b29cd449ceb640cbecf1af1b3e6f1a09540b2142f78e
X-RIPE-Spam-Level: ----
X-RIPE-Signature: 13a8e87b1b31202db532b29cd449ceb640cbecf1af1b3e6f1a09540b2142f78e
Cc: dnsop@ietf.org, Matthijs Mekking <matthijs@NLnetLabs.nl>
Subject: Re: [DNSOP] Fwd: New Version Notificationfor draft-mekking-dnsop-auto-cpsync-00
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 29 Jun 2010 14:43:32 -0000

Hi Stephan,

> I like this draft but I'm a little bit concerned about the scalability.
> How will a busy parent provision a unique secret key for each of the
> child?
Do you mean the scalability for capacity on the update server side? Although
BIND might not be able to scale this out of the box, the example has only been
given in the draft to have a hands-on way for ppl to try this draft.

In reality it should not be a major issue to receive those DNS updates and
process them (with or without signatures) - similar efforts are currently made
for each request to change NS-sets on the parent (admittedly those might happen
less frequent).

> And how will this key be transported between the parent and the
> child in a secure way?
The same way a parent is currently providing a domain owner with credentials for
their management interfaces. If a domain owner has specific requirements in
terms of security on that channel it is something where registrars can offer
whatever their customers demand.

Regards,
Wolfgang