Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

[Shumon Huque <[e-mail]>]

On Tue, Sep 27, 2016 at 3:10 PM, Shumon Huque <[e-mail]> wrote:

> On Tue, Sep 27, 2016 at 2:48 PM, White, Andrew <[e-mail]>
> wrote:
>
>> Hi Shumon,
>>
>>
>> What about this?
>>
>>
>>
>> # When an iterative caching DNS resolver receives a response with RCODE
>> being NXDOMAIN,
>>
>> # the resolver SHOULD store the response in its (negative) cache.  During
>> the time the response
>>
>> # is cached, any query with a QNAME at or descended from the denied name
>> that is not otherwise
>>
>> #cached (positively), can be assumed to result in a name error.
>> Responses to those queries
>>
>> # SHOULD set RCODE=NXDOMAIN (using the DNSSEC records cached as proof).
>>
>>
>>
>> When an iterative caching DNS resolver receives a query response with
>> RCODE as NXDOMAIN,
>>
>> The resolver should store the NXDOMAIN response in cache. During the time
>> that this response
>>
>> is cached, any query with a QNAME at or descended from the query that
>> resulted in NXDOMAIN
>>
>> and that is not already in cache can be assumed to result in a name
>> error. Responses to such
>>
>> queries SHOULD respond with RCODE as NXDOMAIN using DNSSEC records from
>> cache as proof.
>>
>>
>>
>> Andrew
>>
>
> Andrew - this looks very similar to Ed's rewrite.
>
> The problem I see with both is that it says to reply with NXDOMAIN for all
> names at or below the cut, except for RRsets already positively cached. But
> the current draft also allows resolvers to immediately invalidate cached
> entries below the cut and also return NXDOMAIN for them. Your rewrite
> appears to remove (or at least not mention) that possibility.
>
> --
> Shumon Huque
>

One other quick comment on the rewrite:

" .. (using the DNSSEC records cached as proof)." is a bit unclear and
perhaps misplaced. I assume here this means signed NSEC or NSEC3 records,
which may or may not exist depending on whether the zone in question is
signed. And even if they exist, the resolver typically doesn't return them
as proof unless the querier sets DO=1. I think we cover this point further
down in the text, which I'll excerpt here:

  "If the NXDOMAIN response due to a cached non-existence is from a
   DNSSEC signed zone, then it will have accompanying NSEC or NSEC3
   records that authenticate the non-existence of the name.  For a
   descendant name of the original NXDOMAIN name, the same set of NSEC
   or NSEC3 records proves the non-existence of the descendant name.
   The iterative, caching resolver MUST return these NSEC or NSEC3
   records in the response to the triggering query if the query had the
   DNSSEC OK (DO) bit set."

Re-reading this paragraph, I think I'd suggest explicitly mentioning that
the NSEC/NSEC3 signatures must be returned also.

-- 
Shumon Huque