Subject: Re: [dnsext] Comments on draft-ietf-dnsext-dnssec-bis-updates-09

From: Florian Weimer <[email-masked]>
Date: Fri, 12 Feb 2010 12:21:22 +0100

* Mark Andrews:

> In message <[email-masked]>, Florian Weimer writes:

>> But RFC 4035 says this in section 3.2.2:
>> 
>> |  If the resolver side implements a BAD cache (see Section 4.7) and the
>> |  name server side receives a query that matches an entry in the
>> |  resolver side's BAD cache, the name server side's response depends on
>> |  the state of the CD bit in the original query.  If the CD bit is set,
>> |  the name server side SHOULD return the data from the BAD cache; if
>> |  the CD bit is not set, the name server side MUST return RCODE 2
>> |  (server failure).
>> 
>> The latter case appears to be the relevant one to me, so I still don't
>> see how the advice in section 4.8 of the draft matters in practice.
>
> You still need to make upstream queries to populate either the
> normal cache or a BAD cache (assuming you have one).  Anything in
> a BAD cache would have had CD=1 on the upstream query because to
> enter the BAD cache it had to fail validation and to validate you
> make CD=1 queries.

The latter part feels bad and is quite surprising.  Is it really
desirable to potentially reduce security when running validation
yourself?  (Assuming that the ISP resolver validates, too, and puts
more effort into it, therefore having more trust anchors to work
with.)