[dns-operations] responding to spoofed ANY queries

Vernon Schryver vjs at rhyolite.com
Sun Jan 13 16:28:32 UTC 2013


> From: David Conrad <drc at virtualized.org>

> I suspect you're misunderstanding what I'm saying ... 

> Yes, it is yet another form of "security theatre", but when has
> that stopped anyone?

Yes, I misunderstand your position as the same as others'.

> However, I'm pretty sure this isn't appropriate fodder for dns-operations...

Perhaps not, if the supposed lack of laws is not an excuse for DNS
recursive server operators to keep them open and for authoritative
servers to refuse to install some kind of rate limiting.  The many
years of "stop bothering me, spam isn't illegal" responses from
operators of open SMTP relays and other spam-critical services make
me wonder.  There are many open recursive servers and authority
servers without rate limiting or with RRL manually disabled except
for the previously common flavors of attack.


    ....

] From: "Frank Bulk" <frnkblk at iname.com>

] If the problem is amplification, why not only perform RRL on only those DNS
] communications exchanges that have certain amplification factor (i.e. 1.5).

That sounds nice but has problems.  The main one for me is that
you'd have wait until the response has been marshalled before
determining it size and deciding whether to drop it.  That seems
to me harder to code in BIND9 and more expensive in CPU cycles.

A better reason is that simple A requests are much smaller than typical
non-DNSSEC responses.  `dig iname.com @204.74.108.1` sends 38 bytes
and receives 225 for 5.9X amplification.  5X is not as flashy as 30X,
but is a big problem.  5X is a lot more than your 1.5X and so in
practice you would rate limit all responses.  If you always do it,
you might as well do it in the cheapest way possible, before knowing
and regardless of the size of the response.

Even 1X or no amplification could be useful to a bad guy wiggling
through firewall holes or obscuring an origin.


Vernon Schryver    vjs at rhyolite.com



More information about the dns-operations mailing list