I just started seeing thousands of DNS queries that look like some sort 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 known attack?
Roy
In article <43C9EF72.50803@garlic.com> you write:
I just started seeing thousands of DNS queries that look like some sort
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
known attack?Roy
You are being used as a DoS amplifier. The queries will be
spoofed. Someone needs to learn about BCP 38.
Mark
Mark Andrews wrote:
In article <43C9EF72.50803@garlic.com> you write:
I just started seeing thousands of DNS queries that look like some sort
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
known attack?Roy
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
client xx.xx.xx.xx#6704: query: z.tn.co.za ANY ANY +E
class "ANY" has no purpose in the real world, not even for debugging. if
you see it in a query, you can assume malicious intent. if you hear it in
a query, you can safely ignore that query, or at best, map it to class "IN".
er... i guess that is true, although the DNS does work for
things other than IP based networks... dispite our respective
best efforts to cripple it.
--bill
# > class "ANY" has no purpose in the real world, not even for debugging. if
# > you see it in a query, you can assume malicious intent. if you hear it in
# > a query, you can safely ignore that query, or at best, map it to class
# > "IN".
In article <20060115231056.75AAD11425@sa.vix.com> you write:
# > class "ANY" has no purpose in the real world, not even for debugging. if
# > you see it in a query, you can assume malicious intent. if you hear it in
# > a query, you can safely ignore that query, or at best, map it to class
# > "IN".
#
# er... i guess that is true, although the DNS does work for
# things other than IP based networks... dispite our respective
# best efforts to cripple it.i'm not trying to cripple it. i'm saying RFC 1034/1035 was wrong about class
"ANY". all answer/authority/additional data where OP=QUERY and QR=1 will have
the same class as the QCLASS (of which, in spite of the QDCOUNT field, there
can be only one). nodes do not have classes. not even zones have classes.
each class has a hierarchy of NS RRs making a "namespace". each class needs
its own root name servers. there are less-coherent / more-useful ways to
interpret "the spec", and one such way could give meaning to class "ANY", but
no dns implementation i'm aware of follows those alternate interpretations.since nanog isn't a protocol-fine-points mailing list, at least for the DNS
protocol, one could ask "why are we discussing this?" and my answer is, there
is an operational tie-in. if you see QCLASS=ANY in a firewall, that is prima
facie evidence of malfeasance, not merely misconfiguration or
misinterpretation.
And if you want to refuse class ANY queries in BIND 9 create a view
like the following.
view "blackhole" any {
allow-query { none; };
};
Note: all zones have to be in a view once you start using views.
Again this really is only a stop gap measure as the attack
can quite easily morph into something this won't catch.
Mark
Not true,. the ANY query has mutliple uses for consolidating multiple diagnostic queries into a single display, and also for diversion monitoring systems on small domains or groups of same. Not all of us have the resources (or time) of large ISPs behind us.
Did you notice that it was class "ANY" and not type "ANY" that Paul noted?
I've never ever heard of it being used anywhere....
As for ANY query type, what do you think will happen when you query with "ANY" to a host in a domain that is not in your local dns server cache?
And btw if it is in your dns cache, how predictable do you think such
results are going to be???
Admitted, i did not notice the type/class difference. I responded as a knee jerk reaction, and that is my mistake.
For the second part, the any query type is useful (when targeted at either your NS and/or public NS servers) to quickly alert to issues such as the one being discussed with GoDaddy and Nectartech right now on this list.
Pick and/or set up an NS server that is TTL agnostic (flameArmor: this system is to be used for disparate up-to-date checks only, and I know by spec this is far from foolproof but its saved my ass a couple times in the past) and checks disparate roots and its useful for finding or alerting to major name system, registrar ,and provider issues quickly.
Im diverging off-topic, im sure. gnight.
Last saturday one of our Web server experienced a TCP
SYN attck which make the system down for four hours.
It seems there is not a good solution which could
detect & defend DoS traffic at any time.
So, to the class ANY queries, should we only filtering
out class any queries on public cache servers ? To my
understandings, the amplifying result could also be
reached by query type any.
Joe
# Admitted, i did not notice the type/class difference. I responded as a knee
# jerk reaction, and that is my mistake.
on nanog@, the tradition is to send knee-jerk flames without having read the
article you're replying to. it's our own little slice of usenet-like culture,
still alive a decade or several too late. so you're fitting right in. :-).
# For the second part, the any query type is useful (when targeted at either
# your NS and/or public NS servers) to quickly alert to issues such as the one
# being discussed with GoDaddy and Nectartech right now on this list.
i don't like type ANY very much, since it's a cpu amplification attack vector
against recursive nameservers. however, sendmail uses it in hopes of learning
type MX and type A at the same time, and according to eric, this saves more
network traffic than it generates.
in any case i've not said anything against type ANY. it's common, and seeing
it is not an indication of malicious intent, and it should never be blocked.
my earlier comments on this thread were about "class" ANY, not "type" ANY.
# Last saturday one of our Web server experienced a TCP SYN attck which make
# the system down for four hours. It seems there is not a good solution which
# could detect & defend DoS traffic at any time.
by definition, there will never be a single defense against all attacks.
# So, to the class ANY queries, should we only filtering out class any queries
# on public cache servers ?
if you're seeing them and they're hurting you, yes. or if you're willing to
undure the configuration pain of always dropping them (see marka's recent mail
on "view" statements for this purpose), then yes.
# To my understandings, the amplifying result could also be reached by query
# type any.
that's not my understanding. you're more likely to be hurt by a peer's lack
of BCP38 conformance than by all the type=ANY queries you'll ever hear in DNS.