On Feb 7, 2014, at 8:58 AM, Damian Menscher <[email protected]> wrote:
> You go on to argue that the 3-way handshake adds latency and server load, > which I agree with. But keep in mind only the legitimate queries will need > to use TCP, so the actual load is low. And these are queries which would > otherwise have had to retry over UDP after a timeout (and even then only have > a 50% success rate), so the amortized latency hit isn't particularly > significant either. This is my experience with forcing TC=1 for the initial query from a given source (after re-issuance via TC=1, said source is 'authenticated' for some configurable period of time) - the latency effects and the server overhead are minimal. There are two nontrivial problems with forcing TC=1 these days, neither of which is related to actual DNS server performance: 1. Some large-scale DNS operators have incorrectly disabled TCP/53 for their authoritative DNS farms due to a combination of the old misinformation about TCP/53 being a 'security' risk with regards to AXFR, as well as the continuing misperception that TCP/53 overhead is crippling, based upon early-1990s server performance specs vs. specs of modern servers. 2. Incorrect filtering of TCP/53 on endpoint networks (and in some intermediary networks) due to the aforementioned AXFR myth. Tangentially, Geoff Huston gave a preso at NZNOG last week which analyzes the crypto-related sever overhead of DNSSEC. It's quite interesting to compare the crypto overhead to perceived TCP overhead . . . ----------------------------------------------------------------------- Roland Dobbins <[email protected]> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
