RFC 2931

RFC 2931: DNS Request and Transaction Signatures ( SIG(0)s ) 💖🦋

Network Working Group, Request for Comments 2931. Author: D. Eastlake 3rd, Motorola. Category: Standards Track. Date: September 2000. This one updates 2535 (RFC 2535) ✨

---

Status of this Memo ✨

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. 🌸

Copyright Notice 🎀

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract 💅

Okay so, [RFC 2535] describes extensions to the Domain Name System (DNS) that can give security-aware resolvers and applications data origin and transaction integrity and authentication, using cryptographic digital signatures. 🔐

Implementation experience has shown that we need some minor changes that are not interoperable, in Request and Transaction signature resource records ( SIG(0)s ). Those changes are written up in this document. 🍓

Acknowledgments 🫶

The contributions and suggestions of the following persons (in alphabetic order) to this memo are gratefully acknowledged:

Olafur Gudmundsson 💜

Ed Lewis 💜

Erik Nordmark 💜

Brian Wellington 💜

Table of Contents 🧚

1. Introduction.................................................  2
2. SIG(0) Design Rationale......................................  3
2.1 Transaction Authentication..................................  3
2.2 Request Authentication......................................  3
2.3 Keying......................................................  3
2.4 Differences Between TSIG and SIG(0).........................  4
3. The SIG(0) Resource Record...................................  4
3.1 Calculating Request and Transaction SIGs....................  5
3.2 Processing Responses and SIG(0) RRs.........................  6
3.3 SIG(0) Lifetime and Expiration..............................  7
4. Security Considerations......................................  7
5. IANA Considerations..........................................  7
References......................................................  7
Author's Address................................................  8
Appendix: SIG(0) Changes from RFC 2535..........................  9
Full Copyright Statement........................................ 10

---

1. Introduction 🌈

This document makes minor changes to part of [RFC 2535], which it assumes you already know, and it adds extra explanatory text. The changes are not interoperable, so pay attention, bestie 🙈. They concern SIG Resource Records (RRs) that are used to digitally sign DNS requests and transactions / responses. Because such a resource record has a type covered field of zero, people often call it a SIG(0). ✨ The changes are based on implementation and attempted implementation experience with TSIG [RFC 2845] and the [RFC 2535] specification for SIG(0).

The sections of [RFC 2535] that get updated are all of 4.1.8.1 and parts of 4.2 and 4.3. Nothing in here changes the KEY or NXT RRs, or the processing involved with data origin and denial authentication for DNS data. 💅

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 👑

2. SIG(0) Design Rationale 🦋

SIG(0) protects DNS transactions and requests in a way that the regular SIG, KEY, and NXT RRs from [RFC 2535] don't. The authenticated data origin services of secure DNS either provide protected data resource records (RRs) or can authenticatably deny that they exist. But those services give no protection for glue records, no protection for DNS requests, no protection for message headers on requests or responses, and no protection for the overall integrity of a response. Lowkey a big gap, which is why SIG(0) exists 💀.

2.1 Transaction Authentication 🎀

Transaction authentication means that a requester can be sure it is at least getting the messages from the server it queried, and that the messages it receives are responding to the query it sent. This works by optionally adding either a TSIG RR [RFC 2845] or, as described here, a SIG(0) resource record at the end of the response. The SIG(0) digitally signs the concatenation of the server's response and the corresponding resolver query. It's giving security 🔥.

2.2 Request Authentication 🍓

Requests can also be authenticated by including a TSIG or, as described here, a special SIG(0) RR at the end of the request. Authenticating requests does nothing in DNS servers that predate the specification of dynamic update. Requests with a non-empty additional information section produce error returns or may even be ignored by a few of those older DNS servers. However, this syntax for signing requests is defined for authenticating dynamic update requests [RFC 2136], TKEY requests [RFC 2930], or future requests requiring authentication. ✨

2.3 Keying 🔐

The private keys used in transaction security belong to the host composing the DNS response message, not to the zone involved. Request authentication may also involve the private key of the host or other entity composing the request, or of a zone to be affected by the request, or other private keys, depending on the request authority it is trying to establish. The corresponding public key(s) are normally stored in and retrieved from the DNS for verification as KEY RRs with a protocol byte of 3 (DNSSEC) or 255 (ANY). 🧚

Because requests and replies are highly variable, message authentication SIGs can not be pre-calculated. So it will be necessary to keep the private key on-line, for example in software or in a directly connected piece of hardware. 💜

2.4 Differences Between TSIG and SIG(0) 💅

There are significant differences between TSIG and SIG(0). 👀

TSIG involves secret keys installed at both the requester and the server, so the presence of such a key implies that the other party understands TSIG and very likely has the same key installed. TSIG also uses keyed hash authentication codes, which are relatively inexpensive to compute. So it's common to authenticate requests with TSIG, and responses are authenticated with TSIG if the corresponding request is authenticated. Very efficient, very iconic 🌸.

SIG(0), on the other hand, uses public key authentication. The public keys are stored in DNS as KEY RRs, and a private key is stored at the signer. Existence of such a KEY RR does not necessarily imply implementation of SIG(0). In addition, SIG(0) involves relatively expensive public key cryptographic operations that should be minimized, and verifying a SIG(0) involves obtaining and verifying the corresponding KEY, which can be an expensive and lengthy operation. Indeed, a policy of using SIG(0) on all requests and verifying it before responding could, for some configurations, lead to a deadly embrace 😭. That's when the attempt to obtain and verify the KEY needed to authenticate the request SIG(0) results in additional requests accompanied by a SIG(0), which lead to further requests accompanied by a SIG(0), and so on forever. Furthermore, omitting SIG(0)s when they are not required on requests halves the number of public key operations required by the transaction. ✨

For these reasons, SIG(0)s SHOULD only be used on requests when necessary to authenticate that the requester has some required privilege or identity. SIG(0)s on replies are defined so that they don't require a SIG(0) on the corresponding request and still provide transaction protection. For other replies, whether they are authenticated by the server, or required to be authenticated by the requester, SHOULD be a local configuration option. 🫶

---

3. The SIG(0) Resource Record 🌷

The structure and type number of SIG resource records (RRs) is given in [RFC 2535] Section 4.1. However, all of Section 4.1.8.1 and the parts of Sections 4.2 and 4.3 related to SIG(0) should be considered replaced by the material below. Any conflict between [RFC 2535] and this document about SIG(0) RRs should be resolved in favor of this document. Main character energy from this document 👑.

For all transaction SIG(0)s, the signer field MUST be a name of the originating host, and there MUST be a KEY RR at that name with the public key corresponding to the private key used to calculate the signature. (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 all SIG(0) RRs, the owner name, class, TTL, and original TTL are meaningless. The TTL fields SHOULD be zero and the CLASS field SHOULD be ANY. To conserve space, the owner name SHOULD be root (a single zero octet). 🧠

When SIG(0) authentication on a response is desired, that SIG RR MUST be considered the highest priority of any additional information for inclusion in the response. If the SIG(0) RR cannot be added without causing the message to be truncated, the server MUST alter the response so that a SIG(0) can be included. This response consists of only the question and a SIG(0) record, and has the TC bit set and RCODE 0 (NOERROR). The client should at this point retry the request using TCP. 🚨

Heads up: if the response gets truncated, the server MUST alter it so a SIG(0) fits, and the client should then retry over TCP. Don't skip this one, it's literally the whole vibe 💅.

3.1 Calculating Request and Transaction SIGs 🧮✨

Okay bestie, so a DNS request can be optionally signed 🔐 by tacking a SIG(0) onto the very end of the query's additional information section. You can spot that SIG by its "type covered" field being zero. It signs the DNS request message that comes before it, including the DNS header but NOT the UDP/IP header, and it's calculated before the request RR counts get bumped up to account for the request SIG(0) itself. 💅

The "data" for a request SIG(0) is built from two things: (1) the SIG's RDATA, but with the signature subfield left out entirely (not just zeroed out) 🙈, and (2) the DNS query message, DNS header included, but not the UDP/IP header, and again before the reply RR counts have been adjusted for the SIG(0). Here it is in one line:

data = RDATA | request - SIG(0)

The | means concatenation, and RDATA here is the RDATA of the SIG(0) being calculated, minus the signature itself. ✨

Now here's where it gets lowkey iconic 👑. A SIG(0) can also secure a response and the request that produced it. These transaction signatures use a "data" made of (1) the SIG's RDATA with the signature itself left out, (2) the entire DNS query message that produced the response, DNS header included but not the UDP/IP header, and (3) the entire DNS response message, DNS header included but not the UDP/IP header, and before the response RR counts have been adjusted for the SIG(0). 🦋

data = RDATA | full query | response - SIG(0)

Same deal with the | (concatenation) and RDATA (the SIG(0)'s RDATA minus the signature). 🫶

Verifying a response SIG(0) is so satisfying 😭. It's signed with the server's host key, NOT the zone key, and when the requesting resolver checks it, the resolver learns three things: the query and response weren't tampered with in transit 🛡️, the response actually matches the query they sent, and the response really came from the server they queried. 🎀

For DNS messages over TCP, the SIG(0) on the first data packet is calculated with the "data" from above. For every packet after that, it's calculated like this:

data = RDATA | DNS payload - SIG(0) | previous packet

The | is concatenation, RDATA is the same as before, and the previous packet is the DNS payload from the packet before, including its DNS header and its SIG(0), but NOT the TCP/IP header. 🌸 Support of SIG(0) for TCP is OPTIONAL. If you need something else, TSIG can be used afterward, after setting up a key with TKEY [RFC 2930], if that's necessary. 🧚

Servers are not required to check a request SIG(0), except where it's needed to authenticate an update, a TKEY, or a similar privileged request. Lowkey a relief, honestly. 💖

Note: requests and responses can either have a single TSIG or one SIG(0) but not both a TSIG and a SIG(0). Pick your lane, babe 🚫💅

---

3.2 Processing Responses and SIG(0) RRs 📬

If a SIG RR sits at the end of a response's additional information section and has a type covered of zero, it's a transaction signature covering that response AND the query that produced it. 🔍

For TKEY responses, the signature MUST be checked, and the message MUST be rejected if the checks fail, unless the TKEY mode in use says otherwise. For every other response, the signature MAY be checked, and the message MAY be rejected if the checks fail. Choices, choices 🍓

If a response's SIG(0) check succeeds, the transaction authentication SIG does NOT directly authenticate the validity of any data-RRs in the message. What it does do is prove that they were sent by the queried server and haven't been diddled 🙈. Only a proper SIG(0) RR signed by the zone, or by a key that traces its authority back to the zone or to static resolver configuration, can directly authenticate data-RRs, depending on the resolver's policy. 🗝️

If a resolver or server doesn't implement transaction and/or request SIGs, it MUST ignore them without error where they are optional, and it MUST treat them as failing where they are required. ✨

---

3.3 SIG(0) Lifetime and Expiration ⏳

The inception and expiration times in SIG(0)s exist to resist replay attacks 🚨. They should be set to form a time bracket, so that messages outside that bracket can be ignored. In IP networks, that bracket should not normally stretch more than 5 minutes into the past or 5 minutes into the future. Time-bound drama, but make it secure 💜

---

4. Security Considerations 🛡️

No additional considerations beyond those in [RFC 2535]. Full stop, but the important stuff is still there 😭

The inclusion of the SIG(0) inception and expiration time under the signature improves resistance to replay attacks. This is the whole reason those times are signed. Protect them like your life depends on it, because replay attacks are NOT a vibe. 🔥

5. IANA Considerations 📋

No new parameters are created or parameter values assigned by this document. Nothing new in the registry this time, bestie 🌈

References 📚

[RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
           September 1996.

[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
           Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
           April 1997.

[RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
           RFC 2535, March 1999.

[RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
           Wellington, "Secret Key Transaction Signatures for DNS
           (TSIG)", RFC 2845, May 2000.

[RFC 2930] Eastlake, D., "Secret Key Establishment for DNS (RR)", RFC
           2930, September 2000.

Author's Address 📮

Donald E. Eastlake 3rd
Motorola
140 Forest Avenue
Hudson, MA 01749 USA

Phone: +1-978-562-2827(h)
       +1-508-261-5434(w)
Fax:   +1 978-567-7941(h)
       +1-508-261-4447(w)
EMail: Donald.Eastlake@motorola.com

Appendix: SIG(0) Changes from RFC 2535 🎀

Here's the glow-up tea ☕ from RFC 2535:

• Add explanatory text concerning the differences between TSIG and SIG(0).
• Change the data over which SIG(0) is calculated to include the SIG(0) RDATA other than the signature itself, so as to secure the signature inception and expiration times and resist replay attacks. Specify SIG(0) for TCP.
• Add discussion of appropriate inception and expiration times for SIG(0).
• Add wording to indicate that either a TSIG or one or more SIG(0)s may be present but not both.
• Reword some areas for clarity.

Full Copyright Statement ©️

Legal text, kept word for word 🫡

Copyright (C) The Internet Society (2000).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society 💕