On Sun, 17 Aug 2008, Dean Anderson wrote:
There are two more problems with this.
First, Putting any kind of large record in the root creates the
opportunity to use root servers in a DOS attack by sending queries for
the large records to the root servers. Because of Root Anycasting, there
are over 100+ root servers spread around the world that will respond to
queries. A botnet distributed worldwide should be able to send queries
to most or all of these servers. Most or many of these servers have
very high bandwidth connections. Same would be true for TLD servers, and
large, high traffic domains like microsoft.com, etc. It is very hard, if
not impossible, to mitigate attacks coming from root, TLD or other
significant sites.
If it is TCP, due to large DNSSEC answers, you won't easilly be able
to use these for amplifying your DOS attack. If the answer would fit
in UDP, you wouldnt really have an issue.
Second, as I start to look closer at DNSSEC
It keeps amusing me how people who have critisied DNSSEC for years,
end up asking me things like "so how does it work?" or in your case
"I actually looked at it now".
, there appears to be a
problem in the DNSSEC protocol in that if caching servers don't care
about DNSSEC, then caches could store RRSIG records that are out of sync
with the RR they sign. When the security-aware resolver obtains both
records from the caching server, the resolver that finally checks one
record against the other will find that the signature doesn't match.
This is not the case, but if so, why would you bootstrap a DNSSEC enabled
server using a non-DNSSEC forwarder?
This scenario could happen by accident during zone updates between
master and slaves after the RR was changed, if the cache gets one RR
from the master and receives the RRSIG from another server (one might
Don't you get the RRSIG as Authoritive or Additional data when getting
the new RR?
try to avoid this by adding RRSIG records as additional, but there is
still a race on the internal representation if multiple responses are
received from different servers). Or it could happen on purpose using a
cache poisoning attack. Once the incorrect records are cached, a DOS
occurs. (its only an attack if its on purpose)
You lost me here.
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.
The first problem is reason enough not to deploy DNSSEC. The second
problem is serious, too, but I think only affects DNSSEC users who have
shot themselves, other DNSSEC users, and those using DNSSEC-aware
caching servers in the foot, so to speak. Back to the drawing board?
Because root servers could potentialy amplify a single spoofed packet
into more (which I described is not as bad as you make it appear), that
would be a reason not to deploy secure DNS? This is an answer looking
for a reasoning.
Paul
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
