> From: Dan Luedtke <[email protected]> > > After you have rate limiting, why bother with the costs of the > > synthetic CNAMES?
> What I suggested was a method for legitimate clients to remove > themselves from the rate-limiting blacklist. > They get onto the list when an attacker sends spoofed queries using the > legitimate client's (e.g. a resolving DNS server of an ISP) IP address > as source address. Thus an attacker could "disable" zones for specific > ISPs by attacking the rate-limiting authoritative name server of the > zone. Thanks, I am a little less mystified, but still confused. Unlike simplistic firewall-like or firewall-based rate limiting that blocks all requests from a client IP address, RRL does not answer or answers with TC=1 individual requests. With firewall-like rate limiting, when the victim's IP address is forged, all requests are affected. With RRL, a victim will not notice the attack unless the victim asks for the same domain and record type that is being forged. Even if the victim does make the same request as in the forged flood, the odds are good that the victim will get a truncated response, try TCP, and see no more than a hiccup that looks the same ordinary Internet packet loss. It might be nice to have a way to avoid the modest RRL side effects of delays and TC=1 redirection to TCP. Synthetic CNAMEs offer no help but only new and serious vulnerabilities. EDNS cookies sound effective against the side effects of RRL. Because those effects are modest, people might not rush to standardize and implement cookies. They should certainly work on RRL first, because with or without EDNS cookies, RRL will be needed for many years. When something like RRL is a de facto standard, reflection attacks and the side effects of RRL will be rare, leaving less urgency for cookies. > Despite my suggestion earlier in this thread, I agree with Paul when it > comes to handing out data that are obviously not zone data. Cookies seem > more appropriate now. I'm not sure, but I think we agree. Vernon Schryver [email protected] _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
