Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

The amplification is by asking the misconfigured resolver about a DNSSEC zone.

Basically, DNSSEC just mean you do not need to search the for a large zone to request. Given that large zones are not directly in shot supply, and that searching for them is (in the age of ipv4) rather easy, I wonder if DNSSEC actually have any affect on the issue what so ever.



sort by: page size:

You should also note that DNSSEC is just as much of a problem as open resolvers.

A normal A record lookup results in 1-2x amplification

   $ dig www.ripe.net. in a | grep SIZE
   ;; MSG SIZE  rcvd: 46
Asking for DNSSEC records specifically yields a 10x+ amplification

   $ dig www.ripe.net. in RRSIG | grep SIZE
   ;; MSG SIZE  rcvd: 534
According to research by DJB[1] over 2000 DNSSEC enabled zones provide >30x amplification for incoming UDP queries.

1. cr.yp.to/talks/2012.06.04/slides.pdf


> There seems to be lots of fearmongering about DNSSEC amplification

There is also a 300+ Gbps DDoS attack making use of it right now. This was foreseen as a huge amplification vector in a stateless protocol during the design phase, but was ignored. Now we get to reap the benefits of that decision.

Normal DNS responses don't often grow to the size of google.com/IN/ANY. You have a very limited number of authoritative sources to use (and hosting yourself creates a bottleneck as well as a path back to you). With widespread DNSSEC adoption every zone becomes a good amplification source, which nullifies the current best practices for mitigation (rate limiting responses per zone/source).

If DNSSEC adoption becomes the norm, open recursive resolvers no longer become the problem and direct to authoritative becomes a viable attack vector.


Unless I'm misunderstanding, the 'amplification' in 'DNS amplification attack' doesn't necessarily refer to DNSSEC. The idea is that you use x amount of bandwidth to send y amount of bandwidth at the target where y = kx, for some value of k that is significant enough to make it more worthwhile than just sending the traffic directly.

E.g. make a UDP DNS request to an open resolver with the source IP forged to be your target, then the response is sent to your target (rather than to the real source of the request).

My understanding is that the problem people have with DNSSEC in this regard is that the data returned in those responses increases by a lot (allowing for a 30x increase?). But if attackers are able to accomplish this without DNSSEC, then what's the point of talking about how horrible DNSSEC will make things in this regard?


But you can easily force regular DNS to give you high amplification. Just query a domain which gives you a larger response, such as multiple A records, MXes, SPF records, and so on. For example:

    $ dig google.com. ANY | grep SIZE
    ;; MSG SIZE  rcvd: 546
If you want more amplification than that gives, just host one yourself. The recursive resolver will hit your DNS server once, then send out replies based on the cache.

There seems to be lots of fearmongering about DNSSEC amplification, but you can get just the same amount of amplification out of regular DNS, so it seems that fixing DNS amplification in other ways would be more effective than trying to avoid adopting DNSSEC.


Correct. DNSSEC just makes amplification worse.

It's like: Do you want to be shot with 50 bullets or 100 bullets. DNSSEC is 100 bullets, regular DNS might be 50 bullets. Either way, you're going to die.

I don't like DNSSEC, but amplification isn't my argument against it. The fact that it doesn't provide encryption, puts keys in the wrong hands, and is bizarrely complex for reasons that don't fit with the model of DNS is why I don't like DNSSEC.


Was that the bit about amplification via DNSSEC?

DNSSEC amplification is still pretty high. When I ran dnssecamp[1] last year, I got similar numbers to the example run cited (2000+ servers providing 30x amplification, scaling up to 95x amplification for the worst offenders).

[1] http://dnscurve.org/dnssecamp.html


DNSSEC is the amplification in "DNS amplification attack." I personally run a (heavily rate limited) open resolver as a honey pot to observe these attacks in progress.

You can read CloudFlare's own explanation of how these attacks work http://blog.cloudflare.com/deep-inside-a-dns-amplification-d...


Countering DNSSEC Amplification Attack

> other than when websites misconfigure their DNSSEC config

One major problem with DNSSEC is that it is relatively easy to misconfigure it, especially in more complicated scenarios, and a misconfiguration can take you down for a long time.


Hmm. What I got was that, disregarding the open redirector thing, DNSSEC is typically "only" about two times worse than regular DNS amplification. DJB's number is a lot higher.

  | There is also a 300+ Gbps DDoS attack
  | making use of it right now
I have yet to see anyone state authoritatively that DNSSEC is being used in this attack. Could you provide a reference for this?

If this attack right now is able to reach 30x amplification without DNSSEC, then what's the point of of decrying DNSSEC amplification as a huge issue?

Other discussion: https://news.ycombinator.com/item?id=5451299


DNSSEC does not cause DNS amplification attacks. It just makes them worse. If we want to stop DNS amplification attacks, "not doing DNSSEC" isn't the fix. Closing down open redirectors is. If we turned off DNSSEC tomorrow, we'd still see these attacks.

That doesn't answer the question I asked. If you issue a DNS query to your resolver and DNSSEC validation fails, then the resolver can't trust the result it received as that info could be bogus. I can't see how there is a "usable result". Am I missing something?

DNSSEC doesn't cause DNS amplification attacks. It just makes them much, much worse.

Meanwhile, DNSSEC itself provides minimal value (all online commerce on the Internet happens without DNSSEC today, and to a useful first approximation, none of today's online fraud depends on spoofing DNS).


As someone not very knowledgable about DNSSEC, can you expand on this point? To the uninformed that sounds very counterintuitive.

There are nearly 20 million DNSSEC-enabled zones [1], which is a drop in the bucket compared to the internet as whole obviously. But 20 million is not nothin’.

[1]: https://stats.dnssec-tools.org/


DNSSEC used to be the biggest opportunity for amplification attacks.

https://vimeo.com/18279777


A nit, but the resolver, not the client, validates DNSSEC. The client/stub resolver trusts its local resolver. That always struck me as weird.
next

Legal | privacy