On 03/16/15 23:31, Paul Vixie wrote: > removing dns-operations@ as a cc. one mailing list at a time, please?
Sorry, saw this response late... > 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. Right, there have been discussions on this in the past (I think on dns-operations@), but both BIND (dnssec-signzone) and the OpenDNSSEC tools set the NSEC3PARAM TTL to 0. I am not sure what the "right" answer is, but it is contributing to the problem below. > 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.) I know unbound did do this--I think it still does, but it's late and I haven't had a chance to test it. The public recursive DNS service was google, and again, my tests six months ago showed that they were purging the entire ANY pseudo-RRset and requerying the authoritative servers. > "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? I think there are a few issues at play. google and other public recursives will sometimes have multiple backend servers fetch a given RR when they receive a single query for that RR on one instance of, say, 8.8.8.8. I am basing this both on observed behavior and on Geoff Huston's research (recently presented at NANOG). And since nothing is cached, I get the same servers asking the same query over and over again. Writ large, the result is that I end up with 1-2k of simultaneous TCP sessions, per server, per domain. Nothing I can't handle, since usually only 2-3 of my domains are involved, But it does mean that I have to tweak BIND's defaults, since the number of allowed simultaneous TCP sessions for that implementation is much lower. Otherwise I deny legitimate clients, since the TCP limit is applied across the entire named process, without regard to QTYPE or anything else. So if someone is good at figuring out where the rate limits lie, and what tuple(s) they're based on, they can try to sneak just under the radar of any public cache, not just google. If they spread the tuple values out enough, they might have an effective attack. I have no idea how debilitating it is, as I have no visibility into who the actual victim is in this case. > 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. I am pretty small-time, but given some of the domains I slave are viewed as useful for reflection attacks, I will usually see these odd things when they crop up. michael _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop