Hi Paul,

I appreciate you taking a look at my draft proposal. You raise a couple
really good points I'd like to address.·

First, your concerns really made me think this through. Thank you for·
the challenge.·

As you pointed out, big operators already do this through various
mechanisms, tooling does exist. But it is vendor specific,·
heterogeneous and not interoperable. EXPIRE would provide a consistent
protocol-level solution.

The question of whether a particular resolver is reachable from the·
outside is orthogonal to EXPIRE — this is a pre-existing condition for
any authenticated operation (UPDATE with TSIG, NOTIFY, Google or·
Cloudflare purge APIs, etc.). EXPIRE neither creates nor worsens
that situation.

I'm thinking of the internal help desk who gets a ticket for a stale·
record. Current state for most operators is either vendor specific tooling,
or a full cache restart. This would allow authenticated operators the 
chance to manage their environments beyond what is typically possible 
now.·

With respect to your ZSK concern: BIND, Knot, PowerDNS, and others
already support DNSSEC-signed dynamic updates, where an authoritative
server generates the RRSIGs automatically. An operator submitting an·
EXPIRE message does not need direct access to the ZSK any more than·
an operator submitting an UPDATE does.

Further, an EXPIRE request does not require modifying the zone itself,·
nor does it need an offline signer. Authoritative servers that already
perform DNSSEC signing for UPDATE can sign the synthetic RRset in·
EXPIRE using the same signing mechanisms currently used for
UPDATE-generated RRsets.

Finally, DNSSEC is not required at all if using TSIG or another
authenticated mechanism.

Again, I appreciate the discourse, thank you for engaging. 

Best, 
Duane


> On Nov 20, 2025, at 13:00, Paul Wouters <[email protected]> 
> wrote:
> 
> On Thu, 20 Nov 2025, Duane Powers wrote:
> 
> [ speaking only as DNS enthousiast ]
> 
>> 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 had a quick look. My first concern is more centralization of the
> internet by this standard due to resolvers on public IP becoming more
> reliable than those behind NAT as those well known centralized DNS
> servers are the only ones you can reach.
> 
> The dnssec based variant requires the sender to have the ZSK private
> key - eg online signer (or a dedicated machine for issuing EXPIREs that
> shares the ZSK)
> 
> 
> It seems there are existing methods already, like
> https://developers.google.com/speed/public-dns/cache
> 
> These have the benefits that anyone can request a cache expire and so
> this is potentially faster than the domain owner taking action.
> 
> 
> Perhaps some _expire-api prefix record towards a rest api makes more
> sense than shoehorning this into DNS ?
> 
> Paul
> 

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to