Hi Vladimir, Thank you for taking the time to raise this concern. I agree that EXPIRE would make a poor substitute for proper operational discipline; that’s not its intent.
The reality is that even with good discipline, DNS caches persist for the duration of their TTLs. In practice this often means: “you’ll have to wait for propagation,” because flushing cache on many distributed resolvers simply isn’t a viable option. When an operator corrects a configuration issue, the underlying problem is fixed immediately, but the cached state may remain incorrect for hours or even days depending on TTL. EXPIRE is intended to address that residual cache state, not the configuration mistake itself. It’s aimed at reducing the recovery time after the fix has already been applied, not changing the need for proper operational hygiene. From an operational perspective, being able to clear residual stale state in minutes instead of waiting out long TTLs can materially reduce user-visible impact. That’s the narrow problem EXPIRE is trying to address. Today that same action already happens via a mix of vendor-specific mechanisms, resolver restarts, or proprietary purge APIs at large providers. A standardized, authenticated mechanism reduces reliance on those ad-hoc tools without altering the expectation that configuration errors must be corrected properly. I'm happy to clarify the “exceptional use” nature of EXPIRE more explicitly in the next revision if that would help. Thanks again for surfacing this concern, Duane > On Nov 21, 2025, at 02:47, Vladimír Čunát > <[email protected]> wrote: > > On 20/11/2025 17.30, Duane Powers wrote: >> 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. > I'm afraid that this would even more encourage behavior that is detrimental > to the DNS ecosystem. > > I.e. we break our DNS, but since we can fix 8.8.8.8 and a few others, it's > just fine. I believe that this kind of cache-flushing should be very > exceptional for absolute emergency, not something with an automated protocol. > > --Vladimir | knot-resolver.cz > > _______________________________________________ > 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]
