bugtraq - Re: recursive DNS servers DDoS as a growing DDoS problem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 4 Apr 2006 11:06:13 -0400
From: Tim <tim-security@...tinelchicken.org>
To: Anton Ivanov <arivanov@...segv.cx>
Cc: bugtraq@...urityfocus.com
Subject: Re: recursive DNS servers DDoS as a growing DDoS problem

Hello Anton,

>     This is feasible only for corporate networks where the allocations
> are constant and change once in a few years.
> 
>     It is not feasible in any ISP/Telco above a certain size. In fact,
> considering the consolidation over the recent years it is not feasible
> for most ISPs or Telcos.
> 
>     In an ISP you will have to provision and reprovision the
> nameserver ACLs on a daily basis to match your current customer
> allocations and reload it like there is no tomorrow. One mistake in
> provisioning and you will have a large chunk of customers shouting
> down the support line why their internet does not work. It becomes
> even more entertaining if you use RFC3258 or clustering to load
> balance DNS traffic. In that case you often end up with a lottery
> where one server replies, other servers deny or vice versa. Debugging
> that  is even more entertaining. Frankly, expecting any large ISP to
> deploy anything like this is not realistic.

Are you sure this difficulty is due to the real problem at hand, or due
to poorly designed/implemented software to manage DNS?  Leaving
a single ISP's recursive resolution open to the world is a minor
disservice to the Internet community, but a *major* disservice to it's
own customers.  Cache poisoning really isn't that hard when you can
dictate which records you want to poison and when you want to do it,
from the outside.  Especially with certain softwares' lack of source
port randomization.  An attacker can just wait until the next time a
remotely exploitable IE hole comes out and then poison the records of a
popular website, and *bam* your users are 0wned.

>    Using QoS to limit queries coming from the outside world can be
> done in a manner where it does not require any extra provisioning and
> modification to the nameserver config. On top of that, for most well
> designed large ISP/Telco DNS server deployments this is just a simple
> config change. Once it has been rolled out it maintains itself. After
> all, if your customers have no network access having or not having DNS
> is largely irrelevant.

Um... I guess I'm missing something.  If it isn't difficult to limit
_recursive_ query rates from the outside world, how would it be
difficult to disallow them?  This seems like an artifical limitation of
the DNS software in use.  

With that said, I've never ran a very large DNS infrastructure, but I do
know there's a lot of terrible DNS software out there...

cheers,
tim

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)