DOS attack against DNS?

Sun Jan 15 22:32:55 UTC 2006


> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> --------------enig8BD22DF9AD3BC6F2B19E8B12
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
> 
> Mark Andrews wrote:
> > In article <43C9EF72.50803 at garlic.com> you write:
> >> I just started seeing thousands of DNS queries that look like some sor=
> t=20
> >> of DOS attack.  One log entry is below with the IP obscured.
> >>
> >> client xx.xx.xx.xx#6704: query: z.tn.co.za ANY ANY +E
> >>
> >> When you look at z.tn.co.za you see a huge TXT record.
> >>
> >> Is anyone else seeing this attack or am I the lucky one?  Is this a=20
> >> known attack?
> >>
> >> Roy
> >=20
> > 	You are being used as a DoS amplifier.  The queries will be
> > 	spoofed.  Someone needs to learn about BCP 38.
> 
> Next to not running a $world recursive/caching service ;)
> Which is where the OP can actually do something about this problem.
> Folks who don't do ingress filtering will not be bothered to get it
> going unfortunately...
> 
> Greets,
>  Jeroen

	Configure the server to serve z.tn.co.za and set
	"allow-query { none; };".  This will stop the server
	amplifying the attack.

	Black-hole the spoofed address.  This works fine for purely
	recursive servers as they shouldn't be getting queries from
	the given address anyway.

	On could hack the servers to identify particular tuples and
	black-hole them.  This however is a not a long term solution
	to the problem and requires a lot of maintenance.

	Trace the spoofed traffic streams and get the offending
	sites turned off recommending that BCP 38 be depoloyed.  

	For repeat offenders create a list of networks that won't
	implement BCP 38 and collectively de-peer with them telling
	them why you are de-peering and what is required to
	re-establish connectivity.  It is in everyones interests
	to do the right thing here.

	Shunning works if you have the collective gumption to do it.

	Alternatively create a list of networks that agree to
	implement BCP 38 and don't carry traffic from anyone else.
	Advertise that you are BCP 38 compliant.

	Either way, lack of BCP 38 compliance is a collective problem
	and needs to dealt with in a collective manner.
 
	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org