]> ISC

ondrej@isc.org

Cloudflare

jabley@cloudflare.com

Operations and Management Domain Name System Operations transaction signatures tsig dns Transation Signatures (TSIG) provide a standard mechanism to sign DNS messages, so that the authenticity of messages can be verified by the system that receives them. This document updates the required behaviour of a system that receives a signed message that fails verification. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Domain Name System Operations Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Transaction Signatures are specified in and provides a mechanism for transaction-level authentication of DNS messages using shared secrets and one-way hash functions. It can be used to authenticate messages exchanged between DNS clients and servers, e.g. in cases where message integrity and authorisation are important, such as DNS Update and the DNS Zone Transfer Protocol .

Terminology 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 when, and only when, they appear in all capitals, as shown here. This document assumes familiarity with terminology specific to the Domain Name System (DNS) as described in .

Processing of Signed Responses The processing of a signed response by a DNS client is described in section 5.4 of , which includes the following in the case of signed messages that fail verification:

• Regardless of the RCODE, a message containing a TSIG RR that is unsigned as specified in Section 5.3.2 or that fails verification SHOULD NOT be considered an acceptable response, as it may have been spoofed or manipulated. Instead, the client SHOULD log an error and continue to wait for a signed response until the request times out.

There are basically two scenarios how such a message can be received by client. Either the server is misconfigured or the client is under attack. If we assume that such a response has been sent by misconfigured server, e.g. server that doesn't have the correct TSIG keys or isn't configured to use TSIG keys to sign messages to this particular client then no amount of waiting will allow the DNS communication to recover as the server will never send a correct message back. If we assume that such a response is malicious, then the possible attacks can be categorised as on-path or off-path. In the case of an off-path attack, the specified behaviour is not ideal since it provides an increased window of opportunity for an attacker that has correctly guessed parameters such as source port and query id to continue sending responses with different signatures. In the case of an on-path attack, there is even less value in waiting for a valid response, since the attacker can be assumed to have full control over what messages are and are not allowed to reach the client, and once again waiting only provides the attacker with more opportunity to conduct their attack. This document updates the specification in this case to clarify that clients that receive responses that fit the description quoted above SHOULD log an error and MUST treat the message as corrupt, MUST discard it immediately and MUST NOT continue to wait.

Security Considerations This document updates and provides new guidance in order to mitigate on-path and off-path attacks on signed DNS responses.

IANA Considerations This document has no IANA actions.

References Normative References This document describes a protocol for transaction-level authentication using shared secrets and one-way hashing. It can be used to authenticate dynamic updates to a DNS zone as coming from an approved client or to authenticate responses as coming from an approved name server. No recommendation is made here for distributing the shared secrets; it is expected that a network administrator will statically configure name servers and clients using some out-of-band mechanism. This document obsoletes RFCs 2845 and 4635. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. Informative References Using this specification of the UPDATE opcode, it is possible to add or delete RRs or RRsets from a specified zone. Prerequisites are specified separately from update operations, and can specify a dependency upon either the previous existence or nonexistence of an RRset, or the existence of a single RR. [STANDARDS-TRACK] The standard means within the Domain Name System protocol for maintaining coherence among a zone's authoritative name servers consists of three mechanisms. Authoritative Transfer (AXFR) is one of the mechanisms and is defined in RFC 1034 and RFC 1035. The definition of AXFR has proven insufficient in detail, thereby forcing implementations intended to be compliant to make assumptions, impeding interoperability. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of AXFR -- new in the sense that it records an accurate definition of an interoperable AXFR mechanism. [STANDARDS-TRACK]

Acknowledgments TODO acknowledge.