Re: DOS attack against DNS?

[Mark Andrews <Mark_Andrews () isc org>]

> 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 () 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 () isc org