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

Xun Fan xunfan at isi.edu
Sun Mar 31 16:42:18 UTC 2013

On Sun, Mar 31, 2013 at 5:32 AM, 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 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?

> I expect TCP to an anycast resolver -- say -- will prove tricky
> for long-lived connections.

My post solutioin is mostly for those open resolvers that are going to shut
down external queires. Resolvers like 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.

> 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.
> 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....

Yes, and there are always someone got hurt, coffee/hotel guy, or those
suffer DNS amp attack.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20130331/060af776/attachment.html>

More information about the dns-operations mailing list