]> Internet Systems Consortium

Czechia ondrej@isc.org

Internet Systems Consortium

Czechia jan@isc.org

Internet Systems Consortium

Czechia pspacek@isc.org

Operations and Management DNSOP dns dnssec rrsig amplification The Domain Name System (DNS) allows a query with QTYPE=RRSIG. Such a query has no useful answer. RRSIG resource records are meaningful only together with the resource records they cover, so a response can carry no more than an arbitrary subset of the signatures present at the query name. This document specifies that DNS responders refuse queries with QTYPE=RRSIG, and that DNS requestors do not send them. It supplies the guidance that left unspecified.

Introduction The Domain Name System (DNS) allows a query with QTYPE=RRSIG . The RRSIG resource records at a name are the signatures covering the other types present at that name, and each of them can be validated only together with the RRset it covers. A response to a query with QTYPE=RRSIG therefore carries an arbitrary subset of the signatures at the query name, chosen by the responder, that a validating resolver can neither validate nor usefully cache. The DNSSEC specification does not describe the behaviour of DNS responders or DNS requestors for such queries. Section 7 of observed that queries with QTYPE=RRSIG resemble queries with QTYPE=ANY, but did not specify the behaviour for them. This document specifies it: responders refuse the query, and requestors do not send it.

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 . The terms "requestor" and "responder" are used as defined in Section 2 of . The term "requestor" corresponds to the term "initiator" used in .

Motivations for Use of RRSIG Queries There is no legitimate use of a query with QTYPE=RRSIG. The signatures a validating resolver needs are the ones covering the RRsets it asked for, and those are returned together with the covered RRsets whenever DNSSEC data is requested . A validating resolver that receives RRSIG resource records without the resource records they cover cannot validate them and discards the whole answer. Queries with QTYPE=RRSIG are attractive for amplification attacks that use spoofed source addresses and UDP transport . The response is the concatenation of every signature at the query name and is large in relation to the query; at the time of writing, a query for the RRSIG type at the root produces a response of approximately 1200 octets. A recursive resolver answers a query with QTYPE=RRSIG from whatever happens to be in its cache at the time, so the same query returns a different set of signatures from one moment to the next. Some authoritative DNS server implementations require additional processing in order to send a conventional RRSIG response; avoiding that processing expense might be desirable. A server that generates signatures on demand has to generate all of them to answer one such query. Some existing DNS server implementations, both recursive and authoritative, already respond to queries with QTYPE=RRSIG with RCODE=REFUSED.

Behaviour of DNS Responders A DNS responder SHOULD refuse a query with QTYPE=RRSIG and return a response with RCODE=REFUSED. The response SHOULD contain the Extended DNS Error code 21 (Not Supported). This applies to authoritative servers and recursive resolvers alike. The query SHOULD be refused before any lookup is performed. The answer, authority, and additional sections of the response are empty, and the TC bit MUST NOT be set: the response is complete, and repeating the query over TCP does not produce a different result. Refusing queries with QTYPE=RRSIG does not affect DNSSEC. RRSIG resource records continue to be included in the responses for the types they cover whenever DNSSEC data is requested, as specified in .

Behaviour of DNS Requestors A DNS requestor MUST NOT send a query with QTYPE=RRSIG. A resolver MUST NOT send such a query to a DNS responder: the answer can be neither validated nor cached, so the query serves no purpose. Diagnostic and debugging tools MAY send a query with QTYPE=RRSIG in order to observe the behaviour of a DNS responder. A DNS requestor that receives RCODE=REFUSED in response to a query with QTYPE=RRSIG SHOULD NOT repeat the query to another server, over another transport, or with different EDNS parameters. The refusal is a complete answer.

Updates to RFC 8482 Section 7 of states that it does not specify appropriate behaviour for queries with QTYPE=RRSIG. This document specifies that behaviour. The treatment specified here differs from the treatment specifies for QTYPE=ANY. A query with QTYPE=ANY has many valid answers and a responder can return any one of them; a query with QTYPE=RRSIG has none, so there is nothing to return and the query is refused instead.

Implementation Status Cloudflare authoritative servers respond to queries with QTYPE=RRSIG with RCODE=REFUSED and the Extended DNS Error code 21 (Not Supported). BIND 9 version in development refuses queries with QTYPE=RRSIG with RCODE=REFUSED and the Extended DNS Error code 21 (Not Supported), on authoritative servers and recursive resolvers alike, and never sends such queries to other servers.

Security Considerations Responses to queries with QTYPE=RRSIG are large in relation to the query and are therefore useful in reflection attacks that use spoofed source addresses . Refusing the query removes that amplification. Refusing queries with QTYPE=RRSIG is not a DNSSEC downgrade. The signatures needed for validation are carried in the responses for the types they cover, and a validating resolver never has to query for the RRSIG type in order to validate an answer. An off-path attacker can forge the REFUSED response, but a conventional response to a query with QTYPE=RRSIG carries nothing a validating resolver can act on, so the forgery gains the attacker nothing.

IANA Considerations This document has no IANA actions.

References Normative References The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The operator of an authoritative DNS server might choose not to respond to such queries for reasons of local policy, motivated by security, performance, or other reasons. The DNS specification does not include specific guidance for the behavior of DNS servers or clients in this situation. This document aims to provide such guidance. This document updates RFCs 1034 and 1035. This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] 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. The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow. This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS. This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs. Informative References This document describes ways to prevent the use of default configured recursive nameservers as reflectors in Denial of Service (DoS) attacks. It provides recommended configuration as measures to mitigate the attack. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

Acknowledgments TODO acknowledge.