DOS attack against DNS?

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 :wink:
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.org (Mark Andrews) writes:

  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.

people inside one of the largest networks have told me that they have
customers who require the ability to bypass BCP38 restrictions, and that
they will therefore never be fully BCP38 compliant. i've asked for BCP38
to become the default on all their other present and future customers but
then there was whining about bankruptcy, old outdated equipment, and so on.
sadly, there's no way to de-peer this network, or any other multinational,
and so there will be no "peer pressure" on them to implement BCP38.

so, it's either not in everyone's interests to do the right thing, or there
is still a huge variance in what's considered "the right thing". either
way, we're (the internet is) SCREWED until we (that's "we all") fix this.

(if you're not seeing spoofed-source attacks, bully for you! i didn't see
one today, either, but leaving this tool in the bad-guy toolbox makes us all
unsafe, no matter how much or how little they may be using it this day/year.)

Mark_Andrews@isc.org (Mark Andrews) writes:

  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.

people inside one of the largest networks have told me that they have
customers who require the ability to bypass BCP38 restrictions, and that
they will therefore never be fully BCP38 compliant. i've asked for BCP38
to become the default on all their other present and future customers but
then there was whining about bankruptcy, old outdated equipment, and so on.
sadly, there's no way to de-peer this network, or any other multinational,
and so there will be no "peer pressure" on them to implement BCP38.

Consider people in the rest of the world who may purchase simplex satellite links. By definition they inject traffic in places they aren't announcing their route from.

joelja@darkwing.uoregon.edu (Joel Jaeggli) writes:

> people inside one of the largest networks have told me that they have
> customers who require the ability to bypass BCP38 restrictions, and that
> they will therefore never be fully BCP38 compliant. ...

Consider people in the rest of the world who may purchase simplex
satellite links. By definition they inject traffic in places they aren't
announcing their route from.

yup, those are exactly the customers i was told about. (see above.) however,
there's still a way to filter-list the various interfaces -- it's just harder
than letting the routing table imply your filter-list for you. also however,
if these were the only customers who weren't made to follow BCP38, there would
not be a global BCP38-related problem right now. or, as i said before:

Sounds like the landing sites would not be able to use Unicast RPF. However, they could still use BCP38. Nothing says the filters have to be magically generated from routing data (not that uRPF really does that either, since it works off the FIB on most routers).

Mobile IP had the same set of issues when we were first working on the ingress filtering drafts. In their case, a bit of tunneling solved the issue. While tunneling could easily solve the satellite case too, there may be resistance to that.

In article <Pine.LNX.4.64.0601160943150.30093@twin.uoregon.edu> you write:

Mark_Andrews@isc.org (Mark Andrews) writes:

  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.

people inside one of the largest networks have told me that they have
customers who require the ability to bypass BCP38 restrictions, and that
they will therefore never be fully BCP38 compliant. i've asked for BCP38
to become the default on all their other present and future customers but
then there was whining about bankruptcy, old outdated equipment, and so on.
sadly, there's no way to de-peer this network, or any other multinational,
and so there will be no "peer pressure" on them to implement BCP38.

Consider people in the rest of the world who may purchase simplex
satellite links. By definition they inject traffic in places they aren't
announcing their route from.

  But they don't need to be able to source all of 0/0. They
  need to be able to source particular addresses which they
  have. If the end point of the satellite link is dynamic
  then they need to souce netblocks. The satellite company
  should be able to supply a complete list so filters can be
  setup appropriately.

  BCP 38 isn't all or nothing. You do the best you can. You
  limit the exposure.

  In this case if you get spoofed traffic from the satellite
  company's addresses you still talk to the satellite company
  to address the problem. If they have static address
  assignment it should be a easy job to trace the offending
  traffic back. If they have dynamic assignment then things
  get harder.

  It should be possible to prevent any "owned" box (other
  than a router) spewing out spoofed traffic to the net as a
  whole. "owned" routers are a different kettle of fish.

  This is not a new problem. Sooner or later goverments will
  mandate this sort of filtering if the networking community
  as a whole don't do it and they may not leave room to support
  satellite down links. Think manditory strict unicast reverse
  path filtering everywhere.