| Internet-Draft | The DNS SIG(0) RR | October 2024 |
| Eastlake | Expires 24 April 2025 | [Page] |
This document specifies use of the Domain Name System (DNS) SIG Resource Record (RR) to provide a public key based method to authenticate DNS requests and transactions. Such a resource record, because it has a "type covered" field of zero, is frequently called a "SIG(0)". This document obsoletes RFC 2931.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 24 April 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document specifies use of the Domain Name System (DNS) SIG Resource Record (RR) to provide a public key based method to authenticate DNS requests and transactions. Such a resource record, because it has a "type covered" field of zero, is frequently called a "SIG(0)". This document obsoletes RFC 2931.¶
General familiarity with DNS terminology [RFC9499] is assumed in this document.¶
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.¶
SIG(0) provides protection for DNS transactions and requests that is not provided by the DNSSEC RRs specified in [RFC4034]. The authenticated data origin services of DNSSEC [RFC4035] either provide protected data resource records (RRs) or authenticatable denial of their existence. These services provide no protection for glue records, DNS requests, no protection for the DNS message headers on requests or responses, and no protection of the overall integrity of a transaction.¶
Transaction authentication provides some cryptographic assurance to a resolver that it is at least getting the DNS response message from the server and that the received message is in response to the request it sent. This is accomplished by adding either a TSIG RR [RFC8945] or, as specified herein, a SIG(0) RR, at the end of the response which authenticates the concatenation of the corresponding resolver request and the server's response.¶
Requests can also be authenticated by including a SIG(0) RR at the end of the request's additional information section. Authenticating requests serves little function in DNS servers that predate the specification of dynamic update except to enable more rigorous enforcement of restrictions on which resolvers can make what requests of the server. The method of signing requests specified herein is for authenticating dynamic update requests [RFC3007], TKEY requests [rfc2930bis], or requests specified in the future that require authentication.¶
The private keys used in public key based transaction security belong to the host composing the DNS response message, not to any 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 sought to establish. The corresponding public key(s) can be stored in and retrieved from the DNS for verification as KEY RRs with a protocol byte of 255 (ANY).¶
A TSIG [RFC8945] RR can also be used for request and transaction authentication. There are significant differences between TSIG and SIG(0).¶
Because TSIG involves secret keys available at both the requester and server the presence of such a key implies that the other party understands TSIG and likely has the same key installed. Furthermore, TSIG uses keyed hash authentication codes which are relatively inexpensive to compute. Thus, it is common to authenticate requests with TSIG and to authenticate responses with TSIG if the corresponding request is authenticated.¶
SIG(0) on the other hand, uses public key authentication, where the public keys can be 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 that SIG(0) is implemented or enabled. In addition, SIG(0) involves relatively expensive public key cryptographic operations that should be minimized and the verification of 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 would, for some configurations, lead to a deadly embrace with the attempt to obtain and verify the KEY needed to authenticate the request SIG(0) resulting in additional requests accompanied by a SIG(0) leading to further requests accompanied by a SIG(0), etc. Furthermore, omitting SIG(0)s when 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 transactions are defined in such a way as to not require a SIG(0) on the corresponding request and still provide transaction protection. Whether SIG(0)s are authenticated by the server or required to be authenticated by the requester SHOULD be a local configuration option.¶
The structure of SIG resource records (RRs) is the same as the structure of the RRSIG RR in [RFC4034] Section 4 except as provided below.¶
The type of the SIG RR is 24. For SIG(0) RRs, the owner name, class, TTL, and original TTL, are meaningless. The TTL fields MUST be zero and the CLASS field MUST be ANY, and 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. To conserve space, the owner name SHOULD be root (a single zero octet).¶
The inception and expiration times in SIG(0)s are for the purpose of resisting replay attacks. They should be set to form a time bracket such that messages received outside that bracket can be ignored. In IP networks, this time bracket should not normally extend further than 5 minutes into the past and 5 minutes into the future.¶
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. 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.¶
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.¶
A DNS request may be optionally signed by including one SIG(0)s at the end of the request additional information section. Such a SIG is distinguished by having a "type covered" field of zero. It is calculated for and signs the "data" consisting of (1) the SIG's RDATA section entirely omitting (not just zeroing) the signature subfield itself, (2) the DNS request message, including DNS header, but not the UDP/IP header and before the RR counts have been adjusted for the inclusion of the SIG(0). That is¶
data = RDATA | ( request - SIG(0) )¶
where "|" is concatenation and RDATA is the RDATA of the SIG(0) being calculated omitting the signature itself.¶
Similarly, a SIG(0) can be used to secure a response and the request that produced it. Such transaction signatures are calculated by using a "data" of (1) the SIG's RDATA section omitting (not just zeroing) the signature itself, (2) the entire DNS request message that produced this response, including the request's DNS header but not its UDP/IP header, and (3) the entire DNS response message, including DNS header but not the UDP/IP header and before the response RR counts have been adjusted for the inclusion of the SIG(0).¶
data = RDATA | full query | ( response - SIG(0) )¶
where "|" is concatenation and RDATA is the RDATA of the SIG(0) being calculated less the signature itself.¶
Verification of a response SIG(0) (which is signed by the server host key, not a zone key) by the requesting resolver shows that the query and response were not tampered with in transit, that the response corresponds to the intended query, and that the response comes from the queried server.¶
In the case of a DNS message via TCP, a SIG(0) on the first data packet is calculated with "data" as above and for each subsequent packet, it is calculated as follows:¶
data = RDATA | ( DNS payload - SIG(0) ) | previous packet¶
where "|" is concatenations, RDATA is as above, and previous packet is the previous DNS payload including DNS header and the SIG(0) but not the TCP/IP header. As an alternative, TSIG may be used after, if necessary, setting up a key with TKEY [rfc2930bis].¶
Except where needed to authenticate an update, TKEY, or similar privileged request, servers are not required to check a request SIG(0).¶
Requests and responses can either have a TSIG RR or a SIG(0) RR but not both.¶
If a SIG RR is at the end of the additional information section of a response and has a type covered of zero, it is a transaction signature covering the response and the request that produced the response.¶
If a response's SIG(0) check succeeds, such a transaction authentication SIG does NOT directly authenticate the validity any data RRs in the message. However, it authenticates that they were sent by the queried server and have not been altered in transit. (Only a proper 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(0)s, it MUST ignore them without error where they are optional and treat them as failing where they are required.¶
A server acting as a forwarding server of a DNS message SHOULD check for the existence of a SIG(0) record. If it cannot verify the SIG(0), the server MUST forward the message unchanged including the SIG(0). If the SIG(0) passes all checks and verifies, the forwarding server MUST, if possible, include a SIG(0) or TSIG of its own to the destination or the next forwarder. If no transaction security is available to the destination and the message is a query, and if the corresponding response has the AD flag (see [RFC4035]) set, the forwarder MUST clear the AD flag before adding the SIG(0) to the response and returning the result to the system from which it received the query.¶
A forwarded SIG(0) is not verifiable unless the original transaction ID is preserved by, for example, using TCP and maintaining a separate ID space for that TCP connection.¶
The inclusion of the SIG(0) inception and expiration time under the signature improves resistance to replay attacks.¶
More TBD¶
This document requires no IANA action.¶
The comments and suggestions of the following are gratefully acknowledged:¶
tbd¶
The comments and suggestions of the following persons were incorporated into RFC 2931, which was the previous version of this document, and are gratefully acknowledged:¶
Olafur Gudmundsson, Ed Lewis, Erik Nordmark, Brian Wellington.¶