> From: Paul Vixie <[email protected]> > On 12/18/2012 9:12 AM, Dobbins, Roland wrote:
> > The 'application-aware firewall' will collapse from state-table > > exhaustion, however, so this likely isn't a very good idea. > > i don't think that follows. RRL is designed in a way that keeps state > manageably finite. State tables for some application-aware filtering can be smaller than for filtering ICMP Echo-requests, TCP SYNs, or other trivial "applications". If your application falls over at X requests/second, then it might not matter that your firewall state table is exhaustd at 2X requests/second. The BIND RRL state table design limit is supposed to be above the limit for the DNS server itself, but that's an untested regime. I think the recent NSD RRL code answered that issue by using a large, fixed size hash table and tolerating false positives. > in speaking to the cloudshield folks and learning > more about "packetC" i think RRL can be done as part of a really smart > front end firewall. How would it filter requests for <random>.example.com without resolving <random>.example.com to know if the response would be an NXDOMAIN or wildcard answer the same as too many others? You could assume that example.com has at most N subdomains, and that all <random>.example.com after the first (or recent) N would get NXDOMAIN, wildcard, or referral answers from the server behind the filter, but that sounds likely to have false positives. 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
