On 3/17/15 6:17 AM, Yunhong Gu wrote: > > Sounds to me this is the root cause of the problem and ANY is the just a > > scapegoat. > > Giving NSEC3PARAM a positive TTL would prevent my headache, but it > wouldn't help the victim of the attack, and would probably make it worse > for the victim. > > > The reason that this response can be used for an amplification attack is > its size, not the ANY type. A responses with 200 A records can be used > for the same purpose. The (even deeper) root cause is the use of UDP in > DNS protocol. I just do not think banning ANY touches any of these > fundamental issues.
Ah, this is a different argument. I don't believe that I ever suggested "banning" ANY. What I suggested is that if you want to use TC=1 to stop the current en vogue attack, you need to apply it everywhere and make sure that all implementations handle it the same way: All ANY responses get TC=1 with a *minimal* response. Not all implementations currently do that. Another option is cookies, although I haven't fully thought through how that would mesh with the current attack dynamics. I recognize you can do reflection attacks with A records, although there are even better attacks out there that don't use ANY or A. But ANY has basically three uses: reflection attack, troubleshooting, and supporting old qmail. I'd be interested in methods that can be implemented in a matter of weeks or months, which can reduce the attack vector, while retaining as much of the "legitimate functionality" as possible, knowing that the threat can't be fully eliminated. As it stands, operators are taking matters into their own hands and simply blocking ANY responses (which makes my headache bigger because I slave for some of those operators and they're pushing more of the iterative ANY queries at me). michael _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
