Hi Kevin, Great timing on this, I've just spent a bit of time considering it.
The difficulty is that NOTIFY’s existing semantics and operational expectations don’t really line up with what EXPIRE needs to do. Operationally, NOTIFY is almost always constrained to authoritative -> secondary, with specific firewall, ACL, and traffic handling provisions. Reusing it as an authoritative -> resolver control signal would require resolvers to accept inbound NOTIFY in ways their operators generally do not allow today. Semantically, NOTIFY authenticates the server, not the operation. It provides zone-level messaging (zone has changed), but not RRset specific authority, deletion semantics, or replay protection. EXPIRE needs authentication tied to the particular RRset being expired, not just to the existence of an authorized server. Overloading NOTIFY with per-RRset cache-flush semantics would essentially redefine it for all deployed resolvers in ways operators might not embrace. Those were the main reasons it seemed cleaner to define EXPIRE explicitly. Best, Duane > On Nov 21, 2025, at 11:14, Kevin P. Fleming <[email protected]> wrote: > > On Fri, Nov 21, 2025, at 11:29, Duane Powers wrote: >> EXPIRE is not intended as a discovery protocol, and it does not attempt >> to tell an authoritative operator which resolvers may hold a cached >> entry. The model is the same as TSIG-signed UPDATE, NOTIFY, or existing >> vendor-specific purge mechanisms: the operator already knows the >> resolvers they administer and has an established trust relationship with >> them. > > Since you mentioned NOTIFY that triggered my brain... could the 'generalized > NOTIFY' mechanism be leveraged for this, so that there would not be a need > for a new opcode? > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
