It says that RRSIGs exist at that name. -- Mark Andrews
> On 28 Feb 2021, at 08:35, Viktor Dukhovni <[email protected]> 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 > [email protected] > https://lists.dns-oarc.net/mailman/listinfo/dns-operations _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
