4 ms·

Absolutely, but I would say that this has the potential to be a lot more secure than a traditional (full) TCP/IP stack. Most queries are UDP (one packet), and

Absolutely, but I would say that this has the potential to be a lot more secure than a traditional (full) TCP/IP stack. Most queries are UDP (one packet), and we would expect that TCP connections should only last a few packets. TCP connections that don't match a handful of patterns would be suspicious (IMHO) and should probably just be dropped. Of course, then you find some weird version of Windows XP that this breaks :-(

jvehent 12y ago
> TCP connections that don't match a handful of patterns would be suspicious (IMHO) and should probably just be dropped. I used to believe that. It is unfortunately not true. TCP packets will come in all shapes and forms, and all must be treated equally, which is what makes TCP stacks so incredibly complex to implement. The Linux TCP stack is quite safe and fast. Especially with tight integration with NICs hardware (checksum offloading and the like). I'm a bit unsure what a custom stack in userland can provide that the standard kernel stacks don't have.
- thirsteh 12y ago
  Performance. This isn't for security, or it wouldn't be yet another critical piece of software written in C.
- tptacek 12y ago
  Can you be more specific about the different-but-equal forms TCP packets take? You can dive into the details; I've implemented TCP stacks too.
- robertgraham 12y ago
  The Linux TCP stack is NOT fast. My DNS server can respond to DNS queries faster than the simplest of in-kernel echo servers (like ICMP ping or UDP port 7 echo). That's with the entire DNS overhead of parsing the DNS protocol, looking up the name in a very large database (like the .com zone), doing compression, and generating a response. The upshot is this: going through the Linux stack, a DNS server is limited to around 2 million queries/second. Using a custom user-mode stack, it can achieve 10 million queries per second.
  - modusponens 12y ago
    Do you have any insight about how other stacks fare on that same workload? (*bsd, qnx, ms-windows, minix,osx...)
nitinics 12y ago
With the advent of DNSSEC, IPv6 and EDNS0 you're more likely to see DNS responses >512 bytes, therefore falling back to TCP (with truncate bit set). Therefore it is strongly recommended you do not drop/block tcp 53 on your middleboxes , firewalls etc.
- justinsb 12y ago
  Sure; I'm not suggesting dropping TCP entirely, just that e.g. a 1MB request / response is not going to be legitimate, and so you can simply not implement a lot of TCP's complexity (e.g. window scaling)
- colmmacc 12y ago
  EDNS0 includes a mechanism for clients/resolvers to signal that they can handle a large/fragmented UDP response. At this point about 85% of requesters can handle UDP responses of at least 4K. For the moment, DNSSEC and EDNS0 are making falling back to TCP far less common than it used to be. That may change, as some providers are starting to put smaller limits on their response sizes (to mitigate certain kinds of DDOS and response spoofing attacks). Of course permitting TCP 53 is required for DNS to work; as is permitting UDP fragments (which poorly configured firewalls often block too).
- zaroth 12y ago
  Another interesting use-case for TCP in DNS is for anti-DDoS. If a botnet is abusing your DNS server to flood traffic to their target, flipping the 'TC' bit which will force the request to come back over TCP, exposing the spoof. My long-winded write-up here: http://opine.me/cert-advisory-on-dns-amplification-offers-little-hope/ http://opine.me/cert-advisory-on-dns-amplification-offers-li...
  - jamiesonbecker 12y ago
    Very interesting, thx for the link!

jvehent 12y ago

> TCP connections that don't match a handful of patterns would be suspicious (IMHO) and should probably just be dropped. I used to believe that. It is unfortunately not true. TCP packets will come in all shapes and forms, and all must be treated equally, which is what makes TCP stacks so incredibly complex to implement. The Linux TCP stack is quite safe and fast. Especially with tight integration with NICs hardware (checksum offloading and the like). I'm a bit unsure what a custom stack in userland can provide that the standard kernel stacks don't have.

thirsteh 12y ago
Performance. This isn't for security, or it wouldn't be yet another critical piece of software written in C.
tptacek 12y ago
Can you be more specific about the different-but-equal forms TCP packets take? You can dive into the details; I've implemented TCP stacks too.
robertgraham 12y ago
The Linux TCP stack is NOT fast. My DNS server can respond to DNS queries faster than the simplest of in-kernel echo servers (like ICMP ping or UDP port 7 echo). That's with the entire DNS overhead of parsing the DNS protocol, looking up the name in a very large database (like the .com zone), doing compression, and generating a response. The upshot is this: going through the Linux stack, a DNS server is limited to around 2 million queries/second. Using a custom user-mode stack, it can achieve 10 million queries per second.
- modusponens 12y ago
  Do you have any insight about how other stacks fare on that same workload? (*bsd, qnx, ms-windows, minix,osx...)

nitinics 12y ago

With the advent of DNSSEC, IPv6 and EDNS0 you're more likely to see DNS responses >512 bytes, therefore falling back to TCP (with truncate bit set). Therefore it is strongly recommended you do not drop/block tcp 53 on your middleboxes , firewalls etc.

justinsb 12y ago
Sure; I'm not suggesting dropping TCP entirely, just that e.g. a 1MB request / response is not going to be legitimate, and so you can simply not implement a lot of TCP's complexity (e.g. window scaling)
colmmacc 12y ago
EDNS0 includes a mechanism for clients/resolvers to signal that they can handle a large/fragmented UDP response. At this point about 85% of requesters can handle UDP responses of at least 4K. For the moment, DNSSEC and EDNS0 are making falling back to TCP far less common than it used to be. That may change, as some providers are starting to put smaller limits on their response sizes (to mitigate certain kinds of DDOS and response spoofing attacks). Of course permitting TCP 53 is required for DNS to work; as is permitting UDP fragments (which poorly configured firewalls often block too).
zaroth 12y ago
Another interesting use-case for TCP in DNS is for anti-DDoS. If a botnet is abusing your DNS server to flood traffic to their target, flipping the 'TC' bit which will force the request to come back over TCP, exposing the spoof. My long-winded write-up here: http://opine.me/cert-advisory-on-dns-amplification-offers-little-hope/ http://opine.me/cert-advisory-on-dns-amplification-offers-li...
- jamiesonbecker 12y ago
  Very interesting, thx for the link!