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

[Viktor Dukhovni]

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.