On Sun, 17 Aug 2008, Paul Wouters wrote:
> 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.
I'm not sure you understand EDNSO. EDNSO UDP can be 8KB in size.
TCP isn't susceptible to this kind of attack at all. TCP spoofing is
just about impossible if you aren't in the path, because there is a
32bit random sequence ID. If you don't get that sequence id, you won't
get the connection established, and the target won't get the DNS
response. A botnet spread worldwide mostly won't be in the path.
> > 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".
This seems strange only if you don't know the history of DNSSEC.
Because they keep messing up in major ways, and keep starting over on
the protocol, what I looked at years ago has no bearing on DNSSEC now.
And I thought it was a dumb idea years ago, too.
> > , 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?
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
and has a DNSSEC-oblivious caching server. Next you try to access
example.com using the starbucks caching server. The DNSSEC-oblivious
cache will just cache the records as ordinary (very large) records.
> > 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?
I'm not entirely sure it works that way. I didn't see that specified.
But it certainly could work that way, as I said below.
> > 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).
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.
Transaction isolation and locking is used to protect against this. DNS
servers usually aren't designed to support transactions on the update of
multiple records in one response.
> > 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.
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.
> > 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.
> > 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.
I don't think you quite understand DOS attack mitigation.
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.
--Dean
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
