> From: Casey Deccio <ca...@deccio.net> > On Wed, Mar 6, 2013 at 8:36 AM, <wbr...@e1b.org> wrote:
> > (unless slipped/dropped by RRL). Granted, this doesn't amplify the attack > > since REFUSED is a fairly small packet, but it is still traffic to the > > attacked site. > Seems like a REFUSED response fits into its own RRL category. Is there any > reason why name servers wouldn't simply drop them if they exceed the > configured RRL threshold--or even perhaps a lower threshold? The current version of the BIND9 RRL implementation has the errors-per-second parameter. For documentation, follow the link labeled "Draft text for BIND9 Administrators Reference Manual (ARM) describing" on http://www.redbarn.org/dns/ratelimits The paragraph in that text describing "slip" concludes with: A value of 0 does not "slip" or sends no rate limiting truncated responses. Some error responses includinge REFUSED and SERVFAIL cannot be replaced with truncated responses and are instead leaked at the slip rate. .... } From: Joe Abley <jab...@hopcount.ca> } I believe the current advice is not to use RRL on recursive servers. Yes, legitimate clients of a recursive server can repeat requests more frequently than reasonable rate limits for authoritative servers. An SMTP server (mail receiver) pounding on a DNSBL while receiving a burst of spam is an extreme example. Web browsers can need to resolve a single host name many times to render a page. } You might want to check that you're not unintentionally denying } service to legitimate clients. Simply restricting access to a known } community of clients is the more usual precaution (i.e. making it } not be an open recursive server, as you've done). "views" can be used to restrict access. In the BIND9 RRL implementation, views can have differing RRL parameters. } Inbound (non-submission) SMTP servers and recursive DNS servers are } different. With SMTP servers you cannot enumerate a list of legitimate } clients; the point of e-mail is to attract inbound messages from the } whole Internet. With recursive DNS servers you know exactly who your } client base is. A few recursive servers such as those at 8.8.8.8 apparently want to attract requests from the whole Internet. I agree that most recursive servers should know their client bases by IP address or authenticating token, but in practice that has problems. Many organizations want their users to send DNS requests to their recursive servers from any hotel, airport, customer site, etc. That wrecks limits by IP address. I know of no way to use authentication on end user computers except by something like installing a forwarding, caching DNS server on every end user computer. No stub resolvers seem to have provisions for TSIG. } However, if an inbound DNS query directed at a recursive server } is from a non-legitimate source (and we can tell, because legitimate } sources are all on our network and we can drop spoofed legitimate } queries at our border), I think it's far more appropriate to silently } drop it. I agree, and think stateless firewalls are the best way to do that when practical, but it is not always practical. Firewalls often have trouble when the same computer offers both authoritative DNS service for the whole Internet and recursive service for a restricted client base. In those cases, I'd try views and RRL with "slip 0;" to turn off leaked REFUSED response. ..... ] From: Jo Rhett <jrh...@netconsonance.com> ] ... ] In the case of DNS requests I agree that dropping requests that are ] improper makes sense. There's no human sitting there wondering ] why they didn't get a response. That applies equally to SMTP. After a true positive discarding of spam, there is (almost always) no human waiting for a response. After false positive discarding of DNS requests there is often a human waiting for several seconds and then staring at an error page from a web browser. I oppose spam filtering after the SMTP transaction, because of the likelihood of false positives. A spam filter that has no false positives should silently discard spam. The trouble with discarding spam (including hiding it in "bulk" or "spam folders") is that the only spam filters almost no false positives are on "spam traps," and even they have onlyh "almost none." (think of typos) If your DNS request filter has 0 false positives, then discarding makes sense. In theory, 0 false positives for DNS filtering is possible. In practice, I'd send REFUSED for some time before switching to dropping to catch errors in my access lists. Vernon Schryver v...@rhyolite.com _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
