[dns-operations] Geoff Huston on DNS-over-TCP-only study.

[Jared Mauch]

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 <gih at 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 <ggm at 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 at 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