On Mar 31, 2013, at 10:22 , Jim Reid <[email protected]> wrote: > On 31 Mar 2013, at 14:36, "Patrick W. Gilmore" <[email protected]> wrote:
>> CloudFlare, CacheFly, and a few other CDNs who anycast web server addresses >> would probably disagree. > > Yeah. We both know we have had those discussions before Patrick and > (hopefully) agreed to disgagree. :-) You are welcome to disagree, but you are not disagreeing with me. Neither I nor my company use anycasted TCP services. (We do anycast name servers, which I guess could be considered TCP since there is fallback.) Lots of other companies do, and they claim it works. Perhaps you should ask them if they - and their clients - are confused and this really doesn't work? Because empirical evidence trumps arguments on a mailing list. >>> Keeping state for bazillions of DNS TCP connections to a resolving server >>> will present further challenges. [Maybe TCPCT could help.] That could lead >>> to a new DoS attack vector: overwhelming a resolving server with too much >>> TCP traffic. Though that could be done already I suppose. >> >> Shouldn't be difficult to keep TCP in a different thread or process, so UDP >> is unaffected. > > Isolating TCP and UDP traffic at the DNS server is not the issue I think. > Keeping bazillions of protocol control blocks (or equivalent) in the kernel, > one for each TCP connection, is. Though I'd welcome getting told I am wrong > about that. Those PCBs have to stick around for twice the maximum segment > life time, typically a minute or more. DNS over TCP could easily mean > resolvers handling orders of magnitude more connections (ie PCBs) than the > busiest of web servers. A DNS server getting ~10Kqps over TCP would have > around 1 million "active" PCBs in the kernel: nasty. Someone else pointed out web servers do this. OTOH: Web servers tend to be a bit beefier than name servers. So this is really just a CapEx discussion. But like I said, I do not think it is a good idea anyway. >>> Another problem is lots of crapware -- CPE, hotel networks, coffee shop >>> wi-fi, etc -- assume DNS is only ever done over UDP. Anyone stuck behind >>> that already loses whenever they get a truncated response. They'll have >>> much bigger problems if resolving servers default to truncation and TCP >>> retries for everything. I suppose more use of DNS over TCP could provide an >>> incentive to get those broken middleboxes fixed. Wouldn't hold my breath >>> though.... >> >> Maybe it would be an incentive to fix those broken clients? > > It's not the users' clients that are broken. [Though they may be bust too.] > It's the middleware crap that these clients sit behind: the DSL or cable box > that the typical Internet user has or the hotel/coffee-shop network that > mangles DNS packets. I already said forcing DNS over TCP could provide an > incentive to get those middleware devices fixed but doubted this would ever > happen. Good luck getting a Wal-mart or Verizon (say) to beat up their > Chinese suppliers for shipping DSL boxes that constrain DNS to UDP packets of > less than 512 bytes. The OP suggested forcing TCP for off-net users only. If those clients are on-net, they won't need TCP, and the crapware doesn't matter. If they are off-net, they are broken clients, and need to be fixed. Either way, the crapware is not an issue. (To this idea. We both agree the crapware is, well, crap. :) -- TTFN, patrick _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
