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

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Mar 19, 2014 at 2:34 PM, Paul Wouters <[e-mail]> wrote:
> On Wed, 19 Mar 2014, Phillip Hallam-Baker wrote:
>
> [ still finding your replies to replies basiclly unreadable due to your
>   email client quoting settings, so if I'm mis-attributing, thats why.
>   When these go like 3 deep, I basically have to just give up and delete
>   the emails unread. You are the only person I have this problem with,
>   and plenty of people use gmail.]
>
>
>> 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?
>
>
> We tested this a few months ago while discussing
> draft-wouters-edns-keepalive using
> a modified dig command.
>
> All servers support multiple queries at once fine. Only google dns
> capped it at 80 queries before closing the connection. Things will be
> different when the TCP connection is idle of course, as the server might
> hang up on you, hence the above mentioned draft to match up client and
> server behaviour.

Wow, so we have the capability there in the infrastructure but people
are saying that they can't check for DANE records or other policy
records and other people are saying that we shouldn't 'change' the
protocol?


>> 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.
>
>
> All the more reason for draft-wouters-edns-keepalive (and
> draft-wouters-edns-chain-query)

That looks like a perfectly sensible suggestion. But I would prefer to
avoid going to TCP unless it is absolutely necessary.

If we go to TCP then the shortest distance between two points is to
make DNS a Web Service and run it over TLS. Now I do in fact do
precisely that in OmniBroker to provide a 'last ditch' resolution
service for cases where the user is stuck behind a hotel portal. But I
was hoping to avoid that for DNSE.



-- 
Website: http://hallambaker.com/