| Internet-Draft | KeyState Signaling Via EDNS(0) | June 2026 |
| Bergström, et al. | Expires 19 December 2026 | [Page] |
This document introduces the KeyState EDNS(0) option, to enable a child operator to query a parent UPDATE Receiver about the state of a SIG(0) key used to secure cross-zone-cut DNS UPDATE messages. The KeyState option allows the child to include a key state inquiry in its DNS query, and the parent to include the corresponding key state in its response. This addresses the challenge of maintaining synchronization of SIG(0) keys between the child and the parent UPDATE Receiver: the child can become aware of any issue with its SIG(0) key in advance, before attempting the next operational DNS UPDATE.¶
TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-berra-dnsop-keystate. The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests.¶
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 19 December 2026.¶
Copyright (c) 2026 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.¶
In [I-D.ietf-dnsop-delegation-mgmt-via-ddns] a mechanism for automatic synchronization of delegation data between a child zone and a parent zone is proposed.¶
That mechanism relies on the parent validating and subsequently trusting the child SIG(0) public key so that the child is able to sign DNS UPDATE requests to the parent using the corresponding SIG(0) private key. While there is a mechanism for both uploading and rolling the public SIG(0) key there is still a risk of the child operator and the parent receiver getting out of sync.¶
This will be noticed by the child if a DNS UPDATE is refused. In this situation the parent UPDATE Receiver does have the opportunity and ability to provide more details of the refusal via an EDE opcode [RFC8914]. However, at that point it is too late to immediately get back in sync again and as a result the needed delegation synchronization that triggered the DNS UPDATE will be delayed until the child has managed to "re-bootstrap" a new SIG(0) key with the parent. As such re-bootstrapping may require manual actions, the length of the delay would not always be predictable.¶
The proposed new KeyState EDNS(0) Option addresses this problem by allowing the child and parent to exchange information about the current "state" of a SIG(0) key. This enables the child to become aware of any issue with the SIG(0) key currently being used in advance, and then address and resolve the problem. Additionally, the KeyState EDNS(0) Option enables the child to detect and resolve key synchronization issues before they cause operational failures.¶
Using the proposed KeyState option the child gains the ability to inquire about the state of its SIG(0) key at the parent UPDATE Receiver, and the parent gains the ability to respond with the current state, independently of a new DNS UPDATE (i.e. the exchange may be sent via a normal DNS QUERY + response).¶
It should be pointed out that for the child to be able to trust the response from the parent, the response must be signed using a key that the child trusts. As the mechanism for automatic synchronization of delegation data aims to work independently of whether the involved zones are DNSSEC-signed or not, this requires that the parent UPDATE Receiver is able to sign the response using its own SIG(0) private key.¶
Hence there is a similar need for the UPDATE Receiver to "bootstrap" (as in "validate so that the key may be trusted") the child SIG(0) public key and for the child to "bootstrap" the UPDATE Receiver SIG(0) public key. The mechanism for doing this is described in [I-D.ietf-dnsop-delegation-mgmt-via-ddns].¶
Knowledge of DNS NOTIFY [RFC1996] and DNS Dynamic Updates [RFC2136] and [RFC3007] is assumed. DNS SIG(0) transaction signatures are documented in [RFC2931].¶
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.¶
A DNS transaction signature mechanism ([RFC2931]) that uses asymmetric cryptography, allowing the recipient to verify a signature using only the sender's public key.¶
The child and parent zones on either side of a delegation, as in [I-D.ietf-dnsop-delegation-mgmt-via-ddns].¶
The entity (operated by the parent, or a registrar/agent acting on its behalf) that receives and processes DNS UPDATE messages for the delegation, as defined in [I-D.ietf-dnsop-delegation-mgmt-via-ddns].¶
The condition of a particular SIG(0) key as known to the UPDATE Receiver (for example, unknown, known, or trusted), signaled by the KeyState option defined in this document. The defined values are listed in Section 6.¶
EDE (Extended DNS Errors) lets the receiver of a DNS message provide more information about the reason for a negative response, carried in an OPT record as an EDE code and an optional human-readable "Extra Text". Three limitations make EDE insufficient for communicating key state between two parties:¶
An EDE must only be present in a response, not in the originating message.¶
An EDE must only be used to augment an error response. It should not be part of a successful response.¶
An EDE must contain an EDE info code (16 bits) and may contain "Extra Text". However this extra text is intended for human consumption, not automated parsing. To communicate state between two parties this requirement is too strict.¶
These are not flaws in EDE, which serves a different purpose; they simply mean that signaling key state between child and parent needs a dedicated mechanism, which this document provides.¶
This document uses an Extended Mechanism for DNS (EDNS0) [RFC6891] option to include Key State information in DNS messages. The option is structured as follows:¶
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | OPTION-CODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | OPTION-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: | KEY-ID |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
6: | KEY-STATE | KEY-DATA |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
8: / EXTRA-TEXT /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
¶
Field definition details:¶
OPTION-CODE: 2 octets / 16 bits (defined in [RFC6891]) contains the value TBD for KeyState.¶
OPTION-LENGTH: 2 octets / 16 bits (defined in [RFC6891]) contains the length of the payload (everything after OPTION-LENGTH) in octets and should be 4 plus the length of the EXTRA-TEXT field (which may be zero octets long). For example, for an option with no extra text OPTION-LENGTH is 4 (KEY-ID + KEY-STATE + KEY-DATA = 2 + 1 + 1 octets); for an option carrying 12 octets of extra text OPTION-LENGTH is 16.¶
KEY-ID: 16 bits. The KeyID of the SIG(0) key that the KeyState inquiry is referring to. Note that while KeyIds are not guaranteed to be unique, it is the child that generates the initial SIG(0) key pair and all subsequent key pairs. Hence, it is the child's responsibility to not use multiple keys with the same KeyId.¶
KEY-STATE: 8 bits. Currently defined values are listed in Section 6. Additional values may be defined in future documents.¶
KEY-DATA: 8 bits. Interpretation specific to each KEY-STATE.¶
EXTRA-TEXT: a variable-length sequence of octets that may hold additional information. This information is intended for human consumption (typically a reason or additional detail), not automated parsing. The length of the EXTRA-TEXT MUST be derived from the OPTION-LENGTH field. The EXTRA-TEXT field may be zero octets in length.¶
A child that wishes to receive KeyState information about its own SIG(0) key MUST include a KeyState option in its query or UPDATE message to the UPDATE Receiver. Including the option signals the child's capability and intent to receive a KeyState response; a child that does not need key-state information for a given message need not include it.¶
The UPDATE Receiver MUST only include a KeyState option when responding to a DNS message that contained a KeyState option; that is, the UPDATE Receiver never assumes that the child is able to interpret KeyState options. A KeyState option MAY be included in any type of response (SERVFAIL, NXDOMAIN, REFUSED, even NOERROR, etc.) to a query that includes a KeyState option.¶
A recipient that does not understand the KeyState option ignores it. A recipient that does understand it SHOULD respond with the KeyState for the specified key (identified by the KEY-ID field), unless local policy or operational constraints (for example, rate limiting) prevent it. When such a response is sent, it MUST meet the requirements in Section 6 (signed by the UPDATE Receiver's SIG(0) key and carrying a KeyState option).¶
This document includes a set of initial "key state" codepoints but is extensible via the IANA registry defined and created in Section 8.2.¶
This document defines a number of initial KEY-STATE codes. The mechanism is intended to be extensible and additional KEY-STATE codes can be registered in the "KeyState Codes" registry (see Section 8.2). The KEY-STATE code from the "KeyState" EDNS(0) option is used to serve as an index into the "KeyState Codes" registry with the initial values defined below.¶
For KeyState signaling to be used the child includes a KeyState option in its query to indicate the ability to interpret a KeyState option in the response.¶
The KEY-STATE code space is divided into three ranges by who sets the value and what it conveys: protocol-level responses (0-1, set by the UPDATE Receiver), inquiries set by the sender (2-3), and key-state reports set by the UPDATE Receiver (4-127). Private Use occupies 128-255.¶
These codes report on the KeyState exchange itself rather than on the state of any particular key. They are the KeyState equivalents of the DNS FORMERR and SERVFAIL conditions.¶
0 (KEY_REQUEST_MALFORMED): The KeyState request could not be understood; for example, it carried an unrecognized or unassigned KEY-STATE value (see below), an invalid KEY-DATA value, or a KeyState option that could not be parsed. The KEY-ID field MUST echo the KEY-ID from the request if it could be parsed, and MUST be 0 otherwise. KEY-DATA MUST be 0.¶
1 (KEY_TEMPORARY_FAILURE): The UPDATE Receiver understood the request but is temporarily unable to determine the state of the key. The child MAY retry the inquiry later. KEY-DATA MUST be 0.¶
An UPDATE Receiver that receives a KeyState option whose KEY-STATE value it does not recognize, including the unassigned values 3 and 11-127, MUST treat the request as malformed and respond with code 0 (KEY_REQUEST_MALFORMED).¶
2: Key inquiry. Child requests information about the current KeyState for the specified key. KEY-DATA MUST be 0.¶
Code 3 is unassigned. Together with codes 0 and 1, codes 2 and 3 were used differently in earlier revisions; see Section 8.2 for the historical context.¶
4 (KEY_TRUSTED): The SIG(0) key is known and trusted. KEY-DATA MUST be 0.¶
5 (KEY_UNKNOWN): The SIG(0) key is unknown. KEY-DATA MUST be 0.¶
6 (KEY_INVALID): The SIG(0) key is invalid (e.g. the key data does not match the declared algorithm). KEY-DATA MAY carry a receiver-defined sub-reason code; if no sub-reason is offered, KEY-DATA MUST be 0.¶
7 (KEY_REFUSED): The SIG(0) key is refused (e.g. the algorithm is not accepted by policy). KEY-DATA MAY carry a receiver-defined sub-reason code; if no sub-reason is offered, KEY-DATA MUST be 0.¶
8 (KEY_VALIDATION_FAILED): The SIG(0) key is known but validation has failed. This corresponds to the bootstrap state described in [I-D.ietf-dnsop-delegation-mgmt-via-ddns] Section "Communication in Case of Errors" as "SIG(0) key is known, but validation failed". KEY-DATA MUST be 0.¶
9 (KEY_BOOTSTRAP_AUTO): The SIG(0) key is known but not yet trusted; automatic bootstrap is in progress. This corresponds to the bootstrap state described in [I-D.ietf-dnsop-delegation-mgmt-via-ddns] Section "Communication in Case of Errors" as "SIG(0) key is known, but not yet trusted". KEY-DATA MUST be 0.¶
10 (KEY_BOOTSTRAP_MANUAL): The SIG(0) key is known but not trusted; manual bootstrap is required. This corresponds to the bootstrap state described in [I-D.ietf-dnsop-delegation-mgmt-via-ddns] Section "Communication in Case of Errors" as "Automatic bootstrap of SIG(0) keys not supported; manual bootstrap required". KEY-DATA MUST be 0.¶
128-255: Reserved for Private Use.¶
To ensure that the SIG(0) bootstrap is correctly prepared, the child (or an agent for the child) sends a DNS QUERY to the parent UPDATE Receiver with QNAME="child.parent." and QTYPE=KEY containing a KeyState option with KEY-STATE=2 (INTENT_INQUIRE_KEY) and the KeyId of the SIG(0) key to inquire about in the KEY-ID field. See [I-D.ietf-dnsop-delegation-mgmt-via-ddns] Section "Communication To Inquire State" for the canonical use case.¶
The response MUST be signed by the SIG(0) key for the UPDATE Receiver and MUST contain a KeyState option carrying the KeyId and the corresponding KEY-STATE as defined above. The mechanism by which the child obtains and validates the UPDATE Receiver's SIG(0) public key is specified in [I-D.ietf-dnsop-delegation-mgmt-via-ddns] Section "Bootstrapping the UPDATE Receiver's Key Into the Child".¶
Key state signals in OPT queries and answers are unauthenticated unless the transaction carrying the state signal is secured via mechanisms such as [RFC8945], [RFC2931], [RFC7858], [RFC9250], [RFC8484] or [RFC8094]. Unauthenticated information MUST NOT be trusted as the state signals influence the DNS protocol processing. For instance, an attacker might cause a denial-of-service by forging a response claiming that the victim's key is invalid, thereby halting the delegation synchronization procedure.¶
Moreover, it is assumed that the child has some means of validating messages from the parent during the initial phase when the child initializes the SIG(0) key synchronization. Otherwise, an attacker could prevent a child from initializing the synchronization by spoofing responses that refuse the key that the child is trying to upload. For that reason, it is expected that the parent has already published a public key that the child can use for this purpose. It could also possibly establish this trust out-of-band, such as via a physical meeting.¶
Lastly, SIG(0) transaction signatures are vulnerable to replay attacks, which could allow an attacker to disrupt the synchronization. Secure transport alternatives exist in [RFC7858], [RFC9250], [RFC8484] and [RFC8094].¶
This document defines a new EDNS(0) option, entitled "KeyState", assigned a value of TBD in the "DNS EDNS0 Option Codes (OPT)" registry¶
| Value | Name | Status | Reference |
|---|---|---|---|
| TBD | KeyState | Standard | (This document) |
The KeyState option defines an 8-bit state field, for which IANA is requested to create and maintain a new registry entitled "KeyState Codes", used by the KeyState option. Initial values for the "KeyState Codes" registry are given below; future assignments in the 11-127 range are to be made through Specification Required review [BCP26].¶
| KEY STATE | Mnemonic | Set by | Reference |
|---|---|---|---|
| 0 | KEY_REQUEST_MALFORMED | Receiver | (This document) |
| 1 | KEY_TEMPORARY_FAILURE | Receiver | (This document) |
| 2 | INTENT_INQUIRE_KEY | Sender | (This document) |
| 3 | Unassigned | -- | (This document) |
| 4 | KEY_TRUSTED | Receiver | (This document) |
| 5 | KEY_UNKNOWN | Receiver | (This document) |
| 6 | KEY_INVALID | Receiver | (This document) |
| 7 | KEY_REFUSED | Receiver | (This document) |
| 8 | KEY_VALIDATION_FAILED | Receiver | (This document) |
| 9 | KEY_BOOTSTRAP_AUTO | Receiver | (This document) |
| 10 | KEY_BOOTSTRAP_MANUAL | Receiver | (This document) |
| 11-127 | Unassigned | -- | (This document) |
| 128-255 | Private Use | -- | (This document) |
The code space is grouped as follows: codes 0-1 are protocol-level responses set by the UPDATE Receiver (the KeyState equivalents of FORMERR and SERVFAIL); codes 2-3 are set by the sender (the child), of which only 2 is currently defined; and codes 4-127 are key-state reports set by the UPDATE Receiver.¶
Codes 0 and 1 were used in draft-berra-dnsop-keystate-02 as the
sender codes REQUEST_AUTO_BOOTSTRAP and REQUEST_MANUAL_BOOTSTRAP.
Those uses were removed in -03 (bootstrap initiation and
bootstrap-method discovery are handled by the self-signed DNS UPDATE
and the SVCB bootstrap SvcParamKey specified in
[I-D.ietf-dnsop-delegation-mgmt-via-ddns]), and the codepoints are
reassigned here as the protocol-level responses described above.¶
draft-berra-dnsop-keystate-03¶
Aligned the draft with [I-D.ietf-dnsop-delegation-mgmt-via-ddns]: mapped each KeyState code to the corresponding named bootstrap state in that document, and added cross-references to the specific sections where the KeyState mechanism is used (state inquiry, re-bootstrapping, mutual authentication).¶
Removed the former sender codes 0 and 1 ("Automatic bootstrap requested" and "Manual bootstrap requested"). Bootstrap initiation and bootstrap-method discovery are handled by other mechanisms (the self-signed DNS UPDATE and the SVCB "bootstrap" SvcParamKey in [I-D.ietf-dnsop-delegation-mgmt-via-ddns]); KeyState is now used purely for key-state inquiry and reporting.¶
Added two protocol-level response codes for reporting on the KeyState exchange itself rather than on a key: KEY_REQUEST_MALFORMED (the equivalent of DNS FORMERR) and KEY_TEMPORARY_FAILURE (SERVFAIL), filling the previous gap where a receiver could not say "I could not understand your request" or "I cannot answer right now". Rather than leave a hole where the removed sender codes 0 and 1 had been, those two now-free codepoints are reused for these responses, giving a clean grouping: 0-1 protocol-level (receiver-set), 2-3 sender-set (only 2 defined), 4-127 key-state reports (receiver-set). This is an incompatible change to codepoints 0 and 1 relative to draft-berra-dnsop-keystate-02. A receiver MUST answer an unrecognized or unassigned KEY-STATE with KEY_REQUEST_MALFORMED.¶
Specified the contents of the KEY-DATA field per KeyState code.¶
Reworded the abstract (removed the "mutual awareness" overreach; the mechanism is child-inquires / parent-responds) and the "Use of the KeyState Option" text (removed the contradictory "may be included" / "MUST be present" wording). Added a cross-reference from Security Considerations to the receiver-key bootstrap mechanism in [I-D.ietf-dnsop-delegation-mgmt-via-ddns].¶
Editorial: fixed the GitHub URL in the abstract; settled on US "signaling" spelling; cleaned up the IANA registry table and unified the KeyState mnemonics (added a "Set by" column).¶
draft-berra-dnsop-opt-keystate-02¶
Removed policy inquiry KeyState code 3 (INQUIRY_POLICY) and policy response codes 11 (POLICY_MANUAL_BOOTSTRAP_REQUIRED) and 12 (POLICY_AUTO_BOOTSTRAP). Bootstrap policy discovery is now handled entirely via the SVCB "bootstrap" SvcParamKey mechanism described in [I-D.ietf-dnsop-delegation-mgmt-via-ddns].¶
Fixed wire format diagram: KEY-ID is 16 bits (a standard DNSSEC Key Tag), corrected byte offsets from 4/8/10 to 4/6/8.¶
Replaced hardcoded section number references with kramdown anchors for stable cross-references.¶
draft-berra-dnsop-opt-keystate-01¶
Fixed minor typos.¶
draft-berra-dnsop-opt-keystate-00¶
Initial public draft.¶