Hi Yorgos, Great question, thank you — it's an important point.
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. The DNSSEC-authenticated form is primarily useful in situations where an operator is aware of a specific external resolver that is serving stale data (for example, a resolver used by a partner or customer). In those cases an EXPIRE message can correct the residual cache state without needing to involve the remote operator directly. In other words, EXPIRE is scoped to the set of resolvers that are already configured to accept authenticated control traffic within an existing administrative relationship. It is not meant for contacting arbitrary resolvers on the Internet, nor does it attempt to solve resolver enumeration. That’s why the draft frames EXPIRE as standardizing the existing operator-to-resolver control channels, rather than providing a mechanism for discovering or reaching third-party caches. If the document isn’t clear enough on that scoping, I can clarify it in the next revision. Thanks for engaging with the idea. Duane > On Nov 21, 2025, at 08:19, Yorgos Thessalonikefs <[email protected]> wrote: > > Hi Duane, > > I understand that this describes and automated way for authoritatives to > dictate cache eviction to caching resolvers. > But I fail to find in the document how an authoritative knows which resolvers > to contact and how. > > Unless it is only intended for standardizing the mix of vendor-specific > mechanisms that you mention on your latest email. > > Best regards, > -- Yorgos > > On 20/11/2025 17:30, Duane Powers wrote: >> Hi all, >> I have submitted a new individual draft proposing the EXPIRE opcode, >> which allows an authenticated authoritative operator to request >> immediate deletion of a specific RRset from a resolver cache. >> The draft defines two authentication profiles: >> • DNSSEC (in-band authority proof) >> • Control-channel authenticated (TSIG, mTLS, IPsec, local trust policy) >> It also specifies replay protection, resolver behavior, and safe >> operational deployment in both signed and unsigned DNS environments. >> URL: https://datatracker.ietf.org/doc/draft-powers-dnsop-expire/ >> I would appreciate comments and discussion from the working group. >> Thanks, >> Duane >> _______________________________________________ >> 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] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
