If it's an attempt at a reflective DNS-based DDoS attack, then the source IP address making the query is likely spoofed. The IP address in question is really the target, not the source of the attack.
That is, of course, if this is a standard reflective DDoS attack.
It could be a DNS amplification attack, with the source IP forged. They
may be hoping you "reply" to the forged source with a response greater than
the cost of them sending the query.
Of course you'd have to actually be running a poorly configured DNS server
on that IP for this to work...
Picking random IPs to spoof and hope some of the random IPs happen to
be DNS servers
doesn't sound like a very "efficient" attack. It seems like the
attacker would want to
'probe first' before selecting innocent servers to reflect at
Perhaps 2 or 3% of the possible random IPs on the internet actually
run DNS servers
that could possibly respond to spoofed queries?
This is definitely a problem.
Unfortunately, what really should happen is DNSSEC should be revised, to,
either make sure that the client initiating the query has to either do more
work than the server, or make a round trip before the DNSSEC data can
be requested.
One way of accomplishing that would be to indicate that DNSSEC data
can be transmitted only over DNS when using TCP; since a reflection
spoofer cannot complete
a 3-way TCP handshake, the attacker cannot send spoofed requests for DNSSEC
data over TCP.
It turns out that DNSSEC makes a respectable traffic amplification vector:
This is definitely a problem.
Yep. So are SNMP reflection attacks (biggest attack I've seen was one of these) and any other datagram-oriented query/response protocol.
Unfortunately, what really should happen is DNSSEC should be revised, to,
either make sure that the client initiating the query has to either do more
work than the server, or make a round trip before the DNSSEC data can
be requested.
No. Implementation of BCP38 does have value, but the existence of
BCP38 does not
solve DNS application problems; Just looking towards BCP38 as a
solution is like attempting
to treat a disease with a theoretically effective treatment that you
can't possibly get enough
of to cure the disease due to limited supplies -- but ignoring
mitigation of the symptoms,
despite there being more readily available options for symptom mitigation.
It's similar to the idea of promoting SPF as a means of stopping
e-mail forgery, and saying
RBLs just treat the symptoms -- stop using RBLs, and get everyone to
implement SPF.
The underlying problem is that "BCP38" is not really a "best common practice",
despite the name of the series.
It's really a "Best Uncommon Practice that really ought to be more common",
but we can't control operators and force them to make it more common.
Lots of networks don't and will not ever implement BCP38; BCP38 is not being
more widely implemented, and there's no obvious action that will
force it to change.
I suspect the root server operators might not like this idea very much.
If it solves other problems adequately, they might eventually just have to learn to like it.
I was, of course, using the root servers as a proxy for pretty much any DNS server operator. The root server operators aren't unique in the requirement to respond to an unbounded number of queries.
No. Implementation of BCP38 does have value, but the existence of
BCP38 does not solve DNS application problems;
You seemed to have missed the part where it isn't just a DNS problem. Your solution would appear to be to replace every datagram-based query/response protocol such as ICMP and SNMP. I personally think it is more feasible for ISPs to implement BCP38 than it is for the entire Internet to move away from using datagram-based query/response protocols, but that's probably just me.
but ignoring mitigation of the symptoms,
despite there being more readily available options for symptom mitigation.
Sorry, which more readily available options are those? I don't think forcing a 3-way exchange for stuff like PMTUD is 'readily available'.
The underlying problem is that "BCP38" is not really a "best common practice",
despite the name of the series.
The name of the series is "Best Current Practice".
Lots of networks don't and will not ever implement BCP38;
It is true that lots of networks don't implement BCP38. Whether or not they will ever is more debatable. I suspect that we're about one major spoofing-based infrastructure attack away from proposed legislation that would force folks to implement something like BCP38, but I may be a bit more pessimistic than most.
However, I would be interested in hearing what the excuses are for folks not implementing BCP38 these days.
1) hardare support varies
2) implementing bcp-38 drives customer support costs up in cases where the customer is doing something weird "e.g.: using toms isdn-dial backup to source return packets".
3) customers can't be trusted to give a complete list of valid source addresses
4) asymmetric or highly kinky routing exists more than one would like to admit
There are cases where it's fairly inexcusable:
Fixed broadband providers (static IP address or dynamic to a customer port/pool)
CGN exit points
Static routed customers (They shouldn't be doing asymmetric routing)
The real reason imho.. is #2 above. desire to keep unnecessary support calls from your call center.