This is not the case, but if so, why would you bootstrap a DNSSEC
enabled server using a non-DNSSEC forwarder?
You haven't been following along with the discussion. There may be
DNSSEC-aware authority zones and DNSSEC-aware stub resolvers that might
use DNSSEC-oblivious intermediate caches. For example, suppose
example.com signs its zone, and you install a DNSSEC-aware resolver on
your laptop. Now suppose you go to starbucks, which didn't do DNSSEC
I wouldn't be using starbucks resolver, since i just installed my
own DNSSEC-aware resolver?
When the internal representation is updated, it is often done one RR at
a time. So two responses updating the same two records could be
interleaved. This is a simple database problem called a race condition.
However, we have TTL's and signature life times, so older entries will only
get updated with newer entries, so this "race" is not a problem.
You lost me here.
Sorry. When the RR isn't the same as the one for which the RRSIG was
computed, the DNSSEC-aware stub resolver will reject the record. If it
asks the caching server again, it gets the same records. So the resolver
will fail, and will continue to fail until the TTL expires. The bad guy
just creates two records with long TTL, and you have the DOS attack.
Mark and Roy already explained why this is not the case.
If the caching server checks the signature of all records, its
susceptible to a DOS attack by lots of DNSSEC queries that take a lot of
computation to check. Seems to be no-win.
That's not a DOS attack. That's the price of cryptogrpahically signing
the DNS.
When your server can't handle the load of all these calculations on
millions of queries sent by the attacker, its a DOS attack.
So is not getting any traffic because you lost .com due to cache poisoning.
In fact, what I understood is that resolvers mostly have problems switching
to DNSSEC not due to DNSSEC but due to DNSSEC requiring EDNS0. And mind you,
the EDNS0 was released in what? 1999?
It's not the crypto that's the resolvers issue. That's easilly solved by
adding a cpu or a box.
Now imagine the target spoofed IP's are the nameservers of, say
yourdomain.com. When the roots (or TLDs, etc) get millions of forged
UDP packets, the roots can't block the incoming packets---that would
severely harm the target IP addresses. On the other end, the target IP
addresses can't block the root servers---that would also seriously harm
the target IP addresses. The target just has to 'take it'.
The greater the amplification factor (Response size / request size--
perhaps only 64 bytes), the more damaging this attack is. Since there
are (or may be--probably will be) a number of additional (and large)
DNSSEC records in a response, the response could get quite large,
causing significant damage. So yes, that is a reason not to deploy
DNSSEC.
This has also been explained earlier. Just get a botnet that's 100x
the size to accomplish the same. This argument amounts to something
like "let's not do HDTV because the home user DSL might not be able
to download it in real time anyway".
But all these discussions have happened for 10 years. The result is
DNSSEC.
Paul
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
