[DNSOP] Re: New Version Notification for draft-sury-dnsop-rr sig-refused-00.txt

Hi everyone,

it was also suggested off-list that returning "something" might be an option. I did think
about this for a while and in fact, I've implemented several variants of that until coming
to conclusion that it makes no sense going half-way.

I would be happy to turn the text below into paragraph in the draft.

### Authoritative servers

For authoritative servers, returning "something" (first RRSIG, whatever) is fine

### Recursive servers

For recursive servers, it is possible to return "something" if there's something in the
cache, but if there's no RRSIG under the name, you can't return "something" because
you don't know if there's a RRSIG or not in the authority. So, you want to prime the
cache with something, so what do you do? There's couple of options:

1. send A/AAAA/MX (whatever) query to upstream with +rd +dnssec
2. send RRSIG query to upstream with +rd (+dnssec)
3. send SOA query to upstream with +rd +dnssec
4. something else?

Either of these can return a positive or negative answer. The positive answer might include
RRSIG, but if it doesn't you are at square one. Same thing with negative answer or error,
the resolver also does not have anything to return.

I believe it is better to be strict here (even if the deployment can take years) and both refuse
to answer RRSIG queries and to send RRSIG queries to upstream servers (both authoritative
and forwarders).

### Validating servers

Validating servers might store the "extra" RRSIG(RR) in the cache with "unvalidated" status,
but there's no reason to do so because answers with RR will always include the signatures,
so that would only increase complexity.

### Non-validating servers

There's only one scenario where returning something for RRSIG queries has a little value
and that's non-validating servers (servers that don't understand DNSSEC). Non-validating
servers could cache RRSIG records as opaque blobs and return them to the clients.

I still believe this is a weak reason to return "something" instead of return FORMERR or
REFUSED.

Cheers,
Ondrej
--
Ondřej Surý (He/Him)
[email protected]

A gentle nudge is always appreciated if I take a little longer to reply.

> On 14. 8. 2026, at 20:33, Ondřej Surý <[email protected]> wrote:
> 
> Colleagues,
> 
> this is the first version of complement to RFC8482 that specifies how the DNS requestors
> and DNS responders should behave in case of RRSIG query.
> 
> 1. this already describes a practice of some DNS operators (Cloudflare, NS1)
> 2. it is important to realize that any validating resolver can't validate RRSIG(RR)
> records without receiving RDATA for RR, so RRSIG queries for signed domains
> can't be cached (not without significantly increasing a complexity)
> 3. RRSIG queries for signed domains have a same property as ANY queries,
> but they are even worse. The ANY queries have a fringe debugging property,
> the RRSIG responses are just "stuffing" that is being used for reflection attacks.
> 
> We understand that the impact of this might be visible in years from now,
> but this is well-aligned with RFC 9413 and this change will increase the
> Protocol Robustness in the long term.
> 
> Cheers,
> Ondrej
> --
> Ondřej Surý (He/Him)
> [email protected]
> 
> A gentle nudge is always appreciated if I take a little longer to reply.
> 
>> Begin forwarded message:
>> 
>> From: [email protected]
>> Subject: New Version Notification for draft-sury-dnsop-rrsig-refused-00.txt
>> Date: 14 August 2026 at 20:24:21 CEST
>> To: "Jan Včelák" <[email protected]>, "Ondřej Surý" <[email protected]>, "Petr Špaček" <[email protected]>, "Jan Vcelak" <[email protected]>, "Ondrej Sury" <[email protected]>, "Petr Spacek" <[email protected]>
>> 
>> A new version of Internet-Draft draft-sury-dnsop-rrsig-refused-00.txt has been
>> successfully submitted by Ondřej Surý and posted to the
>> IETF repository.
>> 
>> Name:     draft-sury-dnsop-rrsig-refused
>> Revision: 00
>> Title:    Refusing DNS Queries That Have QTYPE=RRSIG
>> Date:     2026-08-14
>> Group:    Individual Submission
>> Pages:    7
>> URL:      https://www.ietf.org/archive/id/draft-sury-dnsop-rrsig-refused-00.txt
>> Status:   https://datatracker.ietf.org/doc/draft-sury-dnsop-rrsig-refused/
>> HTML:     https://www.ietf.org/archive/id/draft-sury-dnsop-rrsig-refused-00.html
>> HTMLized: https://datatracker.ietf.org/doc/html/draft-sury-dnsop-rrsig-refused
>> 
>> 
>> 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.
>> 
>> 
>> 
>> The IETF Secretariat
>> 
>> 
> 
> _______________________________________________
> DNSOP mailing list -- [email protected]
> To unsubscribe send an email to [email protected]

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]