Re: [dns-privacy] Multiple DNS requests per packet, multiple packet responses

[Mark Andrews <[e-mail]>]

In message <[e-mail]>
, Phillip Hallam-Baker writes:
> On Wed, Mar 19, 2014 at 2:06 PM, Tony Finch <[e-mail]> wrote:
> 
> > Phillip Hallam-Baker <[e-mail]> wrote:
> > >
> > > In particular, if we let a DNS query ask more than one question at a
> > > time then we improve latency of responses.
> >
> > No need to change the protocol, just make the queries concurrently. If
> > your implementation makes that slow, fix the implementation. You would
> > have to fix it anyway in order to support the protocol changes, so you
> > might as well do the fix without the protocol change. No need to waste
> > time and money on talking about paper protocols.
> >
> 
> This is not a change. It is implementing RFC1035 as written.
> 
> BIND and co have done it wrong all these years. If the implementations are
> not wrong then where is the RFC that states QDCOUNT = 1?

The HEADER is future proof.  The protocol is written for QDCOUNT = 1 for QUERY.
The HEADER does NOT support QDCOUNT != 1 for general <QNAME,QTYPE,QCLASS> in
the query section.  There is no defined behaviour for fixed <QNAME,QCLASS>
and variable <QCLASS>.
 
> I have talked to the engineers at several browser companies and they tell
> me that parallel queries do not actually work the way you imagine.
> 
> In the first place it is only possible to issue the queries at all if you
> override the built in platform API. But even when you do, problems are
> caused by middleboxes and ISPs which limit the number of concurrent queries.

Total BS.  There are system resolvers that are thread aware.  Fire
off # threads in parallel then join. 

> For a resolver, the change is cheap. The benefit to the client is enormous.
> 
> 
> -- 
> Website: http://hallambaker.com/
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]