[dns-operations] Configurable TC=1?

Paul Vixie paul at redbarn.org
Mon Dec 28 01:21:45 UTC 2015


On Monday, December 28, 2015 12:11:06 AM Ralf Weber wrote:
> Moin!

What?

> > every time we use an incrementally just-good-enough tool to stop
> > attackers, we educate them without demotivating them. please stop.
> > the systemic defects in the internet that make it insecure include
> > the approach you are describing.
> 
> I assume that if we would design the Internet today we would do it
> differently, but we live in the Internet we have today and need to make
> it work somehow. Thinking about "political correct" defences might work
> when you look at it from an academic level, but not when your in the
> midst of fighting an attack.

if you fight unsustainably, you will lose. see these five articles for an example of what 
happens when every victim does what's best for their own temporary safety, at scale:

http://www.npr.org/sections/goatsandsoda/2015/09/17/441146398/why-india-is-a-hotbed-of-antibiotic-resistance-and-sweden-is-not

https://www.newscientist.com/article/dn28180-global-study-reveals-soaring-antibiotic-resistance-in-india/

http://thinkprogress.org/world/2015/10/21/3714328/india-antibiotics/

http://www.techtimes.com/articles/86013/20150921/antibiotic-resistance-gets-worse-in-india-here-s-why.htm

http://www.nytimes.com/2014/12/04/world/asia/superbugs-kill-indias-babies-and-pose-an-overseas-threat.html

or have another look at this from 2004:

http://www.redbarn.org/node/8

my approach is not academic. sometimes the victim's best option is not the one that 
improves their situation the most in the first hours of an attack. by failing to plan for the long 
game, victims can sometimes set themselves up for bigger losses.

> And to repeat not all DNS attacks can be mitigated by RRL. ...

that's a canard: the only one who speaks it is you. you're not quoting anyone or referencing 
any remarks that anyone has made. i do not believe that all dns attacks can be mitigated with 
one tool, whether RRL or any other tool. noone is saying that. you can stop disputing it now, 
since it's a straw man fallacy.

> >> There are scenarios where RRL just won't work as others have pointed
> >> out.
> > 
> > no. actually, what's been described are various bypasses that work
> > around RRL, all of which are far more expensive (in retooling costs)
> > to attackers than shifting to a completely different protocol (SSDP,
> > ICMP, NTP, or TCP-SYN).
> 
> So what. This already happened.

well, no.

> There are DNS attacks that only us[e] a certain qps to fly below the rate
> limiter ratio, but use a wide variety of addresses or names depending on
> the algorithm.

i've seen this also. what i havn't seen is its use in low-cost attacks by script kiddies. and i don't 
think we will, since it's more complicated than other attacks that are simpler to understand 
and cheaper to launch and more devastating to the victims.

> There are botnet based random subdomain attacks, that will bypass all
> protection we put in with answering TC or cookies at the authoriative
> se[r]vers as they will be run over legitimate resolvers.

random subdomains via open recursives are not a problem RRL solves, or tries to solve. there 
are many other problems RRL does not solve and was not intended to solve. which is why i 
never say that RRL is the only solution that's needed. RRL works very well on random 
subdomain attacks from spoofed sources, and experience with RRL has illuminated a possible 
approach to handling random subdomains through open recursives.

however, since you've opened the door, let me ask:

> There also still is an army of over 14 million open resolvers out there
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20151227/b3e124c1/attachment.html>


More information about the dns-operations mailing list