Date: 25 Nov 2002 18:33:09 -0000
Message-ID: <20021125183309.59405.qmail@cr.yp.to>
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein"
To: namedroppers@ops.ietf.org
Subject: Re: DNS Server DoS Attacks
References:
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Status: RO
Content-Length: 2070
Lines: 43
Hallam-Baker, Phillip writes:
> DoS attacks against NNTP are quite easy,
Taking the current root system down is trivial.
If you're suggesting that the (signed) root-zone data should be given
high priority in case of floods, I agree. This could be done through
local USENET software, or through building a root-zone-only network; I'd
advocate pursuing both approaches.
> Anything at the application layer has a severe bootstrap problem.
Obviously not: the system is already bootstrapped. (Does it bother you
that people retrieve new root-server lists by asking a.root-servers.net
instead of using the IP address? Gee, what if your Internet connection
fails for a month straight, and all the root servers move, and your
cache expires, and you can never find any DNS records again...)
If you're suggesting that the local links in systems like USENET should
use IP addresses to shield themselves from DNS failures, I agree. This
is why many administrators _do_ use IP addresses.
> Of course this would have some minor inconveniences, not least the
> fact that the assumed resilience of the other infrastructure might be
> imagined and none of the existing software would work.
The existing software will continue to work. If the new root-zone
distribution network is disrupted for weeks on end, people will grab new
data from the root servers in the traditional way.
The crucial point is that the root-zone data will persist for a month.
This not only drastically reduces the overall load, but it also gives us
ample time to fix problems if problems do occur.
Sure, the root could pump up its TTLs with the current system, but that
doesn't have the same effect unless it's combined with prefetching,
cache persistency across restarts, and other unusual features. Changing
and redeploying the cache software would be quite a bit more difficult
than having ISPs run simple scripts to install PGP-verified copies of
the root zone.
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago