<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Mar 31, 2013 at 5:32 AM, Jim Reid <span dir="ltr"><<a href="mailto:jim@rfc1035.com" target="_blank">jim@rfc1035.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 31 Mar 2013, at 10:30, Xun Fan <<a href="mailto:xunfan@isi.edu">xunfan@isi.edu</a>> wrote:<br>

<br>
> So do you think "force TCP for external queries to OR" is a feasible<br>
> solution to DNS reflect amplification problem?<br>
<br>
</div>It's a nice idea that's worth trying.<br></blockquote><div><br></div><div>Thanks!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<br>
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.<br></blockquote>
<div><br></div><div>I don't know if all truncated UDP should be the full length of 512, if not, then we could do a short UDP with truncate flag set to 1?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
I expect TCP to an anycast resolver -- say 8.8.8.8? -- will prove tricky for long-lived connections.<br></blockquote><div><br></div><div>My post solutioin is mostly for those open resolvers that are going to shut down external queires. Resolvers like 8.8.8.8 definitly won't force TCP... At the end, whether or not to shutdown open resolvers is decided by the administrators of those open resolver, they cloud perform according to their own situation.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>

<br>
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....<br>
</blockquote><div><br></div><div>Yes, and there are always someone got hurt, coffee/hotel guy, or those suffer DNS amp attack.</div><div> </div></div><br></div></div>