On 1 August 2012 10:39, Don Stokes wrote:

Seriously, he utterly misses the point. Signing A records and so-forth provides very little in the way of end to end protection, true, but what it does provide is a trusted, consistent mechanism to place security information (public keys, certificates et c) which end-to-end services can use to secure those services, without having to involve third parties in every single deployment.

Basically, think of it not in terms of security for the DNS but as security information provided through the DNS.

and I fully appreciate the integrity facilities which DNSSEC provides. The bits which concern me more are the points where he raises that through the use of DNSSEC, infrastructural DNS servers become DoS traffic amplifiers. I suspect this is still true of non-signed DNS traffic too, the much larger replies complicate matter somewhat however. How would we protect ourselves as DNS operators from becoming DoS traffic originators in this scenario? Thanks, -- * *Mark Goldfinch | Systems Team Leader MODICA GROUP nz: +64 4 498 6000 *THIS MONTH* - Shiny shiny and new! check out our new website at www.modicagroup.com and tell us what you think.

Hi Jay,

A DNS DoS traffic amplifier just needs a large DNS record anywhere on the Internet to reflect at the target. While DNSSEC does mean there will be more records like that available to choose from, it doesn't create a problem where there wasn't one before. A claim could be made that large records on well-connected servers were hard to find but I doubt that would have stopped an attacker for more than a few minutes. I think the main thing that is a problem with the DNSSEC deployments progressing is that the "strongest" part of the hierarchy (root downwards) are the ones that make those records available. One can quite safely assume that almost any potential target on the Internet will have less capacity than a reflection processed via the root servers (for example). See also: http://www.root-servers.org/map/

The problem is mainly related to the fast implementation of those deployments and at which part in the hierarchy they happen - if that 10x amplification increase were to happen over lets say 5 years with current bandwidth growth rates one would not care much about it. However within a roll-out window of a few months the root-servers now offer 10x more bang for the buck and even Internet bandwidth growth and price drops can't stand up to that. The big game changer for a lot of infrastructure providers is that they have to realize that the real cost of operating critical infrastructure on the Internet to date is not the cost of the bandwidth you need to service your users but the total bandwidth you need to stay online. I certainly hope that this is not only occuring to folks now that DNSSEC is being deployed since it's been a reality for a number of years now. Until we find a solution to this problem as a whole it will always be down to the cheapest current method to perform such an attack and how capacity stands up against it. Regards, Wolfgang

On 01/08/12 11:49, Mark Goldfinch wrote:

How would we protect ourselves as DNS operators from becoming DoS traffic originators in this scenario?

As Jay points out, this isn't a DNSSEC-specific problem. It exacerbates it, sure, but any big response will do for DNS amplification; you don't need DNSSEC. An "ANY" query for the apex of a domain with SPF records, other TXT records, a long NS list, a good-sized MX cloud and a both A & AAAA records for all the listed services will produce a pretty decent sized response without needing to throw DNSSEC at it. So yeah, you can keep your responses down to minimal answers, no SPF or TXT, one or two MX records, two NS records, an A and no DNSSEC, and you won't be such an attractive target, but you're still putting out bigger responses than the queries. The longer answer is to look at rate limiting queries. If you're getting a high rate of repeated queries or even particularly high rates of any type of query from a particular source, throttle the source. Yes, you need to keep state. DNS has a TTL field for a reason; if you're getting queries from a "source" (e.g. the target of DNS amplification attack) at a significant multiple of the rate specified by the TTL of the query responses, someone is Doing It Wrong and it's OK to stop listening to them. The real solution is for providers to filter source addresses at the edge so that this kind of spoofing can't happen. -- don

Hi,

We've been seeing large (100gb/sec+) DNS reflection/amplification attacks for years. Yes, the attacker will identify a big TXT record, or he will execute an ANY query (blocking ANY queries during an attack is a rational response, although this will break qmail), or he will query any DNSSEC-enabled server and be guaranteed that the minimum response size he will get will be at least 1300 bytes. We see all of this routinely. It's always interesting to me that Arbor seems to be the only one who "routinely" sees those in the wild. One could almost think that there is a business driver somewhere there ...

Regards, Wolfgang

Hi,

We aren't the only ones who see these - and in fact, we see attacks much larger than this, but we typically publicly report what survey respondents (i.e., network operators themselves) report in our annual Worldwide Infrastructure Security Report. Large ISPs around the world see these attacks, as they and their customers are on the sending, receiving, or transiting side of the attack traffic in question. Maybe we just have a different opinion on "routine" then. 100Gbps are not what I have seen or heard anywhere as routine just yet. But we are most certainly heading there, that I do agree with.

Having operated DNS root servers and other DNSSEC enabled infrastructure for a number of years I have not seen DNSSEC enabled reflection attacks until just a few months ago. You refer to having seen these for years. Also the wider use of regular DNS amplification attacks seems to only have occured to folks out there just in the last two or so years.

In fact, even though we saw several attacks larger than 100gb/sec last year, we only reported the largest attack which survey respondents reported, which was 65gb/sec - down from 100gb/sec in the 2010 report. See above comment regarding "routine". So a whole year with no 100Gbps attack according to your survey, yet you claim it is "routine". Hmm.

Arbor has an excellent reputation in the global operational security community. We are well-known for our community-sourced research and public educational efforts centered around opsec BCPs. We have no need to exaggerate the threat to availability represented by DDoS attacks, as those who are affected by them can attest - and as a quick search on 'DDoS' via any mainstream search engine will demonstrate. I do not trust research by tobacco companies on the health impact of smoking much. Why would I trust surveys and research from Arbor on matters of DDoS attacks? It is nothing I can verify except that I can say that discussions with carrier folks and what I hear from Arbor seem to always be off by a factor of 10.

Regards, Wolfgang

Hi,

Again, we have no reason to exaggerate - the attackers are creating plenty of demand, already. I personally would not associate myself with an organization which would exaggerate matters of such import, and as the primary author of the last three Arbor WISRs as well as an active member in vetted/trusted operational security mitigation communities (in which your organization does not seem to be represented, AFAICT), not to mention the access I have to our ATLAS system, I see the actual data and reports of attacks for myself and can attest to its veracity. We would love to participate in such communities. We are currently represented on ops-trust and the major DNS operations as well as NOG communities. If you disclose which community we seem to neglect I shall see if we have value to add there and shall close that gap.

It depends on which carrier folks you speak with, and which groups/individuals at which carriers in which regions, as to whether you're actually talking to those who handle these attacks on an operational basis, and of course which carriers originate/transit/are targeted by which particular attacks, and when. Rest assured that I do talk to folks that are very much involved in the relevant area of the network operations at those carriers. My reputation in the industry will vet for me on that one...

Cheers, Wolfgang

Eg DNS-based Authentication of Named Entities (DANE) is a working group developing protocols that allow certificates to be bound to DNShttp://en.m.wikipedia.org/wiki/Domain_Name_System names using Domain Name System Security Extensionshttp://en.m.wikipedia.org/wiki/Domain_Name_System_Security_Extensions (DNSSEC). On Wednesday, August 1, 2012, Don Stokes wrote:

<sigh>

Just another DJB rant. If I was cynical I might almost think he was making excuses for not cutting DNSSEC code for djbdns.

Seriously, he utterly misses the point. Signing A records and so-forth provides very little in the way of end to end protection, true, but what it does provide is a trusted, consistent mechanism to place security information (public keys, certificates et c) which end-to-end services can use to secure those services, without having to involve third parties in every single deployment.

Basically, think of it not in terms of security for the DNS but as security information provided through the DNS.

-- don

On 01/08/12 08:31, Mark Goldfinch wrote:

Greetings all,

I recently came across a presentation by DJB taking an in-depth look at how DNSSEC operates: http://cr.yp.to/talks/2012.06.04/slides.pdf

I haven't seen much in the way of discussion on his assertions, so NZNOG, your opinion please!

Thanks, -- Mark Goldfinch | Systems Team Leader

MODICA GROUP

_______________________________________________ NZNOG mailing listNZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog