Have these spoofing attacks been recorded somewhere that can be referenced,
e.g. US-CERT? Can you say more about how those attacks could have been
mitigated without DNSSEC? Have there been attacks that could only be
mitigated with DNSSEC?

Of course, a spoofing-phishing attack turns into a DoS attack if the host
discards the bogus DNS info but never gets the DNSSEC validated info.

- Ralph

On 12/3/06 9:53 AM, "bert hubert" wrote:

> On Sun, Dec 03, 2006 at 08:10:57AM -0500, Ralph Droms wrote:
>> that can be mitigated by DNSSEC are not in the public consciousness like
>> spam or malware or phishing attacks. Do we have documented evidence of
>> specific successful attacks that can be mitigated by DNSSEC?

> Yes, there have been succesful spoofing attacks, whereby end-users end up on
> a different website from the one they thought they were visiting. These
> attacks could have been prevented without DNSSEC however, and any website
> that is truly important uses SSL, which would flag the misdirection (which
> would then be ignored).
> Such spoofing has actually happened a number of times, but hasn't really hit
> the news.
> It is also easy to do, to quote from
> http://www.ietf.org/internet-drafts/...poofing-00.txt
> The calculations above indicate the relative ease with which DNS data can
> be spoofed. For example, using the formula derived earlier on a domain
> with a 3600 second TTL, an attacker sending 7000 fake answer packets/s (a
> rate of 4.5Mb/s), stands a 10% chance of spoofing a record in the first
> 24 hours, which rises to 50% after a week.
> For a domain with a TTL of 60 seconds, the 10% level is hit after 24
> minutes, 50% after less than 3 hours, 90% after around 9 hours.
> I've written some tools that perform this action, when you manage to
> saturate the bonafide authoritative servers, success is achieved within
> seconds. Partial saturation means somewhat longer time is needed. The
> calculations above are for the non-saturated case.
>> What is the direct, immediate RoI for the resources I have to commit to
>> providing DNSSEC resolution for names in my zone? My external contacts
>> ("customers") may benefit from mitigation of attacks, but that's an indirect
>> benefit.

> They might conceivably worry more over the (inherent) higher reliability
> problems of DNSSEC: there are far more failure modes. This is not DNSSECs
> fault, it is inherent in any protocol that gets encryption added to it.
> This is why I favor (immediate) ameliorization measures, as outlined in my
> draft, which are easy to implement.
> However, recapping, there IS a problem that needs to be solved.
> Bert

to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.