-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tim wrote:
>> All it takes is to throttle traffic from the resovers to outside >> the ISP network to a reasonably low value. Depending on the ISP >> this is usually in the low Kbits. All it takes is a moderate >> amount of competence in the ISP: > > > I don't believe this would help the problem. One of the notable > features of many reflected attacks is that no single reflector is > hit with a large amount of traffic. It is spread out amongst many > many reflectors so that the reflectors don't notice the issue, and > so that the victim has a harder time filtering the traffic. Correct. By itself it will not. As a matter of fact no approach will do it by itself alone. Still, let us suppose that antispoofing is largely reduced (there are too many access designs out there where it cannot be fully eliminated) and running open recursive DNS servers on a customer machine is treated the same way we treat open SMTP relays nowdays. This still leaves larger ISPs and Telcos who have large DNS resolver installations that have to serve customers. It will be possible to use these for aplification for years to come unless something is done. > > If your goal is to eliminate the recursive resolution reflection > amplification, then you must disable it for all but trusted > subnets. This also defends the server from the more trivial of > cache poisoning attacks (assuming your own systems use the resolver > as well). This is feasible only for corporate networks where the allocations are constant and change once in a few years. It is not feasible in any ISP/Telco above a certain size. In fact, considering the consolidation over the recent years it is not feasible for most ISPs or Telcos. In an ISP you will have to provision and reprovision the nameserver ACLs on a daily basis to match your current customer allocations and reload it like there is no tomorrow. One mistake in provisioning and you will have a large chunk of customers shouting down the support line why their internet does not work. It becomes even more entertaining if you use RFC3258 or clustering to load balance DNS traffic. In that case you often end up with a lottery where one server replies, other servers deny or vice versa. Debugging that is even more entertaining. Frankly, expecting any large ISP to deploy anything like this is not realistic. Using QoS to limit queries coming from the outside world can be done in a manner where it does not require any extra provisioning and modification to the nameserver config. On top of that, for most well designed large ISP/Telco DNS server deployments this is just a simple config change. Once it has been rolled out it maintains itself. After all, if your customers have no network access having or not having DNS is largely irrelevant. By the way, nothing prevents you from putting the limit at 0 or filtering based on route tag so that you completely block recursive queries from outside your network. Personally, I would not do it (there are failure cases which will not be covered), but nothing prevents an oversealous BOFH from doing it. - -- A. R. Ivanov E-mail: [EMAIL PROTECTED] WWW: http://www.sigsegv.cx/ pub 1024D/DDE5E715 2002-03-03 Anton R. Ivanov <[EMAIL PROTECTED]> Fingerprint: C824 CBD7 EE4B D7F8 5331 89D5 FCDA 572E DDE5 E715 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEMhV3/NpXLt3l5xURAkeQAJ9S1IUxoJYDEAlqsJ5nPq6xZELoCwCgnHDJ BnUYwhfLTD6eU20cF09aA/U= =hL61 -----END PGP SIGNATURE-----