Internet-Draft DNS MSGSIG and SIG(0) RRs October 2026
Eastlake, et al. Expires 3 May 2027 [Page]
Workgroup:
DNSSD
Internet-Draft:
draft-eastlake-dnssd-rfc2931bis-sigzero-05
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 (MSGSIG, SIG(0))

Abstract

This document specifies the MSGSIG and SIG(0) Domain Name System (DNS) Resource Records (RRs) which provide public key based authentication of DNS requests and transactions. MSGSIG 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 3 May 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) MSGSIG and SIG(0) Resource Records (RRs) which provide public key based authentication of DNS requests and transactions. MSGSIG is patterned after the TSIG [RFC8945] and RRSIG [RFC4034] RRs. Use of MSGSIG 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.

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

2. Terminology

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 MSGSIG and SIG(0) 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, MSGSIG 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 MSGSIG and SIG(0) 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 MSGSIG or SIG(0) 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 MSGSIG or SIG(0) 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 MSGSIG or SIG(0) 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, MSGSIG, 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.

MSGSIG 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 MSGSIG 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 public key which can itself be an expensive operation. Indeed, a policy of using a MSGSIG or SIG(0) on all requests and verifying it before responding would, for some configurations, lead to a circular dependency starting with the attempt to obtain and verify the key needed to authenticate the request. This would result in additional requests accompanied by a MSGSIG or SIG(0) leading to further requests accompanied by a MSGSIG 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 MSGSIG or SIG(0) RR SHOULD only be used on requests when necessary to authenticate that the requester has some required privilege or identity. A MSGSIG or SIG(0) on transactions is defined in such a way as to not require that the corresponding request be signed and still provide transaction protection.

Which MSGSIG or SIG(0) RRs are required to be authenticated by a server or requester should be a local configuration option.

4.1. Why MSGSIG Is Preferred Over SIG(0)

The MSGSIG 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. 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. MSGSIG 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 MSGSIG signature. MSGSIG has a dedicated field for this value (as does the TSIG RR). (See Section 8.)
  3. There is no convenient way to extend SIG(0) while MSGSIG 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, MSGSIGs, 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 MSGSIG 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. Such a final TSIG or SIG(0) does sign any MSGSIGs present. If one or more MSGSIG 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 MSGSIG RR is indicated by the MS bit in the EDNS(0) OPT RR [RFC6891]. (See Section 10.3.)

5. The MSGSIG and SIG(0) Resource Records

The format of the MSGSIG 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 MSGSIG or SIG(0) authentication on a response is desired, the MSGSIG or SIG(0) RRs MUST be considered the highest priority of any additional information for inclusion in the response. If they cannot be added without causing the message to be truncated, the server MUST alter the response so that at least one MSGSIG or SIG(0) 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. MSGSIG RR Format

The fields of the MSGSIG 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 MSGSIG 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 MSGSIG will cache the RR.
RDLENGTH:
A 16-bit unsigned integer giving the length of the RDATA.
RDATA:
The RDATA for a MSGSIG 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: MSGSIG 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 MSGSIG is being inserted. When a MSGSIG 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 into which the MSGSIG is being inserted. When a MSGSIG 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 MSGSIG 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 MSGSIG 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 MSGSIG 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 further 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. MSGSIG RR Flags 

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

FW is a two-bit field related to MSGSIG 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 MSGSIG RR, there is no significance to their order and a MSGSIG RR does not sign any other MSGSIG RR in that DNS message.

6.1. Calculating Request MSGSIG RRs

A DNS request may be optionally signed by including one or more MSGSIG 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 MSGSIG RR with upper case US-ASCII letters [RFC20] replaced with the corresponding lower case letter.
  2. The RDATA of the MSGSIG 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 MSGSIG as follows:

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

    3.b If the FW field is 0b10 or 0b11 (Section 8), the DNS request message, including the DNS header without MSGSIG, TSIG, or SIG(0) 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 = (MSGSIG RR's canonicalized Owner Name) |
       (MSGSIG RRDATA without Signature Size and Signature) |
       If FW.eq.0 (request message without MSGSIG, TSIG, or
                   SIG(0) RRs)
       Else (request message without MSGSIG, TSIG, or SIG(0)
             RRs and with any OPT RR adjusted)

where "|" is concatenation.

Note that when a MSGSIG is being calculated for a DNS message, the Original ID field in the MSGSIG and the ID field in the message's DNS header will be the same and the Original Payload Size Limit field in the MSGSIG will be the same as the "requestor's UDP payload size" in 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 MSGSIG RRs

A MSGSIG can be used to secure a transaction consisting of a response and the request that produced it. Such a transaction signature MSGSIG, to be included in the response, signs and is calculated over data consisting of the following:

  1. The uncompressed Owner Name of the MSGSIG RR with upper case US-ASCII letters [RFC20] replaced with the corresponding lower case letter.
  2. The RDATA of the MSGSIG 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 each with one of the following modifications depending on the state of the FW flag bits in MSGSIG being calculated:

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

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

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

where "|" is concatenation.

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

With appropriate configuration, successful verification of a response MSGSIG 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. MSGSIG and SIG(0) on Streaming Connections

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

For MSGSIG:

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

data = (MSGSIG RR's canonicalized Owner Name) |
       (MSGSIG RRDATA without Signature Size and Signature) |
       (previous message's MSGSIG RRDATA with Signature Size
        and Signature) |
       If FW.eq.0 (current message without MSGSIG, TSIG, or
                   SIG(0) RRs)
       Else (current message without any MSGSIG, TSIG, or
             SIG(0) 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 MSGSIG RRs and/or a SIG(0) RR 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 MSGSIG or SIG(0) depending on local policy but are not hereby required to do so.

If the time when a MSGSIG is received is outside the interval indicated by its Time Signed and Fudge, the BADTIME error is returned for that MSGSIG. The MSGSIG is considered to fail verification. If the time when a SIG(0) is received is outside the time interval indicated by its Signature Inception and Expiration times, the BADTIME error is returned. The SIG(0) is considered to fail verification.

When a request MSGSIG is being verified, the Original ID field in the MSGSIG is substituted for the ID field in the DNS header of the request message containing that MSGSIG. When a transaction MSGSIG is being verified, the Original ID field in the MSGSIG 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 MSGSIG is substituted for the UDP payload size field in the OPT. See Appendix C for an example.

If the MSGSIG or SIG(0) 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 DNS message has multiple MSGSIG, TSIG, or SIG(0) 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 MSGSIG, TSIG, or SIG(0) RRs should be sent directly to the final server that will verify those RRs. 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 MSGSIG or SIG(0) 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 MSGSIG or SIG(0) unless it is a MSGSIG with FW equal to 0b00 in which case that MSGSIG is considered to have failed verification. Any MSGSIG (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 MSGSIG or SIG(0) for which the receiving DNS server has a verification key, but verification fails, the treatment of the message depends on local policy. There may be other MSGSIG, SIG(0), or TSIGs that succeed in verification. A failed MSGSIG is only forwarded if the message is forwarded and the MSGSIG's FW field has the value 0b11.

The principal cases for forwarding DNS requests and responses are DNS Update and TKEY operations. (A DNS data 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. However, TKEY operations, which are formatted as a Query for type TKEY, may be forwarded.)

A server which implements MSGSIG 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 MSGSIG and SIG(0) RRs. Forwarding of a MSGSIG is determined from the FW field in that MSGSIG's RDATA as follows:

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

If a server needs to forward a request containing one or more MSGSIG RRs, it MUST forward the MSGSIG 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 MSGSIG or if the FW value is 0b11. If the MSGSIG'S FW field is 0b00 the forwarding server MUST remove it. For SIG(0), it is removed if the forwarder has a key to verify it; otherwise it is forwarded unchanged.

When one or more MSGSIGs and/or a SIG(0) are removed from a forwarded DNS message then, if possible, the forwarding server SHOULD add a TSIG, MSGSIG, or SIG(0) of its own to the destination or the next forwarder.

8.1. OPT RR Forwarding Considerations and [RFC6891] Update

If a DNS message that will or might be 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 MSGSIG 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 MSGSIGs.

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 in a DNS message being forwarded (see Section 8) MUST be forwarded for reasons including the following:

  • 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, and options 20292 and 26946 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 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 MSGSIG and SIG(0) 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 MSGSIG or SIG(0) 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 any message.

The inclusion of the SIG(0) Inception and Expiration Time and the MSGSIG Time Signed and Fudge under the signature improves resistance to replay attacks. Nevertheless, DNS messages can be replayed within the time window specified and MSGSIG and SIG(0) RRs (and any TSIG RR present) will still verify.

An intervening adversary can remove TSIG and/or MSGSIG or SIG(0) RRs and could clear the MS 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 MSGSIG with FW equal to 0b10 or 0b11 does not protect non-forwardable options or the OPT UDP size limit field.

For the strongest 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 MSGSIG 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. MSGSIG RR Type Number

IANA is requested to assign a MSGSIG 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
MSGSIG TBD Public key request or transaction signature [this document]

10.2. MSGSIG Flag Bits Registry

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

    Registry: MSGSIG 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. MSGSIG 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 MS MSGSIG supported [this document]

10.4. EDNS0 Option Codes Table Update

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

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

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

  3. 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]

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. MSGSIG 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)?
     MSGSIG

  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 MSGSIG 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. MSGSIG Transaction Example

This is an example of a request with a request MSGSIG and OPT RR that is forwarded and then responded to with a transaction MSGSIG 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 MSGSIG including Original ID = id1 and Original
      Payload Size Limit = us1
  - (possibly with other SIG Zeros and/or a TSIG)

The REQ1 requester MSGSIG has FW equal to 0b10 or 0b11 and is calculated over the MSGSIG 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 options in the OPT, and without any TSIG, MSGSIG, or SIG(0).

  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 MSGSIG as above
  - (possibly with other MSGSIGs, SIG(0), 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 MSGSIG is forwarded as part of REQ2; it is included without change.

The server receives REQ2 with the forwarded MSGSIG and verifies that MSGSIG 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 MSGSIG including Original ID = id2
  - (possibly with other MSGSIGs, SIG(0), and/or a TSIG)

The response MSGSIG is calculated over (1) the MSGSIG 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, MSGSIG, and SIG(0)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 MSGSIG as assumed in this example. If there was a forwarded request with no request MSGSIG, then id1 would not generally be available to the server and therefore could not be used in calculating a response transaction MSGSIG.)

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 MSGSIG as follows:
  - DNS Header with ID = id1
  - body of response
  - OPT RR with UDP size limit of us4
  - unmodified response MSGSIG as above
  - (possibly with other MSGSIGs, SIG(0), 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 MSGSIG,
  2. the response MSGSIG 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 MSGSIG,
  4. its saved copy of the original request message body without TSIG, MSGSIGs, or SIG(0) and with the OPT RR adjusted including setting the UDP size limit to the Original Payload Size Limit field of the response MSGSIG 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 improvements to considerations for forwarding servers. Specify that a value of 0b01 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.

D.10. From dnssd-04 to dnssd-05

  1. Change the mnemonic for the new RR from "SIGZERO" to "MSGSIG".
  2. Clarify that while Queries are not normally forwardable, a Query for the meta-type TKEY is different and is forwardable.
  3. Since the AD flag is not used by Update or TKEY operations, remove the requirement that a forwrding server clear it in responses if it cannot provide TSIG, MSGSIG, or SIG(0) security to the final/next server.
  4. 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
Sweden
Mark Andrews
Internet Systems Consortium
PO Box 360
Newmarket, NH 03857
United States of America