Re: [DNSOP] Why no more meta-queries? (Was: More work for DNSOP :-)

[Shumon Huque <[e-mail]>]

On Mon, Mar 9, 2015 at 12:05 PM, Ray Bellis <[e-mail]>
wrote:

>
> > On 9 Mar 2015, at 14:28, Stephane Bortzmeyer <[e-mail]> wrote:
> >
> > On Fri, Mar 06, 2015 at 08:59:20PM +0000,
> > Evan Hunt <[e-mail]> wrote
> > a message of 28 lines which said:
> >
> >> (As an aside: I've often wondered why the DNS doesn't have *more*
> >> meta-query types, less extensive than ANY, such as a single type
> >> covering A and AAAA.
> >
> > Probably for the same reason that makes QTYPE=ANY queries very
> > difficult to understand for the beginner and counter-intuitive:
> > because it is hard to specify the semantics. Imagine there is an ADDR
> > meta-query covering A and AAAA. You send QTYPE=ADDR and you get only A
> > record(s). Can you be *sure* (and can you validate with DNSSEC) that
> > there was no AAAA? Think of the various cases, RD=0, RD=1, caches,
> > forwarders, etc.
>
> I wrote this a few years ago:
>
> http://tools.ietf.org/html/draft-bellis-dnsext-multi-qtypes-01
>
> The primary stumbling block was the possibility (given DNSSEC) for
> multiple different RCODEs for the different QTYPEs being requested.
>
> I couldn't think of any failure modes in the non-DNSSEC case, but with
> signed data it's theoretically possible to have valid signatures for the
> owner name on one QTYPE and invalid signatures on another.
>
> Ray
>

Interesting idea. I think it's worth discussing these kinds of proposals in
more depth. To account for the multiple distinct response codes case, one
possibility is to carry an extended "response code array" in an EDNS
option. Clients already have to sometimes parse EDNS to get extended
response codes today, so we have one foot in that direction already. And
this could also support the more general case of multiple distinct query
names (not just multiple query types for the same name). There might be a
usecase for this in some application communities (like web browser vendors)
that are highly resistant to performing additional DNS queries for
additional latency reasons (eg. execute in one query: A/AAAA +
corresponding TLSA record which sits at a different qname).

PS. regarding Paul Vixie's recent suggestion of adding an AAAA or A record
set in the additional section for a corresponding A or AAAA query, I just
learned today that Unbound already does this. Not sure if there are any DNS
client APIs that can successfully make use of this info yet.

Shumon Huque.