[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 / a way forward



Ray

----- Original Message -----
From: Ray.Bellis@nominet.org.uk

> FWIW, yesterday I performed some benchmark tests against Bind 9.6.

> Over TCP/IP I was able to do 3000 qps. 
> The same server will do about 23000 qps over UDP.

I think this is all well and good, FWIW, I think TCP will work ok, most of the time.
I don't think load from legitimate/friendly traffic is a major concern.

Some questions in my mind though :

(1) Even if it is theoretically possible to harden a TCP implementation against
DoS attacks, do we in practise have the expertise? It's a complex undertaking.

https://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf

(2) Using TCP implies extra latency, unless connections can be held open for
long periods ( which I think is worth studying ). I'd like to go as fast as possible.
I have been testing my QRP proposal, and it's nice that there is no discontinuity in
perfomance once replies exceed 1,500 bytes - you get results in a single round
trip up to 6,000 bytes. Speed is important for DNS.
 
(3) If packet loss is significant, I think TCP may struggle. I have been testing QRP
with 30% packet loss, where it still achieves acceptable performance.

I'm not arguing against TCP, rather that a high-performance/robust UDP
solution can and should be developed as well as making TCP a requirement
(which I support). I'm quite happy (and see the necessity) for people to travel
slowly along the old roads, but I want to also build a motorway for going fast
safely and reliably, even when the weather is bad.
 
I have just updated

http://tools.ietf.org/html/draft-barwood-dnsext-dns-transport
 
The idea is to have an experimental protocol that is reasonably well understood
and tested, so that we properly understand what the options really are.
 
Regards,
George