Re: [DNSOP] Fwd: New Version Notification fordraft-mekking-dnsop-auto-cpsync-00

"George Barwood" <george.barwood@blueyonder.co.uk> Wed, 30 June 2010 10:37 UTC

Return-Path: <george.barwood@blueyonder.co.uk>
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 BCC413A68AD for <dnsop@core3.amsl.com>; Wed, 30 Jun 2010 03:37:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.588
X-Spam-Level: ****
X-Spam-Status: No, score=4.588 tagged_above=-999 required=5 tests=[AWL=1.393, BAYES_50=0.001, HELO_EQ_BLUEYON=1.4, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753]
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 d06nYXzHMGl2 for <dnsop@core3.amsl.com>; Wed, 30 Jun 2010 03:37:40 -0700 (PDT)
Received: from smtp-out4.blueyonder.co.uk (smtp-out4.blueyonder.co.uk [195.188.213.7]) by core3.amsl.com (Postfix) with ESMTP id 1EFA03A69A0 for <dnsop@ietf.org>; Wed, 30 Jun 2010 03:37:39 -0700 (PDT)
Received: from [172.23.170.138] (helo=anti-virus01-09) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1OTufs-0003Pb-Uw; Wed, 30 Jun 2010 11:37:49 +0100
Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out1.blueyonder.co.uk with smtp (Exim 4.52) id 1OTuf7-0003fp-Db; Wed, 30 Jun 2010 11:37:01 +0100
Message-ID: <62CC4714954D4674A04FC5F9718E1D89@local>
From: George Barwood <george.barwood@blueyonder.co.uk>
To: Matthijs Mekking <matthijs@NLnetLabs.nl>, dnsop@ietf.org
References: <4C29F2FA.1000907@nlnetlabs.nl>
Date: Wed, 30 Jun 2010 11:36:59 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931
Subject: Re: [DNSOP] Fwd: New Version Notification fordraft-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: Wed, 30 Jun 2010 10:37:42 -0000

I'd like to encourage some discussion of the relative merits of the UPDATE approach

http://www.ietf.org/id/draft-mekking-dnsop-auto-cpsync-00.txt

compared to the publication approach outlined in the recent draft at

http://www.ietf.org/id/draft-barwood-dnsop-ds-publish-00.txt

I haven't yet done a well-considered analysis, and maybe this would be better
undertaken by others, but here are some of my immediate thoughts:

I think the publication approach is somewhat simpler, at least for the child zone.
It's very simple for signing software (including off-line signers) to generate the "CDS" RRset.
Since there are many more child zones than parent zones, this seems significant.

The publication approach leverages the in-built redundancy of DNS slave servers
for transmitting information, and seems closer to the normal DNS method of operation.

I also like the ability to simply check whether the parent and child DS RRset
are properly synchronised.

I'm a bit doubtful about the complications of setting up additional secret keys for UPDATE.

Regards,
George