Re: [dnsext] RFC 4470 bitmap (Was Re: Authenticated denial of existence...)

[Matthijs Mekking <[e-mail]>]

On 11/22/2013 03:06 PM, Tony Finch wrote:
> Matthijs Mekking <[e-mail]> 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.

It is not clear to me that this sentence only refers to the on-demand
NSEC records. Especially because the sentence talks about "generated
NSEC record's type bitmap" and in para. 1 of sect 3. it is mentioned
that for instantiated names, NSEC records can still be generated and
signed in advance.

But yes, it makes sense that the rule only applies to non-existent names.

Best regards,
  Matthijs

> 
>> (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.
>