Re: Issue: Add a new QTYPE

[Kevin Darcy <kcd@daimlerchrysler.com>]

Paul Vixie wrote:

> > ... 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.
> >    
>
> sendmail was incorrect in its usage of QTYPE=* and when they "abandoned"
> it, it was to fix the bug in their code where they had used it at all.
>
>  
>
> > > ... 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
> > <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.
> >    
>
> the draft is expired.  the DNSIND working group decided to scrap everything
> therein.  my offer to pull out RRD was insufficient; the wg wanted the whole
> thing killed.
>
>  
>
> > As far as I can tell, there has been no attempt to clarify QTYPE=*
> > recursivity independently of the EDNS1 proposal.
> >    
>
> there is no way to "clarify" QTYPE=* short of a protocol extension.  the
> current behaviour is perfectly well understood and there are no incorrect
> implementations of it.  there's no document quality issue around QTYPE=*,
> and all extant implementations are fully interoperable regarding QTYPE=*.
Paul,
        The current behavior is fine as long as one puts on blinders 
with respect to correctness and completeness of answer content. In my 
opinion, giving out a known-incomplete answer to *any* query, when a 
complete answer is available via recursion and where recursion was both 
requested and its availability advertised, is a violation of the spirit 
if not the precise wording of the standards (and let's face it, RFC 
1034&1035 leave a lot to the imagination wrt how QTYPE=* queries are 
actually supposed to work). Just as partial-RRset answers were outlawed 
in in RFC 2181, partial answers at owner-name level (i.e. with RRsets 
missing) should never IMO be returned to recursive QTYPE=* queries either.

The fact that all extant implementations (arguably) violate the standard 
in the same, interoperable way does not mean the behavior is correct -- 
that is, after all, the defining difference between _de_facto_ standards 
and _de_jure_ ones.

More importantly, a faithful implementation of QTYPE=* recursivity might 
rescue that QTYPE from its current state of dubious usefulness (at best) 
and/or near-obsolescence (at worst), and put an end to all of these 
new-metatype proposals without the overreaching that EDNS1 represented 
or was perceived to represent. I can understand why you'd be bitter 
about how EDNS1 turned out, but that doesn't mean a more modest 
approach, one that stays within the existing RFC 1034/1035 framework 
without requiring extensions, can't or shouldn't work.

                                                                        
                          - Kevin



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