Subject: [dnsext] TCP DNS benchmarking, or Who's afraid of TCP?

From: Nicholas Weaver <[email-masked]>
Date: Sun, 23 Aug 2009 13:39:53 -0700

My worry on the UDP fragmentation issue has always been the latency  
hit from the unpredictable timeouts, not the latency hit from TCP  
(simply because 3 RTTs vs 1 is nowhere near the same as a failure- 
timeout).  But I think we can handle that by having the resolver learn  
when it has a fragmentation problem and use a smaller EDNS MTU to  
accommodate this.

	Thus the remaining concern is load on authorities if some fraction  
(say, 10% of queries if it only returns records using DNSSEC >1500B)  
fallback to TCP.

	Has anyone seen how many queries/second a standard Bind configuration  
on vanilla hardware can handle under TCP, both with the default (2  
minute) timeout and a more aggressive 10 second timeout on idle  
connections?

---

From: [email-masked]
Date: Mon, 24 Aug 2009 01:10:31 +0000

On Sun, Aug 23, 2009 at 01:39:53PM -0700, Nicholas Weaver wrote:
> 
> 	Has anyone seen how many queries/second a standard Bind 
> 	configuration  on vanilla hardware can handle under TCP, both with the 
> default (2  minute) timeout and a more aggressive 10 second timeout on idle 
> connections?
> 

	ref the thread on e2e - initiated by Wm Simpson.
	standard bind on vanilla hw is not enough. TCP stack
	performance is really OS dependent.

	also - a 10sec timeout violates the DNS spec ... it has
	to be the 2min timeout.

--bill

---

From: Nicholas Weaver <[email-masked]>
Date: Sun, 23 Aug 2009 20:41:12 -0700

> 	performance is really OS dependent.

Do you have a URL for this thread?

And for typical (eg, Linux, BSD)?

> 	also - a 10sec timeout violates the DNS spec ... it has

This is one of those cases where if you violated the spec, so what?   
It should only be happening for resolvers with busted middleboxes, so  
who cares about their reinitiation latency on a 10s timeout vs 2  
minutes?

---

From: [email-masked]
Date: Mon, 24 Aug 2009 04:39:30 +0000

> Do you have a URL for this thread?

	List-Archive: <http://mailman.postel.org/pipermail/end2end-interest>
 
> And for typical (eg, Linux, BSD)?

	no idea what the limits are - there are 1000s of research papers
	that touch the subject.

> who cares about their reinitiation latency on a 10s timeout vs 2  

	er...  not so much.  back when the spec was written, the
	idea of and deployment of middleboxes was rare indeed.
	there must have been another reason for the 2min timeout.

	moving to TCP is a massive multiplier on consumption of system
	resource.   thats a huge cost for operations.

	the cost has to be pushed back to the edge.
	
--bill

---

From: Mark Andrews <[email-masked]>
Date: Mon, 24 Aug 2009 14:46:57 +1000

> who cares about their reinitiation latency on a 10s timeout vs 2  

Except it isn't just these clients.  It's also plain DNS clients that
need to get a answer > 512.

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

---

From: Paul Vixie <[email-masked]>
Date: Mon, 24 Aug 2009 06:50:04 +0000

> From: Nicholas Weaver <[email-masked]>
> Date: Sun, 23 Aug 2009 20:41:12 -0700
> 
> > 	also - a 10sec timeout violates the DNS spec ... it has to be the
> > 	2min timeout.
> 
> This is one of those cases where if you violated the spec, so what?  It
> should only be happening for resolvers with busted middleboxes, so who
> cares about their reinitiation latency on a 10s timeout vs 2 minutes?

notwithstanding the fact that we can change the spec, and we must if we
want tcp to be available, the problems will be felt beyond those who are
behind busted middleboxes.  right now it's correct to syslog() in the
requestor when the responder closes a tcp/53 session.  that's got to
change.  and it's not just a timeout value.  if a responder knows it can
only talk to N tcp initiators simultaneously, then at some point near
N-1 it has to shorten the timeouts, all the way to zero if necessary.

attackers in the current spec need only open some long running initiators
who do nothing or who do things very slowly.  we have to raise that bar
or we just make the whole thing into a shiny new ddos target.  make them
open lots of sessions continuously, make them send queries soon after they
open, insist that those queries be valid, insist that the receive windows
be large enough for a response, and then be ready to close immediately
after sending a response depending on how many connection slots are full,
and do NOT keep the tcb around for 2*MSL (so, forget about FIN_WAIT_2).

even so we will need something like djb's tcp cookies if we find no other
solution to the fragmentation problem and are forced to rely on tcp here.

---

From: Michael Graff <[email-masked]>
Date: Mon, 24 Aug 2009 16:14:20 -0500

> and do NOT keep the tcb around for 2*MSL (so, forget about FIN_WAIT_2).

I will ask this in another thread.  How is this at all any difference
than what we have today, as an attack vector?  This is not the future
threat, it is a current one.

It's not a shiny new target, that is.

- --Michael

---

From: Paul Vixie <[email-masked]>
Date: Tue, 25 Aug 2009 00:17:57 +0000

> Date: Mon, 24 Aug 2009 16:14:20 -0500
> From: Michael Graff <[email-masked]>
> 

it's not a target today.  to be a target you have to be attractive, which
means if somebody blows it up it'll be missed.  the moment someone adds a
dependency on tcp/53 in any part of the dns design, the weakness of the
target will become the fatness of the target.