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

From: Samuel Weiler <[email-masked]>
Date: Fri, 3 Jun 2005 08:47:00 -0400 (EDT)

On Tue, 24 May 2005, Edward Lewis wrote:

> So - in summary, what I am saying is that you should only return
> NOERROR/NODATA for a qtype=* when the name is a previously sought
> empty non-terminal, in the negative cache.  The existence of names
> ought never be inferred by a cache, if a name is not explicitly in
> local information, and recursion is permitted, the server ought to
> recurse.

I think I agree with Ed here.

Would you gentlemen take a look at the new bis-updates doc and see if
Section 2.3 is adequate?  I know it doesn't capture all of the
subtlety discussed in this thread, but I'm thinking it still might be
adequate for most readers.  Here it is, for ease of reference:

2.3  Validating Responses to an ANY Query

   RFC4035 does not address now to validate responses when QTYPE=*.  As
   described in Section 6.2.2 of RFC1034, a proper response to QTYPE=*
   may include a subset of the RRsets at a given name -- it is not
   necessary to include all RRsets at the QNAME in the response.

   When validating a response to QTYPE=*, validate all received RRsets
   that match QNAME and QCLASS.  If any of those RRsets fail validation,
   treat the answer as Bogus.  If there are no RRsets matching QNAME and
   QCLASS, validate that fact using the rules in RFC4035 Section 5.4 (as
   clarified in this document).  To be clear, a validator must not
   insist on receiving all records at the QNAME in response to QTYPE=*.

-- Sam

--
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 09:57:07 -0400

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

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

Scott

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Samuel Weiler
>

---

From: Paul Vixie <[email-masked]>
Date: Fri, 03 Jun 2005 15:28:06 +0000

> I think I agree with Ed here.

me too.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 3 Jun 2005 14:41:54 -0400

>    insist on receiving all records at the QNAME in response to QTYPE=*.

I'm a little puzzled by the need for a bis-updates document at this point.

For instance, the last sentence is not an update to the protocol but 
an reminder to implementers of something that is already plainly 
evident in the protocol definition.  By plainly evident I mean that I 
can't think of any implementation to date that equates qtype=any with 
"all."

I would say that serious work on an updates document ought to be held 
until there is demonstrated evidence of a need to clarify the 
original specifications.  I think that incrementally trying to stamp 
out all foreseen bugs may work against a true test of the quality of 
the documents.

There's something to be said for isolated development coming together 
in a bake-off and documenting the identifiable issues.  Why had no 
one noticed that the bit position for the, what, CD and AD, bits been 
omitted?  Maybe because we've all become a bit too chummy in the 
process.

Being chummy is fine.  But sometimes we tend to trust each other too much.

Another reason I am surprised that such a document is progressing now 
is that documents sometimes peak too early.  The first operation 
practices document for DNSSEC in DNSOP was begun by me on a plane 
coming home from the 1999 Minneapolis IETF.  Yeah, a doomed effort if 
there ever was one.  (It was based on 2065 semantics, or maybe 2535.) 
Even though the document was known to be needed then, it wasn't the 
time for it yet.

I think discussing implementation faults is good, but I'd lag on the 
document effort for sometime.  I think the experience gained is not 
yet ripe - and I wouldn't want to stunt an effort that might diverge 
from current popular sentiment that later proves to the the right way.

Getting back to the issue at hand though, I really don't see a 
clarification here at all.  Assuming we have a bad answer cache (as 
opposed to a negative cache and a good answer cache), then some part 
of the answer smells funny, it's funny - whether it's a specific type 
query or a qtype=any query.  As per usual, a negative answer is a 
negative answer and needs to be treated as such.

Looking back at the 4035 document, does it ever mention that there be 
a relationship between the QTYPE in the QUERY section and the RR's in 
the ANSWER section?  I don't see it.

I also don't see treatment of "bogus" messages ("treat the answer as 
bogus"), just "bogus" RRSets.

So - I am not sure what we are trying to update or clarify here.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.