Good call out. Maybe parent is just loosely referring to larger TXT records (or maybe DNSSEC or ipv6?) etc. My guess is that even these are probably a relatively small percentage of overall DNS traffic and that's not likely to change anytime soon.
So I can't imagine why records would all of a sudden exceed 512 bytes on avg either.
UDP isn't as reliable on mobile connections, many mobile clients issue TCP DNS requests with the UDP request at the same time and not waiting the "casual 5 seconds time out".
DNS records also seem to grow and EDNS has not been adopted very well.
Other things like Crhome's async DNS prefetch also seem to use TCP as much as UDP for some reason, especially to google DNS servers.
The updated RFC mandates TCP support for regular DNS, and although i don't have a single reason (other than IPV6 records, TXT records use and DNSSEC) for why i have a strong feeling that mobile and browser optimizations are a good reason for that.
When your browser does DNS pre-fetch from the DOM it becomes much more efficient to open a single TCP connection and issue all of the DNS requests (and with CDN's, adds, capthcas, social media and 3rd party content you can easily get to 20+ distinct DNS records per page) over it rather than issue individual async DNS queries over UDP.
This will both be faster and more importantly more reliable for the next step which is the TCP-preconnect once it has resolved all the DNS records from the DOM even before loading it fully.
When your browser does DNS pre-fetch from the DOM it becomes much more efficient to open a single TCP connection and issue all of the DNS requests (and with CDN's, adds, capthcas, social media and 3rd party content you can easily get to 20+ distinct DNS records per page) over it rather than issue individual async DNS queries over UDP.
How are there any fewer RTTs with TCP DNS than there would be with UDP? I'm not seeing the efficiency here.
There is a per-packet cost to processing requests. TCP can bundle them; UDP cannot. Is it large enough to matter? I don't know. But the cost includes evaluating context of the requesting entity, which might not be meaningful for DNS queries. Maybe if they are related, some working-set caching would occur.
RTT might not improve at all. But lag might. Scripts often make the mistake of asking for information when they need it. Instead of before they need it, so it will be ready when needed. The suggested approach would pre-load the DNS info and might reduce lag.
TCP sends successive data elements together, at least as part of the Nagle algorithm. I have no idea if the way DNS uses TCP can trigger Nagle.
In fact my own UDP protocol does something similar to Nagle as well. There's no good reason UDP protocols can't pick and choose what features they include. But most don't.
I (a) don't think TCP DNS routinely stuffs two requests in a single TCP segment and (b) don't believe TCP DNS is ever more performant than UDP DNS, including on mobile --- UDP gets a head start from not having a 3WH, and doesn't have rate limiting, which TCP does. TCP headers are also much larger than UDP headers.
Even the reliability argument doesn't make sense. Yes, TCP is "reliable". But so is UDP DNS, and in exactly the same way: if a request or response is dropped, it's retransmitted.
Nagle, for what it's worth, is an HN contributor. You could just ask him. :)
Agreed an all counts. Its a stretch to imagine TCP is better at performance.
{edit} though performance isn't really about wire time or packet size - its about cpu time on either end plus buffering. Including router time since that's a cpu in the path.
