Internet-Draft Refusing QTYPE=RRSIG Queries August 2026
Surý, et al. Expires 15 February 2027 [Page]
Workgroup:
DNSOP
Internet-Draft:
draft-sury-dnsop-rrsig-refused-00
Updates:
RFC8482 (if approved)
Published:
Intended Status:
Standards Track
Expires:
Authors:
O. Surý
Internet Systems Consortium
J. Včelák
Internet Systems Consortium
P. Špaček
Internet Systems Consortium

Refusing DNS Queries That Have QTYPE=RRSIG

Abstract

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 [RFC8482] left unspecified.

Status of This Memo

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 15 February 2027.

Table of Contents

1. Introduction

The Domain Name System (DNS) allows a query with QTYPE=RRSIG [RFC4034]. 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 [RFC4033] [RFC4034] [RFC4035] does not describe the behaviour of DNS responders or DNS requestors for such queries. Section 7 of [RFC8482] 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.

2. 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 [RFC2119] [RFC8174] 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 [RFC9499].

The terms "requestor" and "responder" are used as defined in Section 2 of [RFC6891]. The term "requestor" corresponds to the term "initiator" used in [RFC8482].

3. 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 [RFC4035]. 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 [RFC5358]. 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.

4. 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 [RFC8914] 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 [RFC4035].

5. 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.

6. Updates to RFC 8482

Section 7 of [RFC8482] 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 [RFC8482] 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.

7. 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.

8. 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 [RFC5358]. 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.

9. IANA Considerations

This document has no IANA actions.

10. References

10.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4033]
Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, , <https://www.rfc-editor.org/rfc/rfc4033>.
[RFC4034]
Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, , <https://www.rfc-editor.org/rfc/rfc4034>.
[RFC4035]
Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, , <https://www.rfc-editor.org/rfc/rfc4035>.
[RFC6891]
Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, , <https://www.rfc-editor.org/rfc/rfc6891>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8482]
Abley, J., Gudmundsson, O., Majkowski, M., and E. Hunt, "Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY", RFC 8482, DOI 10.17487/RFC8482, , <https://www.rfc-editor.org/rfc/rfc8482>.
[RFC8914]
Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. Lawrence, "Extended DNS Errors", RFC 8914, DOI 10.17487/RFC8914, , <https://www.rfc-editor.org/rfc/rfc8914>.
[RFC9499]
Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, , <https://www.rfc-editor.org/rfc/rfc9499>.

10.2. Informative References

[RFC5358]
Damas, J. and F. Neves, "Preventing Use of Recursive Nameservers in Reflector Attacks", BCP 140, RFC 5358, DOI 10.17487/RFC5358, , <https://www.rfc-editor.org/rfc/rfc5358>.

Acknowledgments

TODO acknowledge.

Authors' Addresses

Ondřej Surý
Internet Systems Consortium
Czechia
Jan Včelák
Internet Systems Consortium
Czechia
Petr Špaček
Internet Systems Consortium
Czechia