Subject: Re: Issue: Add a new QTYPE

From: Kevin Darcy <[email-masked]>
Date: Sat, 22 Nov 2003 00:22:27 -0500

Paul Vixie wrote:

>>>Special rules about A/AAAA just seem short-sighted to me.
>>>      
>>>
>>I tend to agree. We already have QTYPE=*, but it has been rendered
>>unreliable because BIND and AFAIK most other implementations never bother
>>recursing for QTYPE=* queries (even as they advertise the RA bit to the
>>client, natch).
>>    
>>
>
>that's just not true.  if a nameserver (bind or any other recursive server)
>gets a QTYPE=* query and it has no rrsets cached for that QNAME then it will
>recurse.  
>
Yes, you're correct. My statement swept too broadly. Recursion will 
happen if nothing is cached for the name.

>however, if it has learned an rrset it will return that rrset even
>though an authority server might return additional rrsets that the recursive
>server has not had occasion to see or store.
>
Right, and _this_ is the part that makes QTYPE=* queries too unreliable, 
since the query results might vary depending on the vicissitudes of 
whatever the caching server happens to have cached at what time. 
Granted, there will always be an irreducible amount of "unreliability" 
whenever one takes caching into consideration, but this should not IMO 
extend beyond the TTL constraints of any *given* RRset. What the current 
behavior does is extend the unreliablity of QTYPE=* queries *across* 
RRsets of differing TTL scales (i.e. just because an RRset with a high 
TTL sits in a cache, it inhibits the resolver's ability to fetch other 
RRsets with possibly much smaller TTLs in response to QTYPE=* queries of 
the same name). IMO this raises the unreliability of the QTYPE to a 
whole new level, and I think it's why QTYPE=* has been abandoned for the 
most part (e.g. by sendmail), even in situations where it could be a 
useful optimization.

>Instead of a new QTYPE, perhaps we just need to tighten up the specs
>to require recursive resolvers to recurse for QTYPE=* queries, when
>necessary (i.e. whenever they are unable to synthesize an answer from
>the cached results of a previous QTYPE=* query).
>
>Whatever resource/capacity reasons, if any, went into the original
>decisions to emasculate QTYPE=* are probably mooted by EDNS0.
>    
>
>
>it wasn't resource/capacity, but rather complexity, which took this
>functionality off the table.  see http://sa.vix.com/~vixie/edns1.txt,
>and the working group minutes from DNSIND.
>
I did dig back through the archives, and saw a message from you 
(<[email-masked] 
<http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01448.html>>) 
admitting that QTYPE=* wasn't really germane ("it was a debugging wish 
rather than an operational expectation") to the RRD-flag part of the 
EDNS1 proposal, and a statement of intention that you were going to 
remove that reference from the draft. There was, however, no subsequent 
published revision of the draft, so the verbiage still remains. As far 
as I can tell, there has been no attempt to clarify QTYPE=* recursivity 
independently of the EDNS1 proposal.

Even having read that old thread, I still don't see the insurmountable 
complexity, in protocol terms, in requiring resolvers to honor their 
recursion obligations with respect to QTYPE=* queries. Either you can 
respond from cached data, or you recurse, same as for any other QTYPE. 
The only complexity that comes to mind is in the implementation's 
housekeeping mechanisms i.e. it needs to keep an independent accounting 
of QTYPE=* queries in order to confirm whether and when 
synthesis-from-cache for subsequent QTYPE=* queries of the same name is 
legitimate. But that is, as they say, merely a matter of programming...

(In the relatively unusual case where a previously-unknown RRset gets 
into the cache before the most recent QTYPE=* pseudo-cache-entry for the 
same name expires (with its expiration to be based on the lowest 
associated RRset's TTL), I'd say just take the conservative approach and 
flush the obviously-invalid pseudo-cache-entry. Folks who rapidly create 
and delete whole RRsets on the fly will just have to tolerate the extra 
traffic this will generate for QTYPE=* queries)

                                                            - Kevin

--
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: Masataka Ohta <[email-masked]>
Date: Sat, 22 Nov 2003 18:07:23 +0900

Kevin Darcy;

> happen if nothing is cached for the name.

What happens if an answer of an empty set for a previous non-wildcard
query is cached for the name?

						Masataka Ohta

---

From: Paul Vixie <[email-masked]>
Date: 22 Nov 2003 18:17:28 +0000

> ...

this was one of the concerns expressed by the wg when it killed RRD and
QDCOUNT>1.  negative caching gets a LOT more complicated when the query
that produced the cached result has to match the query being answered.
-- 
Paul Vixie