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
- [DNSOP] Clarifying referrals (#35) Andrew Sullivan
- Re: [DNSOP] Clarifying referrals (#35) Stephane Bortzmeyer
- Re: [DNSOP] Clarifying referrals (#35) Paul Vixie
- Re: [DNSOP] Clarifying referrals (#35) Andrew Sullivan
- Re: [DNSOP] Clarifying referrals (#35) Paul Vixie
- Re: [DNSOP] Clarifying referrals (#35) Andrew Sullivan
- Re: [DNSOP] Clarifying referrals (#35) Paul Vixie
- Re: [DNSOP] Clarifying referrals (#35) Andrew Sullivan
- Re: [DNSOP] Clarifying referrals (#35) John Kristoff
- Re: [DNSOP] [Ext] Re: Clarifying referrals (#35) Edward Lewis
- [DNSOP] CDS polling, was Re: [Ext] Re: Clarifying… Tony Finch
- Re: [DNSOP] Clarifying referrals (#35) Paul Vixie
- Re: [DNSOP] Clarifying referrals (#35) Paul Vixie
- Re: [DNSOP] CDS polling, was Re: [Ext] Re: Clarif… Evan Hunt
- Re: [DNSOP] Clarifying referrals (#35) Matthew Pounsett
- Re: [DNSOP] CDS polling, was Re: [Ext] Re: Clarif… Edward Lewis
- Re: [DNSOP] CDS polling, was Re: [Ext] Re: Clarif… Paul Vixie
- Re: [DNSOP] Clarifying referrals (#35) Paul Vixie
- Re: [DNSOP] Clarifying referrals (#35) Matthew Pounsett
- Re: [DNSOP] Clarifying referrals (#35) Paul Vixie
- Re: [DNSOP] Clarifying referrals (#35) Matthew Pounsett
- Re: [DNSOP] Clarifying referrals (#35) Paul Vixie
- Re: [DNSOP] Clarifying referrals (#35) Robert Edmonds
- Re: [DNSOP] Clarifying referrals (#35) Evan Hunt
- Re: [DNSOP] CDS polling, was Re: [Ext] Re: Clarif… Mark Andrews
- Re: [DNSOP] CDS polling, was Re: [Ext] Re: Clarif… Evan Hunt
- [DNSOP] another draft (was Re: Clarifying referra… Andrew Sullivan
- Re: [DNSOP] Clarifying referrals (#35) Paul Vixie
- Re: [DNSOP] Clarifying referrals (#35) Andrew Sullivan
- Re: [DNSOP] Clarifying referrals (#35) Paul Vixie
- Re: [DNSOP] Clarifying referrals (#35) Evan Hunt
- Re: [DNSOP] Clarifying referrals (#35) Paul Vixie
- Re: [DNSOP] CDS polling, was Re: [Ext] Re: Clarif… Mark Elkins
- Re: [DNSOP] Clarifying referrals (#35) Andrew Sullivan
- Re: [DNSOP] CDS polling, was Re: [Ext] Re: Clarif… Tony Finch
- Re: [DNSOP] Clarifying referrals (#35) Evan Hunt
- Re: [DNSOP] CDS polling, was Re: [Ext] Re: Clarif… Jacques Latour
- Re: [DNSOP] Clarifying referrals (#35) Dave Lawrence
- Re: [DNSOP] Clarifying referrals (#35) Paul Vixie
- Re: [DNSOP] CDS polling, was Re: [Ext] Re: Clarif… Paul Wouters
- Re: [DNSOP] Clarifying referrals (#35) Tony Finch
- Re: [DNSOP] CDS polling, was Re: [Ext] Re: Clarif… Tony Finch
- Re: [DNSOP] Clarifying referrals (#35) Stephane Bortzmeyer
- Re: [DNSOP] Clarifying referrals (#35) Andrew Sullivan
- Re: [DNSOP] Clarifying referrals (#35) Mark Andrews
- Re: [DNSOP] Clarifying referrals (#35) Paul Vixie
- Re: [DNSOP] Clarifying referrals (#35) Andrew Sullivan
- Re: [DNSOP] Clarifying referrals (#35) Andrew Sullivan
- Re: [DNSOP] Clarifying referrals (#35) Mark Andrews
- Re: [DNSOP] Clarifying referrals (#35) Andrew Sullivan
- Re: [DNSOP] Clarifying referrals (#35) Mark Andrews
- Re: [DNSOP] Clarifying referrals (#35) Andrew Sullivan
- Re: [DNSOP] Clarifying referrals (#35) Andrew Sullivan
- Re: [DNSOP] Clarifying referrals (#35) Mark Andrews
- Re: [DNSOP] Clarifying referrals (#35) Andrew Sullivan
- Re: [DNSOP] Clarifying referrals (#35) Mark Andrews
- Re: [DNSOP] Clarifying referrals (#35) Mark Andrews
- Re: [DNSOP] Clarifying referrals (#35) Evan Hunt
- Re: [DNSOP] Clarifying referrals (#35) Paul Vixie
- Re: [DNSOP] Clarifying referrals (#35) Tony Finch
- Re: [DNSOP] Clarifying referrals (#35) Andrew Sullivan
- Re: [DNSOP] Clarifying referrals (#35) Andrew Sullivan
- Re: [DNSOP] Clarifying referrals (#35) Andrew Sullivan
- Re: [DNSOP] Clarifying referrals (#35) P Vix
- Re: [DNSOP] Clarifying referrals (#35) Mark Andrews
- Re: [DNSOP] Clarifying referrals (#35) Andrew Sullivan
- Re: [DNSOP] Clarifying referrals (#35) Andrew Sullivan
- Re: [DNSOP] Clarifying referrals (#35) Tony Finch
- Re: [DNSOP] Clarifying referrals (#35) P Vix
- Re: [DNSOP] Clarifying referrals (#35) Andrew Sullivan
- Re: [DNSOP] Clarifying referrals (#35) Tony Finch
- Re: [DNSOP] Clarifying referrals (#35) Paul Hoffman
- Re: [DNSOP] Clarifying referrals (#35) Evan Hunt
- Re: [DNSOP] Clarifying referrals (#35) Evan Hunt
- Re: [DNSOP] Clarifying referrals (#35) Dick Franks
- Re: [DNSOP] Clarifying referrals (#35) Andrew Sullivan
- Re: [DNSOP] Clarifying referrals (#35) Dick Franks
- Re: [DNSOP] Clarifying referrals (#35) Tony Finch
- Re: [DNSOP] Clarifying referrals (#35) Dick Franks
- Re: [DNSOP] Clarifying referrals (#35) Tony Finch
- Re: [DNSOP] Clarifying referrals (#35) Andrew Sullivan
- Re: [DNSOP] Clarifying referrals (#35) Paul Vixie
- Re: [DNSOP] Clarifying referrals (#35) Florian Weimer
- Re: [DNSOP] Clarifying referrals (#35) Tony Finch
- Re: [DNSOP] Clarifying referrals (#35) Andrew Sullivan
- Re: [DNSOP] Clarifying referrals (#35) Bob Harold
- Re: [DNSOP] Clarifying referrals (#35) Evan Hunt
- Re: [DNSOP] Clarifying referrals (#35) Wessels, Duane
- Re: [DNSOP] Clarifying referrals (#35) Johannes Naab