hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?

[Tony Finch]

PGNet Dev <pgnet.dev at gmail.com> wrote:
>
> With a NOTIFY, something like _your_ old listener
>
>  nsnotifyd: handle DNS NOTIFY messages by running a command
>   https://dotat.at/prog/nsnotifyd/
>
> Don't know yet how dusty that is, or relevant to current bind 9.16+, etc. --
> -- but the general 'respond immediately to a NOTIFY' sounds quite useful.

Maaaaaaybe. Bare NOTIFY can say which zone's keys have changed, but not
what the state transition is, so it isn't what I would consider to be a
complete solution.

However, NOTIFY as specified is a slightly odd protocol - I say "as
specified" because no-one implements the odd parts, for good reasons. It
allows the initiator to include records in the answer section as a "hint"
about what has changed. There's no security, and no provision for
transmitting more than one rrtype at a time, or for transmitting the new
serial number, so it's fairly useless :-) It also says that future
revisions might specify what it means to have a non-zero number of records
in the authority and/or additional section.

So I think it might be worth using these odd parts for a more complete
NOTIFY-for-keys, something like

opcode = NOTIFY
; question section
qtype = DNSKEY
qname = <zone>
; additional section
name = <zone>
type = TXT
rdata = <state transition>

And nsnotifyd would need a little hacking to grab the state transition
code out of the packet. (nsnotifyd is adequate as it is - it works, its
users have not reported bugs - but it is based on very old C resolver APIs
for parsing DNS packets, so it should only be allowed to talk to friends.)

https://datatracker.ietf.org/doc/html/rfc1996

(I remember NOTIFY's RFC number because it is the RFC whose number matches
its year of publication.)

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  https://dotat.at/
an equitable and peaceful international order