Subject: Re: Issue: Add a new QTYPE

From: Kevin Darcy <[email-masked]>
Date: Fri, 21 Nov 2003 18:51:10 -0500

Michael Richardson wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>
>
>I'd rather that we just defined a QTYPE of "all" which just returns
>everything. Given IPSECKEY and SSHKEY and other possible stuff, this
>just makes sense to me. Particularly for the client stub resolver to do.
>
>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). 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.

-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: "D. J. Bernstein" <[email-masked]>
Date: 22 Nov 2003 00:20:08 -0000

Kevin Darcy writes:
> We already have QTYPE=*, but it has been rendered unreliable because BIND

BIND is under no obligation to support your delusions regarding QTYPE=*.
RFC 1034, section 6.2.2, has a clear example of a cache providing _some_
of the SRI-NIC.ARPA records in response to a SRI-NIC.ARPA QTYPE=* query.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 21 Nov 2003 20:51:53 -0500

>of the SRI-NIC.ARPA records in response to a SRI-NIC.ARPA QTYPE=* query.
In response to a *non-recursive* (RD=0) query, yes (see the second 
sentence of the Section 6.2 intro). That doesn't disprove my point in 
the slightest. I certainly wouldn't expect a resolver to provide 
recursion that wasn't requested in the first place...

- Kevin