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.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.