Subject: [dnsext] Support for 1RTT multi-queries over TCP (or lack thereof)

From: Tony Finch <[email-masked]>
Date: Wed, 18 Dec 2013 12:18:05 +0000

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.

$ 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.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  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.

---

From: Dick Franks <[email-masked]>
Date: Thu, 19 Dec 2013 13:22:09 +0000

In order to achieve parallelism you seem to desire, the transactions need
to be mutually order independent.

You will first need to free yourself from the ordering imposed by the TCP
stream; a mighty TCP river with many sockets, the TCP equivalent of the
Nile delta.  Just the thing for DOS attacks!

Perhaps disappointment(1) would be better directed at adns for offering
what it is unable to deliver.

Disappointment(2) would be justified only if the computational cost of the
occasional wasted queries exceeded the cost of monitoring connections which
are rarely dropped.

Dick Franks
________________________

On 18 December 2013 12:18, Tony Finch <[email-masked]> wrote:

> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
>

---

From: Tony Finch <[email-masked]>
Date: Thu, 19 Dec 2013 13:23:54 +0000

> to be mutually order independent.

That is what the query ID is for.

Tony.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 20 Dec 2013 00:49:04 +1100

In message <[email-masked]>, Tony F
> 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.

> 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.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]