Internet-Draft DNS SIG Zero RRs October 2026
Eastlake, et al. Expires 24 April 2027 [Page]
Workgroup:
DNSSD
Internet-Draft:
draft-eastlake-dnssd-rfc2931bis-sigzero-04
Obsoletes:
2931 (if approved)
Updates:
6891 (if approved)
Published:
Intended Status:
Standards Track
Expires:
Authors:
D. Eastlake
Independent
J. Stenstam
Swedish Internet Foundation
M. Andrews
ISC

Domain Name System (DNS) Public Key Based Request and Transaction Authentication (SIGZERO, SIG(0))

Abstract

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 and updates RFC 6891.

Status of This Memo

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 April 2027.

▲

Table of Contents

1. Introduction

[[[ 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.

[[[ It has been suggested that "MSGSIG" be used as the mnemonic for the new RR, rather than "SIGZERO", to emphasize that it covers messages and to avoid confusion. Should a global replace of SIGZERO with MSGSIG and any other needed adjustments to implement that mnemonic change be done? IF THERE AREN'T ANY OBJECTIONS, THIS CHANGE WILL BE MADE IN THE NEXT REVISION. ]]]

This document obsoletes [RFC2931] and, as summarized in Appendix B, updates [RFC6891].

2. Terminology

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 the 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.

3. SIG Zero RR Design Rationale and Use

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 servers but see Section 8 for a discussion of forwarding SIG Zero RRs.)

Transaction authentication can provide cryptographic assurance to a requester 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 a SIG Zero RR, to the additional information section of the response which, in effect, authenticates the concatenation of the corresponding resolver request and the server's response.

Requests can be authenticated by including a SIG Zero RR in the request's additional information section. This method of signing requests is primarily intended for authenticating requests for the purposes of integrity protection and demonstration that the requester is, by its possession of the private key needed to generate the SIG Zero RR, authorized to make the request. 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 and integrity protection.

The private keys used in public key based request security typically belong to the host or other entity composing the DNS message 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 (see [KEYRR]) with a protocol byte of 3.

4. Differences Between TSIG, SIGZERO, and SIG(0)

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. A TSIG on a transaction is specified so as to require a TSIG on the request involved.

SIGZERO and SIG(0), on the other hand, use public key authentication, where the public keys can be stored in DNS as KEY RRs (see [KEYRR]) 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. This would result 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.

4.1. Why SIGZERO Is Preferred Over SIG(0)

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 RFC3445 and is NOT RECOMMENDED. The reasons for this preference include the following:

  1. SIG(0) does not provide a convenient way to include an extended error code in a response reporting on the SIG(0) operation. SIGZERO has an Error field for this purpose (as do the TSIG and TKEY RRs).
  2. SIG(0) does not provide a convenient way to forward the original DNS request message ID through a forwarding server but this value is needed to validate a SIG(0) or SIGZERO signature. SIGZERO has a reserved field for this value (as does the TSIG RR). (See Section 8.)
  3. There is no convenient way to extend SIG(0) while SIGZERO has an Other Data field for this purpose.
  4. The SIG RR was used as a data RR for signatures and its RRTYPE is in the range normally used for data RRs, not Meta-RRs. That it is actually a Meta-RR if and only if a SIG RR's Type Covered field is zero might confuse a deficient DNS implementation.

4.2. Multiple TSIGs, SIGZEROs, and/or SIG(0)s

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). A request with these prohibited combinations MUST be rejected with FORMERR and a response with such a combination is ignored.

Since SIGZERO RRs in a DNS message, as specified by this document, 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 such RRs in the message but they MUST occur after all other RR types in the Additional Information section except that a TSIG RR or a SIG(0) RR, if present, MUST be the very last RR in that section and do sign any SIGZEROs present. If one or more SIGZERO RRs are included in a DNS messages, an OPT RR MUST also be included.

See Section 6 for further details.

4.3. Indicating Support

Support for the SIGZERO RR is indicated by the SZ bit in the EDNS(0) OPT RR [RFC6891]. (See Section 10.3.)

[[[ If SIGZERO is changed to MSGSIG, the "SZ" would probably become "MS". ]]]

5. The SIG Zero Resource Records

The format of the SIGZERO and SIG(0) RRs are specified in the subsections below. All multi-byte 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.

5.1. SIGZERO RR Format

The fields of the SIGZERO Meta-RR are described below. Most of these fields are similar to or identical to the field in the TSIG [RFC8945] or RRSIG [RFC4034] RR with the 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 (ANY)      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       TTL (MUST be zero)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           RDLENGTH            |                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           RDATA               /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Overall SIGZERO RR Format
NAME:
The owner name of the KEY RR [KEYRR] holding the public key that should verify the signature. If there is no such KEY RR owner name then it is a name intended to identify the public key to the recipients of the RR.
TYPE:
This MUST be TBD [248 suggested].
CLASS:
This MUST be 255 (ANY, 0x00FF).
TTL:
The value of the TTL field MUST be zero and is ignored on receipt. This zero value minimizes the risk that a DNS implementation that does not understand SIGZERO will cache the RR.
RDLENGTH:
A 16-bit unsigned integer giving the length of the RDATA.
RDATA:
The RDATA for a SIGZERO RR consists of a number of fields as described below and shown in Figure 2. 
                     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          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Original Payload Size Limit  |            Error              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Fudge             |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         Time Signed
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Key Tag            |        Signature Size         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                           Signature                           /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Other Length          |                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           Other Data          /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SIGZERO RDATA Format
Algorithm:
The signature algorithm used. Values in this field have the same meaning as they do in the RRSIG RR [RFC4034] and use the same IANA registry [IANAalg]
Flags:
Flags as shown in Figure 3. (See also Section 8.)
Original ID:
An unsigned 16-bit integer holding the DNS message ID of the original message, that is, the message into which this SIGZERO is being inserted. When a SIGZERO RR is being forwarded as discussed in Section 8, the Original ID field is forwarded as received.
Original Payload Size Limit:
An unsigned 16-bit integer. This field holds the "requestor's UDP payload size" from the OPT [RFC6891] in the DNS message containing the SIGZERO. When a SIGZERO RR is being forwarded as discussed in Section 8, the Original Payload Size Limit field is forwarded as received.
Error:
In responses, an unsigned 16-bit integer containing the extended RCODE covering SIGZERO processing. In requests, this MUST be zero and is ignored on receipt.
Fudge:
An unsigned 16-bit integer specifying the allowed time difference in seconds permitted from the Time Signed field.
Time Signed:
An unsigned 48-bit integer containing the time the message was signed, that is the time the SIGZERO was added to the DNS message, as seconds since 00:00 on 1970-01-01 UTC, ignoring leap seconds.
Key Tag:
The Key Tag field contains the key tag value of the public key that is to be used to validate this signature. In the case of multiple possible KEY RRs, the Key Tag usually allows a heuristic reduction of the number of KEY RRs to try. Appendix B of [RFC4034] specifies how to calculate Key Tag values.
Signature Size:
A 16-bit unsigned integer giving the size of the Signature field in bytes.
Signature:
The Signature field contains the cryptographic signature that covers the DNS request or transaction. The format of this field depends on the algorithm in use, and these formats are described in separate companion documents referenced from the IANA registry [IANAalg]. The data covered by this signature is specified in Section 6.
Other Length:
An unsigned 16-bit integer specifying the length of the Other Data field in bytes. If it would be zero, this field MUST be omitted.
Other Data:
Additional data relevant to the SIGZERO record. For responses, if and only if the Error field above has the value BADTIME, this field begins with the 48-bit Time Signed in the request that provoked the BADTIME error. This document assigns no meaning to any information in this field in requests and assigns no meaning to additional information that might occur in responses.

The Time Signed and the Fudge form a time bracket, that is, the Time Signed plus or 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 not normally be more than 5 minutes.

5.1.1. SIGZERO RR Flags 

  0  1  2  3  4  5  6  7
+--+--+--+--+--+--+--+--+
| FW  |        Z        |
+--+--+--+--+--+--+--+--+
Figure 3: SIGZERO RR Flags Format

FW is a two-bit field related to SIGZERO forwarding. See Section 8 and Section 10.2.

Z is reserved for flags to be defined in the future. It MUST be sent as zero and ignored on receipt.

5.2. The SIG(0) RR Format

[[[ Should sections exclusively related to SIG(0), like the one here, be moved to an Appendix with some indication that there is an intent to deprecate SIG(0)? ]]]

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 (ANY)      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       TTL (MUST be zero)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           RDLENGTH            |                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            RDATA              /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SIG(0) RR Format

The type of the SIG RR is 24. The structure of a SIG(0) RDATA is shown in Figure 5.

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 byte). 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                          /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: SIG(0) RDATA Format from [RFC4034]
Type Covered:
MUST be zero, which is what makes the SIG RR a SIG(0).
Algorithm:
The signature algorithm used. Values in this field have the same meaning as they do in the RRSIG RR [RFC4034] and use the same IANA registry [IANAalg]
Labels:
Not used, MUST be zero.
Original TTL:
Not used, MUST be zero.
Signature Inception and Expiration:
These times in SIG(0)s are for the purpose of limiting replay attacks. They form a time bracket and messages received outside that bracket are ignored. In IP networks, this time bracket SHOULD NOT normally extend further than 5 minutes into the past or 5 minutes into the future from the time the SIG(0) is added to the DNS message.
Key Tag:
The Key Tag field contains the key tag value of the public key that is to be used to validate this signature. In the case of multiple possible KEY RRs, the Key Tag usually allows a heuristic reduction of the number of KEY RRs to try. Appendix B of [RFC4034] specifies how to calculate Key Tag values.
Signer's Name:
The owner name of the KEY RR [KEYRR] holding the public key that should verify the signature. If there is no such KEY RR owner name then, to avoid wasting bytes, this should be the name of the root, that is, a single zero byte.
Signature:
The Signature field contains the cryptographic signature that covers the DNS request or transaction. The format of this field depends on the algorithm in use, and these formats are described in separate companion documents referenced from the IANA registry [IANAalg]. The data signed is specified in Section 6.

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.

6. Calculating Request and Transaction SIG Zero RRs

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.

6.1. Calculating Request SIGZERO RRs

A DNS request may be optionally signed by including one or more SIGZERO RRs in the request's additional information section. These RRs are calculated for and sign the "data" consisting of the following:

  1. The uncompressed Owner Name of the SIGZERO RR with upper case US-ASCII letters [RFC20] replaced with the corresponding lower case letter.
  2. The RDATA of the SIGZERO RR with the Signature Size and Signature removed so the Other Length field, if present, immediately follows the Key Tag field, and the RDLENGTH adjusted for that removal.

  3. A third set of information consisting of the DNS request message but with one of the two following sets of modifications, depending on the state of the FW field in the SIGZERO as follows:

    3.a If the FW field in the SIGZERO is set to 0b00 (Section 8), the DNS request message before any TSIG or SIG Zero RRs have been added so that, for example, the RR counts have not yet been adjusted for TSIG and SIG Zero inclusion. Any OPT is signed without modification to that OPT.

    3.b If the FW field is 0b10 or 0b11 (Section 8), the DNS request message, including the DNS header without TSIG, TKEY, and SIG Zero RRs, so the RR counts and RDLENGTH do not include such Meta-RR inclusion, and with any OPT RR adjusted as in Section 8.1.

That is

data = (SIGZERO RR's canonicalized Owner Name) |
       (SIGZERO RRDATA without Signature Size and Signature) |
       If FW.eq.0 (request message without TSIG and SIG Zero RRs)
       Else (request message without TSIG, TKEY, and SIG Zero RRs
             and with any OPT RR adjusted)

where "|" is concatenation.

Note that when a SIGZERO is being calculated for a DNS message, the Original ID field in the SIGZERO and the ID field in the message's DNS header will be the same and the Original Payload Size Limit field in the SIGZERO will be the same as the "requestor's UDP payload size" the OPT in the message.

6.2. Calculating Request SIG(0) RRs

A DNS request may be optionally signed by including a single SIG(0) RR in the request's additional information section. This RR is calculated for and signs the "data" consisting of the following:

  1. The SIG(0)'s RDATA section completely omitting the signature subfield itself, not just zeroing its value.
  2. The DNS request message, including DNS header, but not any earlier headers such as UDP/IP headers and before the SIG(0) RR has been added so that, for example, the RR counts have not yet been adjusted for SIG(0) inclusion.

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. If a SIG(0) is being included, the inclusion of a TSIG is prohibited.

Special care must be taken, as described in Section 8.2 for a SIG(0) request signature to work with forwarding.

6.3. Calculating Transaction SIGZERO RRs

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:

  1. The uncompressed Owner Name of the SIGZERO RR with upper case US-ASCII letters [RFC20] replaced with the corresponding lower case letter.
  2. The RDATA of the SIGZERO RR with the Signature Size and Signature removed so the Other Length field, if present, immediately follows the Key Tag field, and the RDLENGTH adjusted for that removal. The Original ID field is set to the ID of the response message and the Original Payload Size Limit is set to the UDP payload size from the OPT.

  3. A third set of information consisting of the DNS request message that produced this response followed by the response message being signed all with one of the following modifications depending on the state of the FW flag bits in SIGZERO being calculated:

    3.a If the FW field in the SIGZERO being created is set to 0b00 Section 8, the DNS request message with any TSIG or SIG Zero RRs removed and the counts adjusted for that removal followed by the DNS response message being created before any TSIG or SIG Zero RRs are added.

    3.b If the FW field is 0b10 or 0b11 (see Section 8), the request message with any TSIG, TKEY, or SIG Zero RRs removed and with the OPT RR adjusted as in Section 8.1 followed by the response message being created before any TSIG, TKEY, or SIG Zeros have been added and with the OPT RR adjusted as in Section 8.1.

data = (SIGZERO RR's canonicalized Owner Name) |
       (SIGZERO RRDATA without Signature Size and Signature) |
       If FW.eq.0 (request message followed by response message
                   both without TSIG and SIG Zero RRs)
       Else (request message followed by response message both
             without any TSIG, TKEY, or SIG Zeros and both with
             OPT RR adjusted)

where "|" is concatenation.

It is RECOMMENDED that the FW field in a transaction SIGZERO be set to 0b11 if it is in response to a request that has a SIGZERO with the FW field equal to 0b10 or 0b11.

With appropriate configuration, successful verification of a response SIGZERO cryptographically confirms that the signed parts of request and response were not tampered with in transit, that the response corresponds to the intended request, and that the response comes from the queried server.

6.4. Calculating Transaction SIG(0) RRs

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 for and signs the "data" consisting of the following:

  1. For the SIG(0), the RDATA section omitting (not just zeroing) the signature itself.
  2. The DNS request message that produced this response, including the request's DNS header but not any preceding headers such as UDP or IP.
  3. The DNS response message, including DNS header but not any preceding headers such as TCP or IP, and before the SIG(0) has been added so that, for example, the response RR counts have not yet been adjusted for such inclusion. 
data = (SIG(0) RDATA omitting signature) |
       (request message) |
       (response message before SIG(0) added)

where "|" is concatenation and RDATA is the RDATA of a SIG(0) being calculated omitting the signature itself. Note that if a SIG(0) is being included, the inclusion of a TSIG is prohibited.

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.

Special care must be taken, as described in Section 8.2 for a SIG(0) transaction signature to work with forwarding.

6.5. SIG Zeros on Streaming Connections

A DNS TCP or other stream transport session, such as a zone transfer, can include multiple DNS messages. Using a SIG Zero on such a connection can protect the connection from an attack and provide data integrity. A SIG Zero on the first message is calculated as above but using data only from that message. For each subsequent message, it is calculated as below.

For SIGZERO:

Assume the previous message has a SIGZERO with signer name n1 which we will call SIGZn1. Set the FW field of the SIGZERO being calculated to the FW field of SIGZn1.

data = (SIGZERO RR's canonicalized Owner Name) |
       (SIGZERO RRDATA without Signature Size and Signature) |
       (previous message's SIGZERO RRDATA with Signature Size
         and Signature) |
       If FW.eq.0 (current message without TSIG and
                   SIG Zero RRs)
       Else (current message without any TSIG, TKEY, or SIG
             Zeros and with OPT RR adjusted)

For SIG(0):

data =  (SIG(0) RDATA omitting signature ) |
        (previous message)

Where, in both of the above, "|" is concatenation and previous message is the previous DNS message including DNS header but not any preceding headers such as TCP or IP.

7. Processing Received Requests and Responses

Except where needed to authenticate an Update, TKEY, SRP registration or similar request by the final server, servers MAY verify a request SIG Zero depending on local policy but are not required to do so.

If one or more SIG Zero RRs are at the end of the additional information section of a response message, they are transaction signatures covering the response and the request that produced that response. Requesters MAY verify a transaction SIG Zero depending on local policy but are not hereby required to do so.

If the time when a SIGZERO on a request is received is outside the interval indicated by the Time Signed and Fudge, the BADTIME error is returned for that SIGZERO. If this applies to a response, that SIGZERO is considered to fail verification.

When a request SIGZERO is being verified, the Original ID field in the SIGZERO is substituted for the ID field in the DNS header of the request message containing that SIGZERO. When a transaction SIGZERO is being verified, the Original ID field in the SIGZERO is substituted for the ID field in the DNS header of the saved copy of the DNS request message and the DNS header of the response message. There MUST be an OPT RR in the message and, for verification, the Original Payload Size Limit field in the SIGZERO is substituted for the UDP payload size field in the OPT. See Appendix C for an example.

If the SIG Zero check on the response to a DNS Query request 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 DNS message has multiple SIG Zero RRs and possibly also one TSIG and verification of some succeeds and the others fail, the appropriate action is dependent on local policy and configuration.

8. Considerations for Forwarding Servers

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 one or more SIG Zero RRs should be sent directly to the final server that will verify those SIG Zeros. If it is operationally required that they be forwarded, they should be forwarded through the minimum number of forwarders practical.

If a DNS message arrives with a SIG Zero for which the receiving DNS server does not have a verification key, but the message does not have other errors, then it SHOULD be forwarded with that SIG Zero unless it is a SIGZERO with FW equal to 0b00 in which case that SIGZERO is considered to have failed verification. Any SIGZERO (which will have FW equal to 0b10 or 0b11) or SIG(0) which is forwarded MUST be forwarded unchanged.

If a DNS message arrives with a SIG Zero for which the receiving DNS server has a verification, but verification fails, the treatment of the message depends on local policy. There may be other SIG Zero of TSIGs that succeed in verification. A failed SIGZERO is only forwarded if the message is forwarded and the SIGZERO's FW field has the value 0b11.

The principal case for forwarding DNS requests and responses is DNS Update. (A DNS Query sent to a recursive server is not forwarded as such but rather may result in one or more new queries being sent by that recursive server in its attempts to obtain the information needed to satisfy the original query.)

A server which implements SIGZERO and is acting as a forwarding server for a DNS message such as an SRP registration or general Update, MUST check for the existence of SIG Zero RRs. Forwarding of a SIGZERO is determined from the FW field in that SIGZERO's RDATA as follows:

Table 1
FW Value Meaning
0b00 Never forward this SIGZERO RR.
0b01 Invalid. Report as FORMERR for that SIGZERO.
0b10 If forwarding, include this SIGZERO if and only if the forwarder does not have a key to verify the SIG Zero RR.
0b11 If forwarding, always include this SIGZERO.

If a server needs to forward a request containing one or more SIGZERO RRs, it MUST forward the SIGZERO RR if either the FW field value of the RR is 0b10 and the forwarder does not have access to a key to verify the SIGZERO or if the FW value is 0b11. If the SIGZERO'S FW field is 0b00 the forwarding server MUST remove it. For SIG(0), it is removed if the forwarder doesn't have access to a key to verify it; otherwise it is forwarded.

When one or more SIG Zeros are removed from a forwarded DNS message then, if possible, the forwarding server SHOULD add a TSIG or 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 TSIG or SIG Zero to the response and then returning the result to the source from which it received the request.

8.1. OPT RR Forwarding Considerations and [RFC6891] Update

If a DNS message being forwarded was received with an OPT RR, the forwarded message MUST include a OPT RR with the same OPT Extended-RCODE, Version, and Flags. If the received message had one or more SIGZERO RRs, then the UDP payload size of the OPT in the forwarded message SHOULD be less than or equal to the minimum Original Payload Size Limit in the received SIGZEROs.

The OPT Meta-RR [RFC6891] provides a number of extensions to the DNS Header and can carry a variable number of type-length-value encoded options. [RFC6891], which prohibits forwarding of OPT, is hereby updated (see Appendix B) to provide that an OPT RR with a DNS Update message MUST be forwarded for reasons including the following if the DNS message carrying the OPT is forwarded:

  • The Update Lease Option (#2) is used in connection with SRP and would be unavailable if it were not forwarded with a forwarded SRP Update message.
  • [[[ Are there any other currently defined OPT RR options that need to be forwarded? ]]]
  • An OPT with an Update response might have an extended RCODE which should be conveyed back to the requester.

When an OPT RR is forwarded, all received options except the Update Lease Option and any options with option number between 55001 and 65000 or between 65301 and 65534 are removed (see Section 10.4). Thus, all options with codes from 1 to 26, except the Update Lease Option, are removed. The forwarder can add new non-forwardable options for the next DNS hop. Option code ranges are specified in Section 10.4 so new options may be conveniently specified in the future as either forwardable or not forwardable.

8.2. Forwarding SIG(0) RRs

There are difficulties in forwarding a DNS message with a SIG(0) in it because the server needs access to the original ID which is not carried by SIG(0). However, it can be done by, for example, (1) always using TCP for DNS messages with a SIG(0), and (2) using a separate ID number space for each DNS TCP connection, and (3) using the same ID in the forwarded message as the ID appearing in the received message when forwarding a DNS message with as SIG(0). (This technique is used by the BIND DNS implementation.)

9. Security Considerations

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.

Use of public key SIG Zero RRs on queries are a possible denial of service attack path due to the effort required for signature verification and KEY RR lookup. As always, DNS servers should limit the effort they will expend on processing a request.

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. Nevertheless, DNS messages can be replayed within the time window specified and SIG Zero RRs (and any TSIG RR present) will still verify.

An intervening adversary can remove TSIG and/or SIG Zero RRs and could clear the SZ bit for an attempted downgrade attack. Local policy requiring signatures can defeat such an attack. Requiring a valid transaction signature before trusting a response provides significant assurance. In the absence of a transaction signature, then trust is being placed in any intervening forwarder between a requester and a server.

A SIGZERO with FW equal to 0b10 or 0b11 does not protect non-forwardable options or the OPT UDP size limit field.

For the strong security assurance in the case of a forwarded request, a one hop signature should be used on each hop and a transaction signature included with the result. For example, a TSIG between the requester and forwarder, a TSIG between the forwarder and server, and a SIGZERO transaction signature on the response.

10. IANA Considerations

The following subsections give requested IANA actions all of which affect the DNS Parameters registry group.

10.1. SIGZERO RR Type Number

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:

Table 2
TYPE Value Meaning Reference
SIGZERO TBD Public key request or transaction signature. [this document]

10.2. SIGZERO Flag Bits Registry

IANA is requested to create a registry in the Domain Name System (DNS) Registry Group as follows:

    Registry: SIGZERO RR Flags
    Registration Procedure: IETF Review
    Reference:  [this document]
Table 3
Bit(s) Name Description Reference
0-1 FW Forwarding enable [this document]
2-7 - unassigned [this document]

10.3. SIGZERO Support EDNS OPT Bit

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:

Table 4
Bit Flag Description Reference
TBD2 SZ SIGZERO supported [this document]

10.4. EDNS0 Option Codes Table Update

IANA is requested to make the following changes to the DNS EDNS0 Option Codes (OPT) registry:

Add [this document] to the Reference for the registry.

The initial Registration Procedures table is changed to the following:

Table 5
Range Registration Procedures
1-65000 Expert Review
65001-65300 Local/Experimental Use, Not Forwarded
65301-65534 Local/Experimental Use, Forwardable

The table of option values is unchanged except that some lines are updated and/or split as follows:

Table 6
Value Name Status Reference
27-20291 unassigned, not forwardable RFC 6891, [this document]
20293-26945 unassigned, not forwardable RFC 6891, [this document]
26947-55000 unassigned, not forwardable RFC 6891, [this document]
55001-65000 unassigned forwardable RFC 6891, [this document]
65001-65300 Reserved for Local/Experimental Use, Not Forwarded RFC 6891, [this document]
65301-65534 Local/Experimental Use, Forwardable RFC 6891, [this document]

[[[ Should a column for "Forwardable" be added to the Option Codes table? ]]]

11. References

11.1. Normative References

[RFC20]
Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC20, , <https://www.rfc-editor.org/info/rfc20>.
[RFC1035]
Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, , <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[KEYRR]
Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, DOI 10.17487/RFC2535, , <https://www.rfc-editor.org/info/rfc2535>.
Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource Record (RR)", RFC 3445, DOI 10.17487/RFC3445, , <https://www.rfc-editor.org/info/rfc3445>.
[RFC4034]
Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, , <https://www.rfc-editor.org/info/rfc4034>.
[RFC4035]
Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, , <https://www.rfc-editor.org/info/rfc4035>.
[RFC6891]
Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, , <https://www.rfc-editor.org/info/rfc6891>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8945]
Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D., Gudmundsson, O., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", STD 93, RFC 8945, DOI 10.17487/RFC8945, , <https://www.rfc-editor.org/info/rfc8945>.

11.2. Informative References

[IANAalg]
IANA, "DNS Security Algorithm Numbers", <https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml>.
[DNSparams]
IANA, "Domain Name System (DNS) Parameters", <https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml>.
[rfc2930bis]
Eastlake, D. and M. Andrews, "Secret Key Agreement for DNS (TKEY Resource Record)", Work in Progress, <https://datatracker.ietf.org/doc/draft-eastlake-dnsop-rfc2930bis-tkey/>.
[RFC2931]
Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, , <https://www.rfc-editor.org/info/rfc2931>.
[RFC3007]
Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, DOI 10.17487/RFC3007, , <https://www.rfc-editor.org/info/rfc3007>.
[RFC9499]
Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, , <https://www.rfc-editor.org/info/rfc9499>.
[RFC9665]
Lemon, T. and S. Cheshire, "Service Registration Protocol for DNS-Based Service Discovery", RFC 9665, DOI 10.17487/RFC9665, , <https://www.rfc-editor.org/info/rfc9665>.

Appendix A. SIGZERO RRTYPE Assignment Application 

   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 with type covered of zero (RFC 2931). 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?
      Creates a new registry for SIGZERO Flags and requests
      assignment of a DNS RRTYPE and DNS EDNS flag bit.

   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

Appendix B. Changes to [RFC6891]

The OPT RR MUST be forwarded if it is in a DNS message that is being forwarded as provided in Section 8.1.

The DNS EDNS0 Option Codes (OPT) registry in the IANA DNS Parameters group is updated as specified in Section 10.4.

Appendix C. SIGZERO Transaction Example

This is an example of a request with a request SIGZERO and OPT RR that is forwarded and then responded to with a transaction SIGZERO on the response. Some details are omitted.

  Requester sends message REQ1 as follows:
  - DNS header with ID = id1
  - body of request
  - OPT RR with UDP size limit us1
  - request SIGZERO including Original ID = id1 and Original
      Payload Size Limit = us1
  - (possibly with other SIG Zeros and/or a TSIG)

The REQ1 requester SIGZERO has FW equal to 0b10 or 0b11 and is calculated over the SIGZERO with Original ID set to id1 and Original Payload Size Limit set to us1 and over the DNS header, request message body, and OPT with only forwardable option in the OPT, and without any TSIG or SIG Zeros.

  Forwarder receives REQ1 and forwards message REQ2 as follows:
  - DNS Header with ID = id2
  - unmodified body of request
  - OPT RR with UDP size limit us2
  - unmodified request SIGZERO as above
  - (possibly with other SIG Zeros and/or a TSIG)

The forwarder will set us2 to be less than or equal to us1. Any forwardable OPT options in the incoming OPT are included unchanged in the outgoing OPT. The original requester SIGZERO is forwarded as part of REQ2; it is included without change.

The server receives REQ2 with the forwarded SIGZERO and verifies that SIGZERO over the DNS Header with id1 substituted for id2 in the ID field, the request message body, and the OPT with only forwardable options and with Original Payload Size Limit of us1 substituted for UDP size limit. The server is informed of the minimum of the requestor and forwarder UDP size limits (us2) by the UDP size limit field of the OPT RR in the forwarded request. It then calculates a response as below.

  Server sends message RSP1 as follows:
  - DNS Header with ID = id2
  - body of response
  - OPT RR with UDP size limit of us3
  - response SIGZERO including Original ID = id2
  - (possibly with other SIG Zeros and/or a TSIG)

The response SIGZERO is calculated over (1) the SIGZERO with Original ID set to id2 and Original Payload Size Limit set to us3, (2) the forwarded request message with DNS Header ID set to id2, non-forwardable options removed from the OPT, and any TSIG, TKEY, and SIG Zeros removed, and (3) the response message body including DNS Header with ID = id2, and (4) the response OPT without non-forwardable options. (NOTE: It might seem that item 2 should set the DNS Header ID to id1 in the forwarded request but that would only be possible if there was a request SIGZERO as assumed in this example. If there was a forwarded request with no request SIGZERO, then id1 would not generally be available to the server and therefore could not be used in calculating a response transaction SIGZERO.)

Forwarder receives message RSP1 and matches it to REQ1 by the header ID id2 as usual.

  The forwarder then sends message RSP2 with the response
  transaction SIGZERO as follows:
  - DNS Header with ID = id1
  - body of response
  - OPT RR with UDP size limit of us4
  - unmodified response SIGZERO as above
  - (possibly with other SIG Zeros and/or a TSIG)

The forwarder will set us4 to be less than or equal to us3. Any forwardable OPT options in the incoming OPT are included unchanged in the outgoing OPT.

The original requester matches message RSP2 with REQ1 by the header ID id1 as usual. It then verifies RSP2 over the following:

  1. the normalized Owner Name of the response SIGZERO,
  2. the response SIGZERO body with the Signature and Signature Size removed,
  3. its saved copy of the original request DNS header but with the DNS Header ID set to id2, which it obtains from the Original ID field of the RSP2 response SIGZERO,
  4. its saved copy of the original request message body without TSIG, TKEY, or SIG Zeros and with the OPT RR adjusted including setting the UDP size limit to the Original Payload Size Limit field of the response SIGZERO and removing any non-forwardable options, and
  5. the response message with the same modification as made to the request in the two points immediately above.

The UDP size limit field of the OPT RR in RSP2 (us4) informs the requestor of the minimum UDP size limit of the forwarder and the server.

Appendix D. Change History

RFC Editor: Please delete this section before publication.

Note: This draft was initially targeted to the DNSOP WG but, after discussion with the Chairs and draft authors, was re-targeted to the DNSSD WG.

D.1. From [RFC2931] to dnsop-00

  1. Change to require KEY RRs used in connection with SIG(0) to have a protocol byte of 255 (ANY). ([RFC2931] also permits a protocol byte of 3.
  2. Change implementation requirement for the TTL and CLASS field of SIG(0) RRs from SHOULD be zero and 255, respectively, to MUST have those values and are ignored on receipt.
  3. Add section on considerations for forwarding servers.
  4. Remove statement that TCP support for SIG(0) is OPTIONAL.
  5. Specify an EDNS option to convey the original ID and return an extended error code.
  6. Editorial changes including updates to meet current Internet draft format requirements. Update references. Convert source to XMLv3.

D.2. From dnsop-00 to dnsop-01

  1. Add section on error return via EDNS and add IANA request for an EDNS OPT number.
  2. Clarify that a SIG(0) public key can be associated with a zone or otherwise indicate authorization.
  3. Add author.
  4. Editorial Changes.

D.3. From dnsop-01 to dnsop-02

  1. Permit multiple SIG(0)s.
  2. Back out change requiring protocol 255 in SIG(0)s and again permit protocol 3 or 255.
  3. Add reference to SIG(0) usage in SRP (Service Registration Protocol).
  4. Editorial changes.

D.4. From dnsop-02 to dnsop-03

  1. Generalize TCP references to include mentions of other stream protocols.
  2. Update reference to DNSSD SRP from draft to [RFC9665].
  3. Editorial changes.

D.5. From dnsop-03 to dnssd-00

  1. Change to specify a new RR (SIGZERO) patterned more like TSIG. Drop EDNS(0) stuff.
  2. Add paragraph suggesting the avoidance of forwarding servers where practical to eliminate a potential point of failure.
  3. Add paragraph about Time Signed and Fudge for SIGZERO specifying a time interval similar to the Inception and Expiration times for SIG(0).
  4. Omit request SIGZEROs from data for response SIGZERO to avoid breaking transaction security if a forwarder, for example, adds a second SIGZERO.
  5. Numerous editorial changes.

D.6. From dnssd-00 to dnssd-01

  1. Correct intended status to Standards Track from Informational.
  2. Note that passage through a forwarding server may also be a potential point of compromise.
  3. Soften assertions of "assurance" to "increase confidence".
  4. Minor editorial changes.

D.7. From dnssd-01 to dnssd-02

  1. Add an EDNS(0) OPT bit to announce support of SIGZERO.
  2. Allow a TSIG with one or more SIGZEROs.
  3. Provide that the Other Length field in a SIGZERO SHOULD be omitted if its value would be zero.
  4. Eliminate key state from SIGZERO since it has nothing to do with the needed signature data, just the KEY RR.
  5. Editorial changes.

D.8. From dnssd-02 to dnssd-03

  1. Add the FW two-bit field in the SIGZERO Flags field and specify its use.
  2. Slightly liberalize the message inclusion rules by allowing a SIG(0) with one or more SIGZEROs.
  3. Numerous editorial improvements and a correction.

D.9. From dnssd-03 to dnssd-04

There are major changes between -03 and -04 as follows:

  1. Numerous changes in Section 6 on how SIG Zeros are calculated.
  2. Add numerous provisions on OPT forwarding and update [RFC6891] to allow forwarding of some options and distinguish these in the IANA OPT Option Codes table
  3. Many improvement to considerations for forwarding servers. Specify that a value of 0b10 in the FW two-bit subfield of the SIGZERO Flags field is reported as a FORMERR for that SIGZERO. Note that principally DNS Update messages are actually forwarded. See Section 8. This makes the provision for conditionally clearing the AD flag a no-op.
  4. Several changes to clarify processing when a DNS message has both a TSIG or SIG(0) and one or more SIGZEROs. The TSIG or SIG(0), only one of which can occur, will always be last in the Additional Information section.
  5. Fix up wording of Section 6.5 to be similar to [RFC8945].
  6. Expanded Security Considerations Section.
  7. Numerous editorial improvements and corrections.

Acknowledgements

The comments and suggestions of the following are gratefully acknowledged:

Stuart Cheshire, Tim Wicinski

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.

Authors' Addresses

Donald E. Eastlake 3rd
Independent
2386 Panoramic Circle
Apopka, Florida 32703
United States of America
Johan Stenstam
Swedish Internet Foundation
Mark Andrews
Internet Systems Consortium
PO Box 360
Newmarket, NH 03857
United States of America