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

Tony Finch dot at dotat.at
Wed Jun 16 11:04:39 UTC 2021

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.)


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

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

More information about the bind-users mailing list