Subject: Re: Glue (was Re: validating a qtype=* response)

From: David Blacka <[email-masked]>
Date: Fri, 3 Jun 2005 10:26:22 -0400

On Jun 3, 2005, at 9:57 AM, Scott Rose wrote:

> So to summarize:  if one RRSIG covering one RRset in a response for
> QTYPE="*" fails to validate, then the whole response is marked  
> Bogus.  I can
> accept that.  However, that might lead to a weird situation where a  
> cache
> would have the same RRset in the BAD cache and the "good" cache for  
> the same
> QNAME, but with one stored as a part of a QTYPE="*" query.  This  
> assumes the
> cache is storing responses as a single atomic unit based on
> qname/qclass/qtype (which may not be the case for some).  Not sure  
> how that
> would affect things.

I think implementers and implementations need to be careful with how  
they mix this sort of granularity.  I would think that marking a  
message as bad in a BAD cache (or otherwise) shouldn't automatically  
effect the cached validation status (if any) of individual rrsets.   
You would mark a response as bogus if, say, the NS rrset in the  
authority section was bogus, even if the answer rrset in the answer  
section validated.

In any case, Sam's proposed text isn't discussing caching, as I read  
it.  It is discussing what should be returned to the client in a very  
generic way, which I think is appropriate.

> I would suggest changing the wording of the last sentence to state:
>
> "To be clear, a validator must not expect to receive all records at  
> the
> QNAME in response to QTYPE=* if the query is sent to a cache and  
> not an
> authoritative server."

Does that mean different validation rules for responses with AA=1?

> This would bring it in line with what RFC 1034 has in the examples for
> QTYPE="*" (Section 6.2.2).

Otherwise, I'm fairly happy with Sam's proposed text, myself.  I'm  
still concerned as to whether there is supporting text elsewhere in  
the DNS standard that speaks to the necessity to recurse when qtype=*  
and qname/qclass isn't present in the cache.  I mean, I agree with Ed  
that certainly a cache *should* recurse, but are we confident that  
they all *do*?

--
David Blacka    <[email-masked]>
Sr. Engineer    VeriSign Applied Research

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "Scott Rose" <[email-masked]>
Date: Fri, 3 Jun 2005 10:46:20 -0400

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of David Blacka
>

Nope - probably should be more clear.  I meant to say that a client should
not expect to get all the RRsets for a given QNAME if it sends a query to a
cache.  Bascially change the "insist" to "expect", since there is no way to
say "I really, really mean it this time" when sending a query. :)

> that certainly a cache *should* recurse, but are we confident that

I'm not.

Scott