BTW, The goal of OpenResolverProject was to have an inventory so folks could measure against attacks and determine what % of attacks utilized them.
The list is available in weekly format to security teams to download in bulk so they can use tools like GrepCidr to perform this cross-reference. The unexpected results of the data were knowing that ~46% are just a broken CPE device that does something weird with DNS packets. BCP-38 isn't going to resolve the DDoS threat, but does close some of the attack surface. A number of folks are doing derivative research with the data as well. You can use the broken CPE devices to measure BCP-38 compliance, and I've been working with at least two different university research teams to help them understand the data. I'd love for more people to dive into it, and any help I can provide in collecting better data (some folks want the UDP reply TTLs captured for example) I'm interested to know about. I've also thought about doing an actual TCP/53 scan as well and send the query over TCP to measure how many reply there. (I have some TC=1 responses in my weekly scan results). The name and shame side-effect is helpful to drive interest, as well as presentations at various meetings. Personally, I see some of the larger threats being the lack of rigorous CPE testing, the fact that many want to be your DNS proxy, and "unmanaged" VPS/VM solutions that exist out there. - Jared On Aug 21, 2013, at 6:00 AM, Geoff Huston <g...@apnic.net> wrote: > 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 _______________________________________________ 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
