Re: RFC 4470 bitmap (Was Re: Authenticated denial of existence...)
Tony Finch <[email protected]> Fri, 22 Nov 2013 14:06:11 +0000
| Newsgroups | gmane.ietf.dnsext |
|---|---|
| Message-ID | <[email protected]> |
Matthijs Mekking <[email protected]> wrote: > > Main point: I cannot find requirements for the owner name. In other > words, that may be an existing name. There are two cases: "instantiated names" which are names that exist in the zone, in which case the owner name of the NSEC record matches the owner name of the other records (para. 2 of sect. 3); and proofs of nonexistence generated on-demand (para. 3 of sect. 3): Whenever an NSEC record is needed to prove the non-existence of a name, a new NSEC record is dynamically produced and signed. The new NSEC record has an owner name lexically before the QNAME but lexically following any existing name and a "next name" lexically following the QNAME but before any existing name. > But the RFC explicitly says: > > The generated NSEC record's type bitmap MUST have the RRSIG and NSEC > bits set and SHOULD NOT have any other bits set. That is the first sentence of para. 4 of sect. 3 which refers to the on-demand NSEC records described in the previous paragraph. > (By the way, I think the requirement should be relaxed, because a > minimally covering NSEC record may also be used in a NODATA response) For NODATA responses you use the NSEC record of an instantiated name, which can be minimally covering as described in para. 2 of sect. 3. Tony. -- f.anthony.n.finch <[email protected]> http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. _______________________________________________ dnsext mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsext