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