[dns-operations] Force TCP for external quereis to Open Resolvers?

[Patrick W. Gilmore]

On Mar 31, 2013, at 08:32 , Jim Reid <jim at rfc1035.com> wrote:
> On 31 Mar 2013, at 10:30, Xun Fan <xunfan at isi.edu> 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.