removing dns-operations@ as a cc. one mailing list at a time, please?
Michael Sinatra wrote: > On 3/16/15 4:15 PM, P Vixie wrote: >> > Michael, what attacks do you think we can stop by limiting ANY? Paul > ... > > * These domains are DNSSEC-signed with NSEC3. Many tools set the TTL of > NSEC3PARAM to 0 when signing zones with NSEC3. The NSEC3PARAM RR is > part of the ANY response. well, that's part of your problem right there. but i can see how ANY is involved, now. > > * The public recursive servers use an implementation that clears all > records from the cache when the TTL of one record expires, so the next > time the recursive server gets an ANY query, it must re-query the > authoritative server. this is an internet-affecting bug and i hope you report it as such. RRsets are to be purged when the lowest TTL therein expires, but the other RRsets sharing that name should not be affected. can i ask which public facing dns service has mandated that the rest of us juggle their chainsaws for them in this way? (this is even worse than the jerk who decided that EDNS could use IP fragmentation -- but i think that guy has apologized at least.) > In this situation, if I set TC=1 for all ANY queries on my authoritative > server, but the public recursives don't, then the victim still gets hit > with a pretty big amplification attack, and my authoritative servers get > hammered with TCP queries. "hammered" sounds like a volume greater than that which would be detected and strangled with DNS RRL. what am i missing here, that makes this your problem, rather than the public recursive dns operator's problem? > ... > > So my point is that if we're going to specify TC=1 for ANY queries, it > has to be mandatory, and all implementations have to handle it the same: > Send an empty NOERROR and set TC=1. If I am the only one setting TC=1, > it won't doing any good for the attack described above, even if my > domains are the ones being used in the attack. > > The other option is to allow the authoritative servers to control what > gets set out in response to QTYPE=ANY. But I see devils in the details, > just as with NOTIMP and other proposals. i think there's no saving ANY at this point. we're deciding how it dies and where to bury it, that's all. however, you've provided an example of an ANY attack that can't be trivially switch to TXT, so, thank you. -- Paul Vixie
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
