[dns-operations] Recently closed open resolver and reflection attacks

[Vernon Schryver]

> From: Casey Deccio <casey at deccio.net>

> On Wed, Mar 6, 2013 at 8:36 AM, <WBrown at 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 <jabley at 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 <jrhett at 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    vjs at rhyolite.com