DNS Request and Transaction Signatures ( SIG(0)s )
updates
- rfc-2535 — Domain Name System Security Extensions
Extracted elements (22)
Request authentication via SIG(0) is primarily intended for dynamic update requests (RFC 2136), TKEY requests (RFC 2930), or future requests requiring authentication. Older DNS servers predating dynamic update may return errors or ignore requests with a non-empty additional section.
SIG(0) provides transaction and request authentication for DNS that the regular SIG, KEY, and NXT RRs do not provide. Standard DNSSEC data-origin services offer no protection for glue records, message headers, or overall response integrity.
SIG(0) uses public key cryptography with KEY RRs stored in DNS, while TSIG uses symmetric shared-secret keyed hashes. SIG(0) operations are relatively expensive; a policy of verifying SIG(0) on all requests can cause a deadly embrace where verification attempts generate further signed requests recursively.
The signed data for SIG(0) was changed from RFC 2535 to include the SIG(0) RDATA (other than the signature itself), securing the signature inception and expiration times and thereby improving replay attack resistance. This is a non-interoperable change from RFC 2535.
Transaction authentication ensures a requester is getting messages from the queried server and that responses correspond to its query, accomplished by appending a SIG(0) RR that signs the concatenation of the server's response and the corresponding resolver query.
A successful response SIG(0) check authenticates that data-RRs were sent by the queried server and have not been tampered with in transit, but does NOT directly authenticate the validity of data-RRs themselves. Only a proper SIG(0) RR signed by the zone or a key tracing authority to the zone can directly authenticate data-RRs.
The changes in this document to SIG(0) calculation and semantics are non-interoperable with the RFC 2535 specification for SIG(0). Any conflict between RFC 2535 and this document concerning SIG(0) RRs should be resolved in favor of this document.
Except where needed to authenticate an update, TKEY, or similar privileged request, servers are not required to check a request SIG(0).
For all SIG(0) RRs, 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). The owner name, class, TTL, and original TTL are meaningless.
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 TKEY responses, the SIG(0) MUST be checked and the message rejected if the checks fail unless otherwise specified for the TKEY mode in use. For all other responses, it MAY be checked and the message rejected if the checks fail.
If a resolver or server does not implement transaction and/or request SIGs, it MUST ignore them without error where they are optional and treat them as failing where they are required.
Requests and responses can either have a single TSIG or one SIG(0) but not both a TSIG and a SIG(0) simultaneously.
SIG(0)s SHOULD only be used on requests when necessary to authenticate that the requester has some required privilege or identity, due to the expense of public key operations and the risk of recursive key-fetching deadlocks.
Support of SIG(0) for TCP is OPTIONAL. As an alternative, TSIG may be used after setting up a key with TKEY (RFC 2930).
When SIG(0) authentication on a response is desired, the SIG RR MUST be considered the highest priority additional information. If adding the SIG(0) RR would truncate the message, the server MUST alter the response to include only the question and the SIG(0) record, with the TC bit set and RCODE 0.
A SIG(0) resource record has a 'type covered' field of zero, distinguishing it from data-origin SIG RRs. It is placed at the end of the additional information section of a DNS request or response.
The inception and expiration times in SIG(0)s resist replay attacks. They should form a time bracket such that messages outside it can be ignored; in IP networks this bracket should not normally extend more than 5 minutes into the past or future.
The inclusion of SIG(0) inception and expiration times under the signature improves resistance to replay attacks. No additional security considerations beyond those in RFC 2535 are identified.
For a request SIG(0), the signed data is: RDATA (SIG RDATA omitting the signature subfield) concatenated with the DNS query message including DNS header but not the UDP/IP header, computed before RR counts are adjusted for SIG(0) inclusion. Formula: data = RDATA | request - SIG(0).
For a transaction SIG(0) on a response, the signed data is: RDATA (omitting signature) concatenated with the full DNS query message and the full DNS response message, both including DNS headers but not UDP/IP headers. Formula: data = RDATA | full query | response - SIG(0).
For DNS over TCP, the first packet SIG(0) is calculated as for UDP. For each subsequent packet, the signed data is: RDATA | DNS payload - SIG(0) | previous packet, where 'previous packet' includes DNS header and the SIG(0) but not the TCP/IP header.