On Mar 31, 2013, at 08:32 , Jim Reid <[email protected]> wrote: > On 31 Mar 2013, at 10:30, Xun Fan <[email protected]> wrote:
>> So do you think "force TCP for external queries to OR" is a feasible >> solution to DNS reflect amplification problem? > > It's a nice idea that's worth trying. > > I'm not sure it will make a difference though. The bad guys won't bother to > do TCP for the obvious reason and will stick with their current, DNS protocol > conformant, behaviour. > > Remember too that in these DDoS attacks truncated UDP responses would still > be going to spoofed addresses. So those victims still get hit, albeit without > the amplification factor of a chubby DNS response. > > I expect TCP to an anycast resolver -- say 8.8.8.8? -- will prove tricky for > long-lived connections. CloudFlare, CacheFly, and a few other CDNs who anycast web server addresses would probably disagree. > 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. > 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? -- TTFN, patrick P.S. I make no comment on the original suggestion. Personally, I am leaning towards it not being a good idea, but haven't thought about it enough to be certain. _______________________________________________ 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
