[dns-operations] Possibly-incorrect NSEC responses from many RSOs

[Mark Andrews]

It says that RRSIGs exist at that name. 

-- 
Mark Andrews

> On 28 Feb 2021, at 08:35, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> 
> On Sat, Feb 27, 2021 at 05:06:29PM +0000, Paul Hoffman wrote:
> 
>> The text in Section 3 of RFC 4035 is:
>> 
>>   A security-aware name server that receives a DNS query that does not
>>   include the EDNS OPT pseudo-RR or that has the DO bit clear MUST
>>   treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and
>>   MUST NOT perform any of the additional processing described below.
>> 
>> The "treat ... as it would any other RRset" seems to say that if an
>> authoritative server gets a query for <tld>/NSEC for a name that has
>> an NSEC record in the zone, that NSEC record should appear in the
>> Answer section.
> 
> The RFC 4035 language is sound for NSEC and DNSKEY, but (and this is a
> related side topic), I rather think that the specification should have
> said that queries for "RRSIG" for an extant name should return a single
> RRSIG of their choice, rather than treat RRSIG records as a normal
> RRSet.
> 
> Since RRSIGs are not signed (no turtles all the way down), and the
> response cannot be validated, the RRSIG record can be entirely
> synthetic:
> 
>    example.com. 0 IN RRSIG (
>        RRSIG 255 2 0 19700101000000 19700101000000
>        0 example.com. AAAA )
> 
> The reason is that the collection of RRSIGs for a name do not form a
> sensible coherent RRset, (indeed there is no RRSIG over the hypothetical
> RRSIG RRset) and there will often much be too many of them (one for each
> RRtype associated with the node) for a server to be willing to return
> them all.
> 
> The response could have been NODATA, with proof of the existence of the
> node, were it not for perhaps another design issue, in that the
> NSEC/NSEC3 bitmap always includes RRSIG, which looks like a mistake to
> me, but perhaps I'm missing something...
> 
> -- 
>    Viktor.
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations