Re: [DNSOP] CDS polling, was Re: [Ext] Re: Clarifying referrals (#35)

Mark Andrews <marka@isc.org> Mon, 13 November 2017 22:17 UTC

Return-Path: <marka@isc.org>
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 7642D126C2F for <dnsop@ietfa.amsl.com>; Mon, 13 Nov 2017 14:17:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ob0mJVW5aDVs for <dnsop@ietfa.amsl.com>; Mon, 13 Nov 2017 14:17:03 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42CAC120724 for <dnsop@ietf.org>; Mon, 13 Nov 2017 14:17:03 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 7AF2A3B6A62; Mon, 13 Nov 2017 22:16:47 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 6919D16005B; Mon, 13 Nov 2017 22:16:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 56001160086; Mon, 13 Nov 2017 22:16:47 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id U5oNZby2rnKP; Mon, 13 Nov 2017 22:16:47 +0000 (UTC)
Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 5188416005B; Mon, 13 Nov 2017 22:16:46 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <436111CF-FCA8-44A2-B83D-6540DE6D64AC@icann.org>
Date: Tue, 14 Nov 2017 09:16:43 +1100
Cc: Evan Hunt <each@isc.org>, Tony Finch <dot@dotat.at>, "dnsop@ietf.org" <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <66BA5F27-B044-459B-A2B2-54221FD768C6@isc.org>
References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113032640.tbn7icsllm6jeeny@mx4.yitter.info> <C9AC653C-9A27-4DA3-A0FA-9F1BFD429962@icann.org> <alpine.DEB.2.11.1711131456200.26046@grey.csi.cam.ac.uk> <20171113183004.GA35038@isc.org> <436111CF-FCA8-44A2-B83D-6540DE6D64AC@icann.org>
To: Edward Lewis <edward.lewis@icann.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/WIY-WYrb2r7fAIBrCyGfHFWj0Nk>
Subject: Re: [DNSOP] CDS polling, was Re: [Ext] Re: Clarifying referrals (#35)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 13 Nov 2017 22:17:04 -0000

> On 14 Nov 2017, at 5:45 am, Edward Lewis <edward.lewis@icann.org> wrote:
> 
> On 11/13/17, 13:30, "DNSOP on behalf of Evan Hunt" <dnsop-bounces@ietf.org on behalf of each@isc.org> wrote:
> 
>> Mark's idea to push updates to the parent instead of relying on polling used a SRV query to identify the correct recipient of an UPDATE:
>> 
>>   ...draft-andrews-dnsop-update-parent-zones-04...
> 
> This would mean then signing all the SRV sets, so I assume to preserve the benefits of "OPTOUT", you'd want these only for the names that had DS sets.  For the others, I assume either no answer or the wildcard ... in the TLD.  (That latter thought might be unsettling to some people.)  What I mean is that there is still a scaling problem, in some dimension, to deal with because the DNS is inherently a "down-only" tree.
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

That part of the namespace doesn’t require signing as the UPDATES themselves are signed
and can be easily split off as a separate zone.  The worst that  would happen is that the
UPDATE request would be blocked if a spoofed response was accepted.  Using servers
that relay the UPDATE request (which is what slave zones do today for UPDATE) only
requires a single SRV record.

Even if the SRV records are all signed and the registry doesn’t run a UPDATE relay there
still isn’t a scaling issue.  It is possible to serve COM with every delegation being a secure
delegation even though we don’t do it today.  At worst this creates a zone of slightly smaller
size.  Add to that there would be a ramp up process as registrars come online supporting
this method.

Remember the draft was designed to handle ALL record updates to the parent zone
after being approved by the registrar in a unified manner.  NS, DS, A, DNAME, AAAA, TXT,
CNAME, etc. This isn’t restricted to DS records.  

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org