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

Mark Elkins <mje@posix.co.za> Tue, 14 November 2017 09:16 UTC

Return-Path: <mje@posix.co.za>
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 01B27129400 for <dnsop@ietfa.amsl.com>; Tue, 14 Nov 2017 01:16:00 -0800 (PST)
X-Quarantine-ID: <GmHRvdK7Y3x6>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam-Report: ...that system for details.\n \n Content previ[...]
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 GmHRvdK7Y3x6 for <dnsop@ietfa.amsl.com>; Tue, 14 Nov 2017 01:15:57 -0800 (PST)
Received: from relay.vweb.co.za (relay.vweb.co.za [IPv6:2001:43f8:790:61::200]) (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 C4E8C12008A for <dnsop@ietf.org>; Tue, 14 Nov 2017 01:15:56 -0800 (PST)
Received: from [165.255.69.12] (port=39884 helo=mjelap.posix.co.za) by relay.vweb.co.za with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from <mje@posix.co.za>) id 1eEXIx-0004x7-Ep for dnsop@ietf.org; Tue, 14 Nov 2017 11:14:52 +0200
Reply-To: mje@posix.co.za
To: dnsop@ietf.org
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>
From: Mark Elkins <mje@posix.co.za>
Organization: Posix Systems
Message-ID: <d11bb419-a056-b075-8ef6-405f8ac097f5@posix.co.za>
Date: Tue, 14 Nov 2017 11:15:17 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20171113233756.GA37394@isc.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9392wh8W9tHgBqEhTkHSXZPwbXk>
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 09:16:00 -0000


On 14/11/2017 01:37, Evan Hunt wrote:
> On Tue, Nov 14, 2017 at 09:16:43AM +1100, Mark Andrews wrote:
>> 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.  
> 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.)
>
> 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.

Getting the parent to examine the child in order to examine changes in
CDS/CDNSKEY is something I'd dearly like to see done.
With foot firmly stuck in mouth and probably breaking all protocols....

Who am I:
I'm a 'local' Registrar (Non-ICANN Accredited), running DNSSEC for
clients. I speak EPP mainly to the ZACR (South African Central Registry)
- usually for the CO.ZA Domain name space. I also speak EPP to a bunch
of other people.
I either run the DNS zone for the client - so know when to send an EPP
update to the Registry (this is totally automated) or run a
"Registration Only" service where clients run their own (DNSSEC Signed)
zones. When the latter do a KSK rollover, they are currently obliged to
login to https://vweb.co.za into their account, find their Domain and
push a [Reread Zone info] button which does a DNS Lookup over TCP using
a DNSSEC aware recursive resolver to see what NS and DNSKEY records have
changed, brings them back and presents them to the user. I automatically
generate CDS records from the DNSKEY. A short time later - these are
pushed to the Parent via EPP.

More ideally, this [Reread Zone info] button should be triggered by the
client using a well documented standard (RFC?), probably a URL and
passing to the URL the Domain Name to "check". (I like to call this the
"tickle RFC").

The same could be used directly with Registry systems...
If you want to get CO.ZA to "Poll" your Nameservers, look for a DNS
record (lets call it TCKL) in the top of the zone which should return a
web like URL which you can then "GET" with... (GET seems more simple
than POST)

co.za    IN    TCKL    "https://poll.registry.net.za?Domain="
(Most ccTLD's might do the same?)

For myself, I'd tell my clients mentioned above to look for:

vweb.co.za    IN    TCKL    "https://tickle.vweb.co.za?Domain="
(Most COM type Registrars might do the same?)

I guess one could have multiple answers for redundancy.
No "security" as in passwords should be needed.
I don't see this being used to DDOS Registries, only do something
further if the domain is one of yours, only if it is already DNSSEC
signed, and only trust the answer if the DNS Connection validates
properly, any faults - wait 5 seconds and then report an error (if so
desired).

I don't quite see how a SVR record could do this as per

https://tools.ietf.org/html/draft-andrews-dnsop-update-parent-zones-04

I also don't remember seeing any DNS record types where the RHS is a full URL.

To me, for now, this would only be used for DNSSEC updates (i.e. CDS/CDNSKEY where the Child Zone is already signed)

Anyway - that's my baby step, so just a small foot in my mouth. Please be gentle.

-- 
Mark James ELKINS  -  Posix Systems - (South) Africa
mje@posix.co.za       Tel: +27.128070590  Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za