In message <20120612001414.ga27...@hiwaay.net>, Chris Adams writes: > Once upon a time, Mark Andrews <ma...@isc.org> said: > > If we have Attacker -> CPE -> Auth -> CPE -> Target why isn't the CPE > > returning answers from its cache? > > Most of the CPE just run a DNS proxy (e.g. dnsmasq on Linux-based > boxes), not a full cache. Even if they ran a cache, the attack would > still be CPE->Target (just not going to another server in-between). It > is easier to find an open CPE being used to attack and shut it down when > it sends every request back out to the ISP's recursive servers.
If it is a proxy then the initial path is: Attacker -> Proxy -> Recursive -> Auth -> Recursive -> Proxy -> Target and once a response is cached: Attacker -> Proxy -> Recursive -> Proxy -> Target One shouldn't be seeing "Attacker -> CPE -> Auth -> CPE -> Target" as a steady stream unless the CPE is not caching in which case how is it getting to the auth server? That said the answers to the other questions I asked will be much more interesting to answer as the solution to this problem lies in those answers. It is relatively easy to get the equivalent amplification protection TCP gives to UDP/EDNS queries using well known techniques. The question is if we were to go down that path would it be deployed and would it be enough? Can we live with the amplification of plain DNS or do we need to address that as well? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
