If we are going to send NOTIFY messages just send signed UPDATE messages.  I 
described how to do this securely about a decade ago now.

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

NOTIFY messages are just going to have to be relayed to the registrar in 
exactly the same way as UPDATE messages needed to be relayed to the registrar 
in the above draft.  The registrar still performs the EPP update. 


> On 29 Nov 2022, at 23:37, Peter Thomassen <pe...@desec.io> wrote:
> 
> Dear DNSOP,
> 
> Changes in CDS/CDNSKEY, CSYNC, and other records related to delegation 
> maintenance are usually detected through scheduled scans run by the consuming 
> party (e.g. top-level domain registry), incurring an uncomfortable trade-off 
> between scanning cost and update latency.
> 
> A similar problem exists when scheduling zone transfers, where it has been 
> solved using the well-known DNS NOTIFY mechanism ([RFC1996]) which enables 
> primaries to nudge secondaries when there's a zone update, allowing the 
> latter to initiate an out-of-order zone transfer and reset the serial check 
> timer.
> 
> At the IETF a few weeks back, Johan and I felt a sudden enlightenment when it 
> occurred to us that the same approach could be used to reduce scanning cost 
> for CDS/CSYNC scans and the like, while maintaining low update latency. In 
> fact, the NOTIFY spec already does allow sending NOTIFY message of other 
> types. So, we not use that for hinting beyond SOA?
> 
> We wrote up a draft, and if you'd like to read how one could make this work, 
> feel free to take a look:
> --> 
> https://datatracker.ietf.org/doc/draft-thomassen-dnsop-generalized-dns-notify/
> 
> There is also an application in multi-signer setups, where Viktor had brought 
> up the problem of ZSK rollovers by one signer, and how the others would know 
> about that. That's not as well fleshed-out yet, but we figured it shouldn't 
> keep us from circulating the initial idea.
> 
> Best,
> Peter
> 
> 
> -------- Forwarded Message --------
> Subject: New Version Notification for 
> draft-thomassen-dnsop-generalized-dns-notify-00.txt
> Date: Mon, 28 Nov 2022 13:10:10 -0800
> From: internet-dra...@ietf.org
> To: Johan Stenstam <johan.stens...@internetstiftelsen.se>, Peter Thomassen 
> <pe...@desec.io>
> 
> 
> A new version of I-D, draft-thomassen-dnsop-generalized-dns-notify-00.txt
> has been successfully submitted by Peter Thomassen and posted to the
> IETF repository.
> 
> Name:         draft-thomassen-dnsop-generalized-dns-notify
> Revision:     00
> Title:                Generalized DNS Notifications
> Document date:        2022-11-28
> Group:                Individual Submission
> Pages:                13
> URL:            
> https://www.ietf.org/archive/id/draft-thomassen-dnsop-generalized-dns-notify-00.txt
> Status:         
> https://datatracker.ietf.org/doc/draft-thomassen-dnsop-generalized-dns-notify/
> Html:           
> https://www.ietf.org/archive/id/draft-thomassen-dnsop-generalized-dns-notify-00.html
> Htmlized:       
> https://datatracker.ietf.org/doc/html/draft-thomassen-dnsop-generalized-dns-notify
> 
> 
> Abstract:
>   Changes in CDS/CDNSKEY, CSYNC, and other records related to
>   delegation maintenance are usually detected through scheduled scans
>   run by the consuming party (e.g. top-level domain registry),
>   incurring an uncomfortable trade-off between scanning cost and update
>   latency.
> 
>   A similar problem exists when scheduling zone transfers, and has been
>   solved using the well-known DNS NOTIFY mechanism ([RFC1996]).  This
>   mechanism enables a primary nameserver to proactively inform
>   secondaries about zone changes, allowing the secondary to initiate an
>   ad-hoc transfer independently of when the next SOA check would be
>   due.
> 
>   This document extends the use of DNS NOTIFY beyond conventional zone
>   transfer hints, bringing the benefits of ad-hoc notifications to DNS
>   delegation maintenance in general.  Use cases include DNSSEC key
>   rollovers hints via NOTIFY(CDS) and NOTIFY(DNSKEY), and quicker
>   changes to a delegation's NS record set via NOTIFY(CSYNC).
> 
>   TO BE REMOVED: This document is being collaborated on in Github at:
>   https://github.com/peterthomassen/draft-thomassen-dnsop-generalized-
>   dns-notify (https://github.com/peterthomassen/draft-thomassen-dnsop-
>   generalized-dns-notify).  The most recent working version of the
>   document, open issues, etc. should all be available there.  The
>   authors (gratefully) accept pull requests.
> 
>                                                                               
>    
> 
> The IETF Secretariat
> 
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to