[dns-operations] Possibly-incorrect NSEC responses from many RSOs
marka at isc.org
Sun Feb 28 01:32:23 UTC 2021
It says that RRSIGs exist at that name.
> 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
> Since RRSIGs are not signed (no turtles all the way down), and the
> response cannot be validated, the RRSIG record can be entirely
> 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...
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
More information about the dns-operations