| Internet-Draft | DNS SIG Zero RRs | July 2026 |
| Eastlake, et al. | Expires 31 January 2027 | [Page] |
This document specifies the SIGZERO and SIG(0) Domain Name System (DNS) Resource Records (RRs) which provide public key based authentication of DNS requests and transactions. SIGZERO is the RECOMMENDED option. This document obsoletes RFC 2931.¶
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 31 January 2027.¶
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.¶
[[[ META COMMENTS: Comments within triple square brackets like this are discussion points or alternatives/options for the content of this draft. They are NOT text to be included in the final document. ]]]¶
This document specifies the Domain Name System (DNS) SIGZERO and SIG(0) Resource Records (RRs) which provide public key based authentication of DNS requests and transactions. SIGZERO is patterned after the TSIG [RFC8945] and RRSIG [RFC4034] RRs. Use of SIGZERO is RECOMMENDED for this purpose.¶
As discussed below, use of the SIG RR for this purpose is NOT RECOMMENDED. When a SIG RR is so used, it has a "type covered" field value of zero, and is called a "SIG(0)" RR.¶
The term "SIG Zero" is used in this document to refer to both the SIGZERO RR and the SIG(0) RR.¶
General familiarity with DNS terminology [RFC9499] is assumed.¶
SRP is Service Registration Protocol [RFC9665].¶
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.¶
The SIGZERO and SIG(0) (SIG Zero) Meta-RRs provide authentication and integrity protection for DNS transactions and requests that is not provided by the DNSSEC security specified in [RFC4034] and [RFC4035]. The authenticated data origin services of DNSSEC security provide either protected data resource records (RRs) or authenticatable denial of their existence. Those services provide no protection for the following:¶
As Meta-RRs, SIGZERO and SIG(0) are not stored in zones. They accompany DNS messages in the Additional Information section of the message. (Meta-RRs are usually "one DNS server hop" and not forwarded by recursive servers but see Section 7.1 for a discussion of forwarding SIG Zero RRs.)¶
Transaction authentication can provide cryptographic assurance to a resolver that it is getting the DNS response message from the server to which it sent a request and that the received message is in response to that request. This is accomplished by adding either a TSIG RR [RFC8945] or, as specified herein, a SIG Zero RR, at the end of the additional information section of the response which authenticates the concatenation of the corresponding resolver request and the server's response.¶
Requests can be authenticated by including a SIG Zero RR at the end of the request's additional information section. This method of signing requests is primarily intended for authenticating requests for integrity protection and to demonstrate that the requester is authorized to make the request by its possession of the private key needed to generate the SIG Zero RR. Examples of such requests are dynamic update requests [RFC3007], use in the Service Registration Protocol (SRP) for DNS-Based Service Discovery [RFC9665], and TKEY requests [rfc2930bis]. There may be additional requests specified in the future that require such authentication.¶
The private keys used in public key based request security typically belong to the host composing the DNS request message or the other entity composing the request or to a zone to be affected by the request. The corresponding public key(s) can be stored in and retrieved from the DNS for verification as KEY RRs with a protocol byte of 3 or 255 (ANY).¶
A TSIG [RFC8945] RR can also be used for request and transaction authentication. There are significant differences between TSIG and SIG Zero.¶
Because TSIG involves secret keys available at both the requester and server the presence of such a key can imply that it is likely that the other party understands TSIG and has the same key installed. Furthermore, TSIG uses keyed hash authentication codes which are relatively compact and inexpensive to compute. Thus, if shared secret keys are in place and there is agreement to do so, it is relatively inexpensive to authenticate DNS requests and transactions with TSIG.¶
SIGZERO and SIG(0) on the other hand, use public key authentication, where the public keys can be stored in DNS as KEY RRs and a private key is held by the signer. Existence of such a KEY RR does not necessarily imply that SIGZERO or SIG(0) are implemented or enabled. In addition, they involve relatively expensive public key cryptographic operations and their verification involves obtaining and verifying the corresponding KEY which can itself be an expensive operation. Indeed, a policy of using a SIGZERO or SIG(0) on all requests and verifying it before responding would, for some configurations, lead to a deadly embrace with the attempt to obtain and verify the KEY needed to authenticate the request resulting in additional requests accompanied by a SIGZERO or SIG(0) leading to further requests accompanied by a SIGZERO or SIG(0), etc. Furthermore, omitting these RRs when not required on requests halves the number of public key operations required by the transaction and saves space in requests.¶
For these reasons, a SIG Zero RR SHOULD only be used on requests when necessary to authenticate that the requester has some required privilege or identity. SIG Zero on transactions is defined in such a way as to not require a SIG Zero on the corresponding request and still provide transaction protection.¶
Which SIG Zero RRs are required to be authenticated by a server or requester should be a local configuration option.¶
The SIGZERO RR was designed for this application and its use is RECOMMENDED. SIG(0) is an alternative use of the older SIG RR originally specified in [RFC2535] and is NOT RECOMMENDED. Four reasons for this preference are as follows:¶
[[[ This section currently preserves the [RFC2931] tight restrictions on multiple TSIGs and/or SIG(0)s by themselves but is more liberal on SIGZERO and permits one or more SIGZEROs to be accompanied by a TSIG. Should this be yet further liberalized? ]]]¶
A request or response may contain any one of the following but no other combinations are permitted:¶
It MUST NOT have both a TSIG and a SIG(0). It MUST NOT have more than one TSIG or more than one SIG(0). It MUST NOT have a SIG(0) along with a SIGZERO. A request with these prohibited combinations MUST be rejected with FORMERR and a response with such a combination is ignored.¶
Since SIG Zero RRs in a DNS message do not sign each other, their order is not significant. They may be inserted into or removed from the message without affecting the validity of any other SIG Zeros in the message.¶
Support for the SIGZERO RR is indicated by the SZ bit in the EDNS(0) OPT RR. (See Section 9.2.)¶
The format of the SIGZERO and SIG(0) RRs are specified in the subsections below. All multi-octet integers in these RRs are sent in network byte order (see Section 2.3.2 of [RFC1035]).¶
When SIG Zero authentication on a response is desired, the SIG Zero RR MUST be considered the highest priority of any additional information for inclusion in the response. If the SIG Zero RR cannot be added without causing the message to be truncated, the server MUST alter the response so that a SIG Zero can be included, set the TC bit, and return RCODE 0 (NOERROR). The client should at this point retry the request using an available transport that does not have UDP packet size restrictions.¶
The fields of the SIGZERO Meta-RR are described below. Most of these fields are similar or identical to the field in the TSIG [RFC8945] or RRSIG [RFC4034] RR with same field name.¶
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Owner Name = Signer's Name | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TYPE = TBD | CLASS = 0x00FF (ALL) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TTL (MUST be zero) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RDLENGTH | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RDATA / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Flags | Original ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error | Fudge |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Time Signed +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Signature Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Tag | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signature /
/ /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Other Length | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Other Data /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Time Signed and the Fudge form a time bracket, that is, the Time Signed plus/minus the Fudge, for the purpose of limiting replay attacks. Signatures received outside that bracket are considered invalid. In IP networks, the value of Fudge should normally not be more than 5 minutes.¶
[[[ Should the Other Length / Other Data construct copied from TSIG and TKEY be replaced by TLVs, which would be more flexible? ]]]¶
The structure of the SIG(0) resource record (RR) is the same as the structure of the RRSIG RR in [RFC4034] Section 4 except as provided below.¶
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Owner Name (not used, SHOULD be 0x0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TYPE = 24 | CLASS = 0x00FF (ALL) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TTL (MUST be zero) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RDLENGTH | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RDATA / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The type of the SIG RR is 24. The structure of a SIG(0) RDATA is shown in Figure 4.¶
For SIG(0) RRs, the above Owner Name, CLASS, and TTL fields are meaningless. To conserve space, the owner name SHOULD be root (a single zero octet). The TTL field MUST be zero. The CLASS field MUST be 255 (ANY), These fields are ignored on receipt. A TTL of zero decreases the risk that a DNS implementation that does not understand SIG(0) will cache such an RR. The RDATA for a SIG(0) RR consists of a number of fields as described below.¶
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Covered = 0 | Algorithm | Labels = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original TTL = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Expiration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Inception |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Tag | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Signature /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For transaction SIG(0)s, there MUST be a KEY RR associated with the signer name with the public key corresponding to the private key used to calculate the signature. For general transaction authentication and integrity, the Signer's Name field is a name of the originating host; for example, the host domain name used may be the inverse IP address mapping name for an IP address of the host if the relevant KEY is stored there. For SIG(0)s on requests requiring authentication, the signer relates to the authority being requested such as authority to update a zone.¶
This section specifies the exact data over which request and transaction SIG Zero RRs are calculated. In the case of more than one SIGZERO RR, there is no significance to their order and a SIGZERO RR does not sign any other SIGZERO RR in that DNS message.¶
A DNS request may be optionally signed by including one or more SIGZERO RRs at the end of the request additional information section. These RRs are calculated for and sign the "data" consisting of the following:¶
That is¶
data = (SIGZERO RR with zero Signature) |
(request message without SIG Zero RRs)
¶
where "|" is concatenation and RR is a SIGZERO RR with the signature field set to zero.¶
A DNS request may be optionally signed by including a single SIG(0) RR) at the end of the request additional information section. This RR is calculated for and signs the "data" consisting of the following:¶
That is¶
data = (SIG(0) RDATA with Signature omitted) |
(request without SIG(0))
¶
where "|" is concatenation and RDATA is the RDATA of a SIG(0) being calculated completely omitting the Signature itself.¶
A SIGZERO can be used to secure a transaction consisting of a response and the request that produced it. Such a transaction signature SIGZERO, to be included in the response, is calculated over data consisting of the following:¶
data = (SIGZERO RR with signature zeroed) |
(request message without SIG Zeros) |
(response message without SIG Zeros)
¶
where "|" is concatenation.¶
With appropriate configuration, successful verification of a response SIGZERO cryptographically confirms that the query and response were not tampered with in transit, that the response corresponds to the intended query, and that the response comes from the queried server.¶
A SIG(0) can be used to secure a transaction consisting of a response and the request that produced it. Such a transaction signature is calculated by using data consisting of¶
data = (SIG(0) RDATA omitting signature) |
(request message) |
(response message without SIG Zeros)
¶
where "|" is concatenation and RDATA is the RDATA of a SIG(0) being calculated omitting the signature itself.¶
With appropriate configuration, successful verification of a response SIG(0) cryptographically confirms that the query and response were not tampered with in transit, that the response corresponds to the intended query, and that the response comes from the queried server.¶
In the case of a DNS message split into multiple packets via a stream transport (e.g. TCP, DoT, etc.), a SIG Zero on the first data packet is calculated with "data" as above but using data only from the first packet. For each subsequent packet, it is calculated as follows:¶
data = ( (SIG(0) RDATA) or (SIGZERO RR) ) |
(DNS payload without SIG Zeros) |
(previous packet)
¶
where "|" is concatenations, RDATA and SIGZERO RR are as above, and previous packet is the previous DNS payload including DNS header but not any preceding headers such as TCP or IP and including the SIG(0) RR if one was present but not any SIGZERO RRs.¶
This does not apply to fragmented UDP where the message is just signed once at the end and then fragmented.¶
Except where needed to authenticate an update, TKEY, SRP registration or similar request, servers are not required to verify a request SIG Zero.¶
If the time when a SIG Zero on a request is received is outside the interval indicated (by the Inception and Expiration Times for a SIG(0) or the Time Signed and Fudge for a SIGZERO), the BADTIME error is returned. If this applies to a response, the response is ignored.¶
If one or more SIG Zero RRs are at the end of the additional information section of a response, they are transaction signatures covering the response and the request that produced that response.¶
If a response's SIG Zero check succeeds, such a transaction authentication does NOT directly authenticate the validity of any data RRs in the message. However, it can increase confidence that they were sent by the queried server and have not been altered in transit. (Only an RRSIG RR [RFC4034] signed by the zone or a key tracing its authority to the zone or to resolver configuration can directly authenticate data RRs, depending on resolver policy.) If a resolver or server does not implement transaction and/or request SIG Zeros, it MUST ignore them without error where they are optional and treat them as failing where they are required.¶
If a response has multiple SIGZERO RRs and verification of some succeeds and other fail, the appropriate action is dependent on local policy and configuration.¶
A server acting as a forwarding (recursive) server of a DNS message such as an Update or an SRP registration SHOULD check for the existence of SIG Zero RRs. If it implements SIG Zero RRs but cannot verify a SIG Zero RR, the server MUST include that SIG Zero RR when forwarding the message. If a SIG Zero passes all checks and verifies, the forwarding server SHOULD remove it and if possible, add a SIG Zero of its own to the destination or the next forwarder. If no transaction security is available to the destination and the message is a request, and if the corresponding response has the AD flag (see [RFC4035]) set, the forwarder MUST clear the AD flag before adding a SIG Zero to the response and returning the result to the host from which it received the request.¶
The transit of a DNS request between the originating client and final server through one or more forwarding servers and the similar handling of its response introduces additional potential failure and/or compromise points. Thus, when practical, requests with a SIG Zero RR should be sent directly to the final server that will verify that SIG Zero.¶
[[[ This section probably need some more work. ]]]¶
Private keys used to create SIG Zero RRs are very sensitive information and all available steps should be taken to protect them on every host on which they are stored. Such hosts may need to be physically protected. If they are multi-user machines, great care should be taken so that unprivileged users have no access to private keying material.¶
The inclusion of the SIG Zero Inception and Expiration Time and the SIGZERO Time Signed and Fudge under the signature improves resistance to replay attacks.¶
IANA is requested to make the assignments specified in the following sections.¶
IANA is requested to assign a SIGZERO RRTYPE number in the "Resource Record (RR) TYPEs" registry [DNSparams] in the range for meta-RRs as requested in Appendix A. [Value 248 is suggested] The resulting entry would be as follows:¶
| TYPE | Value | Meaning | Reference |
|---|---|---|---|
| SIGZERO | TBD | Public key request or transaction signature. | [this document] |
IANA is requested to assign an EDNS Header flag in the EDNS Header Flags registry in the Domain Name System (DNS) Registry Group as follows:¶
| Bit | Flag | Description | Reference |
|---|---|---|---|
| TBD2 | SZ | SIGZERO supported | [this document] |
A. Submission Date: tbd
B.1 Submission Type: [X] New RRTYPE [ ] Modification to RRTYPE
B.2 Kind of RR: [ ] Data RR [X] Meta-RR
C. Contact Information for submitter (will be publicly posted):
Name: Donald Eastlake Email Address: d3e3e3@gmail.com
International telephone number: +1-508-333-2270
Other contact handles:
D. Motivation for the new RRTYPE application.
SIG(0) has been found to have a number of deficiencies which are
fixed in the specification for this new RRTYPE.
E. Description of the proposed RR type.
See draft-eastlake-dnssd-rfc2931bis-sigzero
F. What existing RRTYPE or RRTYPEs come closest to filling that need
and why are they unsatisfactory?
The SIG RR (RFC 2536) with type covered of zero. Deficiencies
are listed in draft-eastlake-dnssd-rfc2931bis-sigzero
G. What mnemonic is requested for the new RRTYPE (optional)?
SIGZERO
H. Does the requested RRTYPE make use of any existing IANA registry
or require the creation of a new IANA subregistry in DNS
Parameters?
Does not create any new registries and does not add entries to
existing registries other than the allocation of the RRTYPE.
I. Does the proposal require/expect any changes in DNS
servers/resolvers that prevent the new type from being processed
as an unknown RRTYPE (see RFC 3597)?
It can be ignored but then you do not get its security benefits.
J. Comments: See draft-eastlake-dnssd-rfc2931bis-sigzero
¶
RFC Editor: Please delete this section before publication.¶
Note: This draft was initially targetted to the DNSOP WG but, after discussion with the Chairs and draft authors, was re-targetted to the DNSSD WG.¶
The comments and suggestions of the following are gratefully acknowledged:¶
Stuart Cheshire¶
The comments and suggestions of the following persons were incorporated into [RFC2931], which was the previous version of this document, and are gratefully acknowledged:¶
Olafur Gudmundsson, Ed Lewis, Erik Nordmark, Brian Wellington.¶