[dns-operations] DNS ANY requests from Amazon?

[Vernon Schryver]

> From: Stephane Bortzmeyer <bortzmeyer at nic.fr>

> >                      While rate limiting by client IP address stops
> > a reflection attack, it also turns off almost all DNS service to the
> > client from the server.
>
> No one in his right mind limits simply by the client's IP
> address. People typically also use the type of the request (today,
> typically ANY). See my mini-HOWTO for Linux Netfilter in this thread.

That tactic makes limited sense if you assume that the bad guys are
too stupid to see that they can bypass ANY filters with almost as
much amplification with other query types such as A.

`dig +dnssec www.nic.fr @ns1.nic.fr` offers amplification of more than 25X.

 +++++

] but my point is that it works *today*, with *actual* attacks. So, it
] definitely helps but keep your eyes open, have alternative solutions
] in place and do not put all your eggs in one basket

Yes, automated response rate limiting (RRL) is too small a basket
to hold all of anyone's eggs.  However, a static ANY filter amounts
to trying to keep all of your eggs in a handkerchief.  Manually
maintained iptable rules are akin to hiring jugglers keep all of
your eggs in the air.


>                                                   (nobody asks "ANY
> isc.org" in the real world, except the attackers).

The common claim that no one uses ANY is so overstated that it is
false.  I use ANY to diagnose real problems in the real Internet.


> I appreciate the BIND RRL patch and it is obvious to me that we must
> continue the research in dDoS mitigation, but let's not drop the
> mitigations techniques that work *today*. (The attackers are not
> superhuman, they use imperfect techniques.)

That's quite true, but advocating defenses such as static ANY filters
or manually installed iptable rules is like avocating homeopathy in
the fight against malaria.
The suggested iptable tactic would be better if the phython program
somehow automatically installed iptable rules.  However, that might
be too effective.


> In actual deployments, some people may be unwilling or unauthorized
> (corporate policy) to install "unofficial" patches on a production
> server. That's why we should not reject blindly the OS-level rate
> limiters (see my mini-HOWTO in this thread).

A third party's iptable rules (not to mention a third party's program
that generates the iptable rules) should get as much scrutiny as
unofficial patches for BIND or NSD.  Neither iptables hacks, a third
party's phython program to generate iptables rules, nor DNS server
patches (even if official) should be used lightly.

The BIND patch includes a standard test suite in bin/tests/system/rrl


Vernon Schryver    vjs at rhyolite.com