Re: Support for 1RTT multi-queries over TCP (or lack thereof)

Mark Andrews <[email protected]> Fri, 20 Dec 2013 00:49:04 +1100
Newsgroups gmane.ietf.dnsext
Message-ID <[email protected]>
In message <[email protected]>, Tony F
inch writes:
> I saw a message to the unbound-users list which says unbound processes TCP
> queries sequentially.
> 
> http://unbound.nlnetlabs.nl/pipermail/unbound-users/2013-December/003096.html
> 
> I thought this was disappointingly poor, especially wrt the recent
> discussion about backwards-compatible alternatives to edns-chain-query. So
> I did a quick test to see if BIND has the same problem. I shoved a few
> entries from the Alexa Top 1 Million list into adns as follows.

And edns-chain-query is primarially worried about getting the DNSSEC
records required to validate a response. You do not need asynchronous
processing in a nameserver for this.  The nameserver should be
validating the initial query (cd=0 despite what is written in a
recent rfc) which will trigger most the asyncronous lookups needed
and the queued lookups are just filled from the cached data.

Add to that asynchronous processing then required more complicated
response handling so that each message is added to the TCP stream
atomically.  Now one could do that but there is little benefit once
you get more that a couple of simultaneous TCP clients.

> $ sed 's|^[0-9]*,||;s|/.*||' top-1m.csv | head -100 |
>   adnshost --cname-loose --asynch --pipe
> 
> Over UDP you can clearly see the response serial numbers are out-of-order,
> and the whole thing runs in about 3 seconds with a cold cache.
> 
> If I add --tcp to the adnshost command line the responses come back
> strictly in order and BIND processes them one at a time. Processing all
> the queries takes more than 30 seconds, so adns times out before getting
> responses to the last 25 queries. (When you invoke adnshost like this it
> does not by itself do anything to limit the number of outstanding
> queries.) In addition to that, named fails to notice that the TCP socket
> has gone away and continues to process queries. (I will report this as a
> bug.)
> 
> So that is doubly disappointing.

And how this is different to a UDP source which sends queries without
listening to the responses?  Both can get named to do work.  Add
to that there isn't really a way in TCP to say I've closed my read
side which is not also a spoofable dos vector for still open
connections.

> Tony.
> -- 
> f.anthony.n.finch  <[email protected]>  http://dotat.at/
> Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
> Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
> occasionally poor at first.
> _______________________________________________
> dnsext mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email protected]
_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext