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

[Patrick W. Gilmore]

On Mar 31, 2013, at 10:22 , Jim Reid <jim at rfc1035.com> wrote:
> On 31 Mar 2013, at 14:36, "Patrick W. Gilmore" <patrick at ianai.net> 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