[AusNOG] "stateless TCP" for DNS

[Terry Manderson]

Hi Grenville,

On 12/11/2010, at 2:43 PM, grenville armitage wrote:

> AusNOG,
> 
> The nett effect for the DNS server is significantly reduced
> resource consumption relative to handling TCP-based DNS requests
> using regular TCP.
> 
> Why would clients use TCP for DNS queries? We're envisaging a
> future where DNSSEC and/or IPv6 results in lots of DNS answers
> larger than 512 bytes, resulting itself in lots of problems for
> UDP-based DNS exchanges. DNS clients migrate to using TCP for
> transport, and your DNS server melts.
> 

The 2009 OARC DITL analysis showed that, at the time, 65% of resolvers used a message size of 4096.
At a meeting at IETF in Beijing last week someone suggested that they see 70% of queries, I don't have any data to support this but it seems plausible that there is a growth in EDNS support. Further, in reading the paper "Improving DNS performance ... in FreeBSD" I got stuck on the suggestion in the paper which says "Most DNS servers are configured to allow only a maximum UDP packet size of 512 bytes", I assume you mean RFC1035 section 2.3.4 "will not output a packet longer than 512 bytes long". However we do have EDNS (RFC2671) which is not mentioned in the paper. The current default for edns-udp-size in bind is 4096. And surely as DNSSEC is deployed, requiring new(er) DNS server releases, server response size capability will be on an incline.

That obviously doesn't address the MTU fragmentation concerns that are highlighted in the paper, but how much should we protect entities with poor performing network equipment from real development that is intended to improve the security of the DNS naming system?

Don't get me wrong. I think it is kinda cute to create a TCP-lightweight proxy to attempt to bypass the on path MTU-isms. But is that enough of an incentive to mask the problem instead of fixing it? Maybe, maybe not.

I would also suggest that it is an overstatement that your DNS server would melt. The default tcp-clients value in bind9 is 100 (simultaneous). I think simply this represents a client problem, as the nameserver configured out of the box will hardline TCP clients at 100 and care not, so probably not so much a server problem as I see it.

> The project is at http://caia.swin.edu.au/ngen/statelesstcp/,
> including a tarball of patches to FreeBSD 9.

In regard to the first conclusion in the paper.

This really isn't a problem with DNS. It is a MTU problem in middleware that DNS triggers which has ramifications to DNS clients on the internet who might be stuck behind firewalls and other boxes that do the wrong thing. The real issue here is about service to a DNS client. Unless a DNS client uses TCP from the outset, the query will be done on UDP, some DNS dancing (retry/timeout etc) to get a TCP response. I would posit that by the time this has happened the resource concern on a DNS server is minor.

There is also a DNS specific discussion on this in rfc3226.

It might also be worthwhile reading the paper from 2003 suggesting transactional tcp for dns based on motivations to limit security (ddos) events. http://www.ne.jp/asahi/bdx/info/depot/IPSJ-JNL4408024-k2r.pdf

The next thought I have, is along the lines of the good old SYN flood attack.. or other security facets... :-)

Cheers
Terry