Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-00)

Peter,
 I like the concept a lot and this is a good natural evolution,

My comments/issues
 #1 this should cover normal notify as well as there is no reason parent
should have to be updates every time an external DNS provider changes its
distribution "top"
#2 I would love the examples to use a different port than  53 as there is
no need for the notifies to go to that overloaded port
#3 As of new type vs SRV the argument against new type at apex is always
size of ANY, which I do not buy but I like new types :-)
#4 It should be clear that there is no need to run a "nameserver code" as
the target of the NOTIFY messages, similarly there is no real reason why
the issuer of the Notify is a "nameserver code" i.e. both of ends are
front/back ends of provision systems

Olafur

On Tue, Nov 29, 2022 at 7:37 AM Peter Thomassen <peter@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-drafts@ietf.org
> To: Johan Stenstam <johan.stenstam@internetstiftelsen.se>, Peter
> Thomassen <peter@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
>