[dns-operations] DNS ANY requests from Amazon?

[Vernon Schryver]

> From: "Patrick, Robert (CONTR)" <Robert.Patrick at hq.doe.gov>

> I don't disagree that limiting responses is a smarter tact than
> limiting requests, with respect to making an informed decision prior
> to discarding traffic.  Having zone and query-type plus response
> data to evaluate the client hash is more information than looking
> only at source and destination IP address, as may be implemented
> at a firewall or within the O/S.  Some of these data elements could
> also be tracked by an application-aware firewall.

Yes, you could do response rate limiting (RRL) within an application
aware firewall by have the firewall do almost of all of the work
of your DNS server.  For example, your RRL mechanism (whether in a
firewall or DNS server) must count all NXDOMAIN responses to a given
IP address as identical to avoid spewing GBytes/sec of big signed NXDOMAIN
responses about distinct random, invalid domains.
`dig +dnssec asdf1234asdf.com @a.gtld-servers.net` gives a 1K NXDOMAIN.
Referrals have a similar issue.

A firewall that is as DNS aware as that should not waste the computing
it has done to know whether to discard the response it computed to
count.  If things are ok, it should go ahead and send the response.

Never mind that consistency, maintenance, and other problems that
always come with duplicating things, whether definitions of constants
in code or the big chunks of code and data that are a modern DNS server.


> ...
> Allow administrators the freedom to set the limit to any value and/or
> disable the feature, but shipping the product with a "smart" default
> may be viewed as a pragmatic step forward in noise reduction.

The right RRL value depends on each server's popularity.  It might be
reasonable to ship DNS software with a default rate limit suitable for
modest servers (e.g. 5 or fewer responses/second) and expect big server
operators to make adjustments.

> Continuing to deploy into the wild without any rate-limiting isn't
> the best approach long term.

Neither is tolerating unnecessary open recursive servers and ignoring
BCP-38.


Vernon Schryver    vjs at rhyolite.com