Yes, our goal was to test out the asserting in RFC5966 that: "The majority of DNS server operators already support TCP" and we wanted to see if we could quantify what that "majority" actually was.
What we found out was that of the DNS resolvers that were visible to the authoritative name server, some 83% of them did use TCP following the reception of a truncated UDP response, and the failing 17% of these visible resolvers were used by 6% of the end clients. Of these affected clients, 2/3 of them then used alternate resolvers that did perform TCP, while the remaining 2% were stranded and were unable to complete the name resolution process. But that is just one part of the total story, and a TCP-based resolver is more vulnerable to various forms of SYN flooding attacks as Paul points out. Of course you could always turn to "stateless TCP" (http://www.potaroo.net/ispcol/2009-11/stateless.html) but while that effort was a more light hearted response to the issue, the issue of TCP server scaling and vulnerability to SYN attack is nevertheless a serious one. On the other hand its no more serious than any other form of small TCP transaction based services that are subjected to massive volumes, such as, say, a search engine front end. We've seen a variant of this scaling discussion in a number of domains, and there is a common theme running along here: as the internet grows the servers that support its function need to grow as well. While part of the answer may well be selective TCP session rate limiting and other TCP smarts that reduce the per-TCP-session resource footprint in the server, another part of the answer may simply be that being a DNS authoritative server today simply needs more grunt than yesterday. (Its not just the population of clients and the query loads that can be imposed on servers - its also related to our efforts to increase the information load in the DNS. As an illustration of this in the context of DNSSEC I did some measurements on the amount of additional queries and additional traffic we see from a DNSSEC-signed name as compared to a unsigned name earlier this year when using the client - our results and estimates of the increase in traffic and query loads are at http://www.iepg.org/2013-07-ietf87/2013-07-28-dnssec.pdf) Geoff On 21/08/2013, at 4:27 PM, George Michaelson <g...@apnic.net> wrote: > > > I believe our goal was to find out how many clients, measured by resolver, > failed to complete a TCP forced DNS query. Other people will be looking at > the server side, that wasn't what we were primarily exploring. People who > want to consider TCP based DNS need both sides of the questionspace filled, > so choosing to analyse client failure isn't the whole picture, but it is part > of the picture. _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
