| Internet-Draft | DNS EXPIRE Opcode | November 2025 |
| Powers | Expires 24 May 2026 | [Page] |
This document defines a new DNS message opcode, EXPIRE, which enables an authenticated authoritative operator to request immediate deletion of a specific RRset from a resolver's cache. EXPIRE messages may be authenticated either through DNSSEC signatures or through resolver control-channel authentication (for example TSIG, mutually authenticated TLS, IPsec, or local trust policy). EXPIRE applies only to resolver cache and MUST NOT modify authoritative data.¶
Resolvers validate authority, apply mandatory replay protection using SOA serials when available or equivalent replay-mitigation mechanisms, and flush the targeted RRset upon successful validation. EXPIRE provides a deterministic, authenticated mechanism for cache rollback and correction across both signed (DNSSEC) and unsigned (internal) DNS deployments.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 24 May 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
DNS caching improves performance but complicates rollback and repair when resolvers retain stale or erroneous RRsets. The DNS protocol includes no authenticated in-band mechanism for a resolver to flush a cached RRset before TTL expiration.¶
This document defines a new DNS opcode, EXPIRE, which allows an authoritative operator, authenticated via DNSSEC or a resolver control channel, to instruct a resolver to delete a specific RRset from its cache. EXPIRE uses RFC 2136-style RRset deletion semantics (QCLASS=NONE) but applies strictly to resolver cache.¶
EXPIRE is intended to be deployable in both DNSSEC-signed environments and non-DNSSEC internal environments that already rely on TSIG, mutually authenticated TLS, IPsec, or equivalent control-channel mechanisms. This dual-profile model is analogous to the operational deployment of RFC 2136 Dynamic Update.¶
EXPIRE: The DNS opcode defined in this document.¶
RRset: A set of resource records sharing owner name, type, and class.¶
Resolver: A recursive DNS server that maintains a cache.¶
Validating Resolver: A resolver that performs DNSSEC validation.¶
Control Channel: An authenticated resolver interface such as TSIG, mutually authenticated TLS, IPsec, or an implementation-specific management channel.¶
Authoritative Operator: Entity controlling publication of zone data.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Operators often require immediate cache correction due to erroneous publication, emergency failover, rollback of TLSA or SRV records, stale negative cache entries, or long TTLs. Existing mechanisms such as low TTLs, aggressive resigning, or manual outreach to resolver operators are operationally insufficient.¶
DNSSEC already defines a cryptographic authority model for signed zones. For internal, unsigned zones, operators typically rely on authenticated control channels (TSIG, mutually authenticated TLS, IPsec, or local ACLs) to manage resolvers. EXPIRE therefore defines two authentication profiles: a DNSSEC profile and a control-channel profile, each providing a standards-aligned way to authenticate EXPIRE without introducing new trust assumptions.¶
A particularly critical operational scenario involves rapid NS record updates during DDoS or routing incidents. When authoritative operators update NS records to redirect traffic away from attacked infrastructure, cached NS RRsets at resolvers may persist for the duration of their TTL -- potentially hours or days. EXPIRE enables authenticated, immediate cache invalidation of NS records, allowing traffic redirection in near-real-time during operational emergencies when seconds matter.¶
IANA is requested to assign a new DNS Opcode, EXPIRE (TBD), from the DNS OpCode registry.¶
EXPIRE uses the DNS UPDATE message structure defined in RFC 2136 for RRset deletion semantics (QCLASS=NONE). EXPIRE messages operate exclusively on resolver cache and MUST NOT modify authoritative data.¶
The Question Section of an EXPIRE message MUST contain:¶
Resolvers receiving an EXPIRE message with QCLASS not equal to NONE MUST discard the message.¶
The content of the Answer Section depends on the authentication profile in use.¶
When DNSSEC is used, the Answer Section MUST contain:¶
Resolvers MUST validate the RRSIG but MUST ignore the RDATA and TTL of the synthetic RRset. No comparison against cached RDATA is performed.¶
When control-channel authentication is used, the Answer Section MAY be omitted. If present, it MAY contain a synthetic RRset, but no RRSIG is required and no DNSSEC fields need to be included.¶
A resolver implementing the control-channel profile MUST accept an EXPIRE message whose Question Section is the only populated section, assuming the control-channel authentication has succeeded.¶
This distinction allows DNSSEC environments to obtain in-band cryptographic proof of authority, while non-DNSSEC deployments avoid unnecessary overhead and may treat EXPIRE as a remote cache-management operation.¶
The use of the SOA RRset in the Additional Section depends on the authentication profile.¶
The Additional Section MUST contain the zone's SOA RRset and a valid RRSIG covering it. The resolver MUST validate the SOA RRSIG and use the SOA serial number as the basis for replay protection as described in Section 5.4.¶
The Additional Section MAY contain an unsigned SOA RRset. If present, the resolver SHOULD use the SOA serial for replay protection as described in Section 5.4.¶
If no SOA is present, the resolver MAY rely on implementation-defined replay-protection mechanisms (nonces, per-sender counters, authenticated-session state, or other mechanisms providing equivalent or stronger guarantees).¶
EXPIRE messages MUST NOT contain wildcard owner names in the Question Section. Resolvers receiving EXPIRE messages with wildcard QNAMEs MUST discard them.¶
EXPIRE requires no explicit capability negotiation. Resolvers that do not implement EXPIRE SHOULD silently discard EXPIRE messages. Legacy resolvers MAY return NOTIMP or REFUSED in accordance with RFC 1035. Authoritative operators and control tools MUST treat NOTIMP, REFUSED, and silent discard as equivalent indicators of non-support. Resolvers that implement EXPIRE but reject it for policy reasons (e.g., rate-limiting, sender not authorized) SHOULD return SERVFAIL or NOTAUTH rather than NOTIMP.¶
A resolver that implements EXPIRE MUST authenticate EXPIRE messages using at least one of the following profiles:¶
Deployments MAY enable both profiles concurrently. If any enabled profile successfully authenticates the EXPIRE message, the resolver MAY proceed with EXPIRE processing.¶
A resolver using the DNSSEC profile MUST perform DNSSEC validation of the EXPIRE message components as follows:¶
Any DNSSEC validation failure under this profile MUST cause the resolver to reject the EXPIRE message.¶
For zones that are unsigned or environments that do not deploy DNSSEC, resolvers MAY authenticate EXPIRE messages using an authenticated control channel. This model is equivalent to the trust assumptions used for RFC 2136 Dynamic UPDATE, RNDC, and other resolver management operations.¶
Acceptable forms of control-channel authentication include, but are not limited to:¶
When control-channel authentication is used, resolvers MAY bypass DNSSEC validation of the EXPIRE message, including the synthetic RRset and SOA, but MUST still apply replay protection whenever SOA data or an equivalent replay mechanism is available (Section 5.4).¶
Implementations SHOULD provide configuration allowing administrators to specify "authorized EXPIRE senders" per zone or per resolver instance, using source addresses, TSIG key identities, TLS client identities, or other locally meaningful attributes.¶
Resolvers implementing EXPIRE MUST implement replay protection to prevent stale EXPIRE messages from deleting more recent data. SOA serial numbers SHOULD be used when available.¶
When SOA-based replay protection is used, the resolver applies the following rules:¶
If the resolver determines, by local policy, that the EXPIRE-associated serial is older than the cached serial, it MUST reject the EXPIRE message as a replay.¶
Under the control-channel profile, resolvers MAY implement alternative replay-protection mechanisms, such as nonces, per-sender monotonic counters, or authenticated session state, provided these mechanisms offer replay resistance at least as strong as SOA-serial-based checks.¶
A resolver MAY check whether the targeted RRset is present in cache prior to performing DNSSEC validation of the synthetic RRset. If the RRset is not present, the resolver MAY skip DNSSEC validation of the synthetic RRset but MUST still apply any available replay protection when SOA data or other replay mechanisms are present.¶
Upon successful authentication and replay protection, the resolver MUST:¶
Resolvers MUST NOT delete unrelated RRsets, including other RRTypes at QNAME, CNAME/DNAME records pointing to QNAME, or RRsets under other owner names.¶
Resolvers MUST NOT compare EXPIRE RDATA to cached RDATA, MUST NOT require matching RRSIGs, and MUST NOT consider TTL or RRset cardinality when deciding whether to delete the cached RRset. EXPIRE is a cache control signal, not a replacement data payload.¶
After processing EXPIRE, the resolver MAY immediately requery authoritative servers for (QNAME, QTYPE) or MAY wait until the next client query for that name and type. This behavior is an implementation choice and does not affect protocol correctness.¶
Responding to EXPIRE messages is OPTIONAL. If a resolver chooses to respond, it SHOULD use the following RCODEs for interoperability:¶
The EXPIRE message was successfully processed. This includes cases where the targeted RRset was not present in cache.¶
Authentication failed (DNSSEC validation failed, control channel authentication failed, or sender was not in the authorized-sender list for this resolver or zone).¶
The resolver does not support EXPIRE or rejected the message as unsupported. Authoritative operators and control tools MUST treat these codes as equivalent to non-support.¶
Silent discard is permitted for all failure conditions.¶
Authoritative servers or associated front ends (such as DNS load balancers or policy engines) MAY originate EXPIRE messages. EXPIRE MUST NOT modify authoritative zone data. A valid DNSSEC signature or authenticated control channel proves authority, depending on the chosen authentication profile.¶
In control-channel deployments, EXPIRE is conceptually similar to existing RNDC or management-API operations that flush cache entries, but uses a standardized on-the-wire format suitable for multi-vendor and cross-network use.¶
EXPIRE uses UDP by default. TCP MAY be used when message size, operational policy, or transport characteristics require it.¶
When EXPIRE is carried over DNS-over-TLS (RFC 7858) or DNS-over-HTTPS (RFC 8484) with mutual TLS authentication (client certificate authentication), the control-channel authentication profile MAY rely on the TLS client identity as proof of authorization. Server-only TLS authentication (typical for public resolvers) does NOT satisfy the control-channel authentication requirements and MUST NOT be accepted as authorization for EXPIRE unless combined with another authentication mechanism such as TSIG or the DNSSEC authentication profile.¶
EXPIRE does not require a persistent channel or an explicit acknowledgement beyond the optional DNS response described in Section 5.8. Standard DNS transport rules apply.¶
EXPIRE introduces no new authority beyond DNSSEC and existing resolver control-channel mechanisms. Under the DNSSEC authentication profile, EXPIRE is limited by the same trust model and failure modes as DNSSEC validation. Under the control-channel profile, EXPIRE inherits the security properties of the resolver's management channel (TSIG, mutually authenticated TLS, IPsec, or local trust policy).¶
EXPIRE may enable inference of cache state through timing analysis if resolvers exhibit observable behavioral differences when an RRset is present versus absent in cache. However, similar probing is already possible using ordinary DNS queries and cache-priming techniques. Resolvers SHOULD avoid introducing additional timing side channels beyond those inherent in normal DNS operation.¶
The control-channel authentication profile relies on the same trust relationships already used for RNDC, Dynamic Update, and resolver management APIs. Operators MUST ensure that these channels are appropriately protected (for example, with strong TSIG keys, mutually authenticated TLS, IPsec, or physically or logically isolated management networks).¶
Resolvers SHOULD apply per-zone or per-source rate limiting to EXPIRE processing to avoid excessive work caused by repeated EXPIRE messages for the same owner name. EXPIRE does not introduce a fundamentally new class of denial-of-service attack beyond those associated with DNSSEC validation and existing management operations, but implementers SHOULD ensure that EXPIRE handling remains within typical validation and management cost profiles.¶
Control-channel authentication allows EXPIRE to be safely deployed in internal DNS environments that do not sign their zones with DNSSEC. In such environments, EXPIRE behaves as a standardized remote cache-expiration command, authenticated by the same mechanisms already used for update and management.¶
In clustered resolver deployments, implementations MAY propagate the effects of EXPIRE across cluster members using any appropriate internal mechanism. This document does not specify intra-cluster propagation semantics and considers them implementation-specific.¶
EXPIRE is intended to be safe for both public and private deployments. Resolvers and operators that do not wish to support EXPIRE simply ignore the opcode or return NOTIMP or REFUSED as described in Section 4.4, and no protocol-level harm results.¶
IANA is requested to assign a new DNS OpCode value for EXPIRE in the "DNS OpCodes" registry. The mnemonic is:¶
EXPIRE (TBD)¶
NOTIFY alerts secondary nameservers of zone changes but does not provide cache invalidation for resolvers. NOTIFY targets only configured secondary nameservers, whereas EXPIRE can be directed to arbitrary resolvers. NOTIFY and EXPIRE serve complementary roles and may coexist in DNS deployments.¶
Dynamic UPDATE modifies authoritative zone data and requires zone transfer privileges or TSIG-based authorization for zone updates. EXPIRE modifies only resolver cache and requires only DNSSEC zone-signing authority (under the DNSSEC profile) or resolver management-channel access (under the control-channel profile). EXPIRE cannot add data or modify zone contents; it can only request deletion of cached RRsets.¶
The dual-profile model used by EXPIRE follows the precedent established by RFC 2136, which supports both SIG(0) (DNSSEC) and TSIG authentication.¶
Reducing TTL values increases query load on authoritative infrastructure and cannot retroactively affect RRsets that are already cached with longer TTLs. EXPIRE provides immediate, targeted cache invalidation independent of TTL values and avoids the operational overhead of maintaining artificially low TTLs for rollback scenarios.¶
The following example illustrates an EXPIRE message using the DNSSEC authentication profile. The resolver validates the RRSIGs over the synthetic RRset and the SOA.¶
;; HEADER
OPCODE: EXPIRE
;; QUESTION
example.com. NONE A
;; ANSWER
example.com. 0 IN A 0.0.0.0
example.com. 0 IN RRSIG A <dnssec-signature>
;; ADDITIONAL
example.com. 0 IN SOA ns1.example.com. admin.example.com. (
2025111901 3600 600 604800 300 )
example.com. 0 IN RRSIG SOA <dnssec-signature>
¶
The following example illustrates an EXPIRE message using the control-channel authentication profile with TSIG. The Answer Section is empty; the resolver relies on the TSIG-authenticated channel and its local policy to authorize the operation.¶
;; HEADER OPCODE: EXPIRE ;; QUESTION example.com. NONE A ;; ANSWER ;; (empty - allowed under control-channel profile) ;; ADDITIONAL example-key. TSIG hmac-sha256. <tsig-data> ;; (note: TSIG appears in Additional section per RFC 8945) ;; (optional unsigned SOA MAY also be included for replay protection)¶