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

Jacques Latour <Jacques.Latour@cira.ca> Tue, 14 November 2017 20:02 UTC

Return-Path: <Jacques.Latour@cira.ca>
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 10655128B51 for <dnsop@ietfa.amsl.com>; Tue, 14 Nov 2017 12:02:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 p5_ZqZviSq8d for <dnsop@ietfa.amsl.com>; Tue, 14 Nov 2017 12:02:36 -0800 (PST)
Received: from mx2.cira.ca (mx2.cira.ca [192.228.22.117]) by ietfa.amsl.com (Postfix) with ESMTP id 2370F1242F7 for <dnsop@ietf.org>; Tue, 14 Nov 2017 12:02:31 -0800 (PST)
X-Virus-Scanned: by SpamTitan at corp.cira.ca
Received: from CRP-EX16-02.CORP.CIRA.CA (10.2.36.121) by CRP-EX16-02.CORP.CIRA.CA (10.2.36.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Tue, 14 Nov 2017 15:02:28 -0500
Received: from CRP-EX16-02.CORP.CIRA.CA ([fe80::15c6:1482:4083:e9f7]) by CRP-EX16-02.CORP.CIRA.CA ([fe80::15c6:1482:4083:e9f7%13]) with mapi id 15.01.0669.032; Tue, 14 Nov 2017 15:02:28 -0500
From: Jacques Latour <Jacques.Latour@cira.ca>
To: Tony Finch <dot@dotat.at>, Evan Hunt <each@isc.org>
CC: Edward Lewis <edward.lewis@icann.org>, "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [DNSOP] CDS polling, was Re: [Ext] Re: Clarifying referrals (#35)
Thread-Index: AQHTXJLOsSgnJWB7GEuhsqDmioRxpaMS9YQAgAAEXgCAADr1gIAAFrIAgADR14CAADB2AA==
Date: Tue, 14 Nov 2017 20:02:28 +0000
Message-ID: <D630AC64.61036%jacques.latour@cira.ca>
References: <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> <66BA5F27-B044-459B-A2B2-54221FD768C6@isc.org> <20171113233756.GA37394@isc.org> <alpine.DEB.2.11.1711140941060.14243@grey.csi.cam.ac.uk>
In-Reply-To: <alpine.DEB.2.11.1711140941060.14243@grey.csi.cam.ac.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.4.170508
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [10.2.36.1]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <8A99D827472D2C42B195219774B69F13@cira.ca>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/sKSNeBMJyVEHzyEhgygt9YtsuZA>
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: Tue, 14 Nov 2017 20:02:38 -0000

Parental synchronization is inevitable so we would be better to find the
best way to make it happen.  I think there are 3 plausible methods to do
the synchronization.

1. Child Notification: Child sends NOTIFY to a predefined parental
destination. The parent then polls the child zone for changes and EPP
commands issued to reflect the changes.

2. DNS Operator Notification: DNS Operator changes the child zone. DNS
Operator finds parental agent API via RDAP or TCKL to notify of changes to
be performed. The parent then polls the child zone for changes and EPP
commands issued to reflect the changes.

	- 
https://tools.ietf.org/html/draft-ietf-regext-dnsoperator-to-rrr-protocol-0
4
	- parental agent can be the registrar or the registry

3. Parent Polling*: On a batch/regular basis, the parent then polls all
child zones for changes and EPP commands issued to reflect the changes.
 *The parent can be the registrar or the registry.

	- a la cz.nic, full zone polling
(https://en.blog.nic.cz/2017/06/21/lets-make-dns-great-again/)
	- it would be nice to send an EPP poll message to the registrar when a
domain is changed by the TLD
	- some of the research we¹ve done shows that there are no ICANN policy
impact of doing #3 across the board (ccTLD and gTLD).

Personally, I like a mix of #3 and #1, on a regular basis poll the entire
zone for changes, and have a mechanism to listen to child notifications
for urgent changes.

_AND_ remember, the preferred method by far is to submit a DS/DNSKEY
record is via the RRR EPP model.  The above is when that RRR EPP model is
non functional.

Jack


On 2017-11-14, 7:08 AM, "DNSOP on behalf of Tony Finch"
<dnsop-bounces@ietf.org on behalf of dot@dotat.at> wrote:

>Evan Hunt <each@isc.org> wrote:
>>
>> In the present context, I was only suggesting this method be used for
>> NOTIFY, not UPDATE -- to signal the parent that it should poll the child
>> for CDS/CDNSKEY.  (I guess CSYNC could be included in the mix as well,
>> though, for updating NS and glue.)
>
>Yes.
>
>> I would suggest the child should be polled periodically regardless. If
>> the SRV record were spoofed, causing the child to send a NOTIFY to the
>> wrong address, synchronization should still occur, just not as quickly.
>
>The starting point for this thread was parental agents saying they don't
>like polling, but having thought about this a bit more I think I agree
>that it would be unwise not to poll. If there's a way to get polled early
>by NOTIFY then that's probably still good for both parent and child -
>parent can poll more slowly, and child can get prompt updates.
>
>I read Mark Elkins' article with interest. I would prefer to use NOTIFY
>rather than a web hook because it's much more plausible to imagine
>supporting this inside a DNS server with some kind of notify-parent
>feature.
>
>I like the idea of being able to automatically discover where to send
>parental notifies. But this can only work if the parental agent doesn't
>require TSIG. On the other hand, we can't rely on autodiscovery because
>I wouldn't bet on the registries publishing the necessary SRV records...
>
>Any opinions on whether this is worth pursuing?
>
>Tony.
>-- 
>f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/  -  I xn--zr8h
>punycode
>Viking, North Utsire: Northwesterly backing westerly 5 to 7. Moderate or
>rough, occasionally very rough later in north. Squally showers. Good.
>
>_______________________________________________
>DNSOP mailing list
>DNSOP@ietf.org
>https://www.ietf.org/mailman/listinfo/dnsop