Re: [dnsext] Fwd: RFC 2308 & RFC 4035

[Brian Dickson <[e-mail]>]

On Fri, Feb 25, 2011 at 4:24 PM, Edward Lewis <[e-mail]> wrote:
> At 20:08 +0000 2/25/11, George Barwood wrote:
>
>> I think this is addressed by
>>
>> http://tools.ietf.org/html/rfc4035#section-4.5
>>
>> <<
>>   In theory, a resolver could use wildcards or NSEC RRs to generate
>>   positive and negative responses (respectively) until the TTL or
>>   signatures on the records in question expire.  However, it seems
>>   prudent for resolvers to avoid blocking new authoritative data or
>>   synthesizing new data on their own.  Resolvers that follow this
>>   recommendation will have a more consistent view of the namespace.

However, this is immediately following (in 4.5):
   2.  NSEC RRs received to prove the non-existence of a name could be
       reused by a security-aware resolver to prove the non-existence of
       any name in the name range it spans.

So, I'd say there are two distinct cases:
- the NSEC *might* be used to deny the existence of a double
(QNAME,QCLASS) in the range
  (e.g. if "next domain name" were b.example.net, and the QNAME were
a.example.net)
- the NSEC is used to deny the existence of an RRTYPE not listed in the NSEC

The former falls in the "it seems prudent" category.

The latter, I think, does not, in which case, using the NSEC to
generate a NODATA answer is appropriate.
It would never be *wrong* to query the authority server, but it might
be unnecessary, e.g. 99.9999% of the time.

There is one other conflict, I think, which could occur - if an NSEC
is cached, but an RRTYPE not found in the NSEC, is also cached at the
same QNAME,QCLASS.
Is that bad or broken? (Should adding/removing an RRTYPE, or
adding/removing a name, result in selective re-generation of
NSEC/NSEC3 records and their signatures)?
Does it matter which order the two responses arrive? (If it does, I
think that indicates that there's a protocol problem....)
Should it trigger discarding or non-caching of the NSEC record? (I
think not, modulo the question on re-generation/re-signing NSEC/NSEC3
data)

> Good observation.  Question to those who've written caches, what strategy
> seemed best.
>
> It's passages like the quoted that should be firmed up when and if DNSSEC is
> ever a Draft Standard/Full Standard.
>
> And getting back to the resimprove draft, I'd wager that a BCP shouldn't
> disagree with a Standards Track document.

Agree.

Brian
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext