I fail to see the connection between an argument that a 20%
That's not what I'm talking about. Consider the whole post,
particularly paragraphs 1-3. Arrgh.
The URL is above.
How about you or Doug try to post a clear attack scenario
that shows exactly how such an attack would be performed?
I have great difficulty parsing the paragraphs, let alone making
sense of statements such as
"If used in the normal fashion, no parser is required to utilize DNS
answers, so the introduction of a parser increases vulnerabilities. "
It is a matter of indisputable fact that all interpretation of
DNS records requires the use of some form of parser. So the
above appears to be nonsense.
"The
less rigid and more extensible the syntax, the greater the
vulnerabilities. "
It is also a matter of indisputable fact that XML can be parsed
using a finite state machine of less than 20 states acompanied by
a simple stack. I have written such a parser several times.
It would therefore seem to me that the competence of the coder is
the significant factor here rather than the choice of syntax
which is at any rate moot at this point.
Having got to the end of paragraph 1 I am unable to find any
issue of relevance outside the XML debate, is it possible that
you have given the wrong URL?
"An attacker "jamming" the checking mechanism might set up DNS servers
for domains they control that respond erratically and offer complex
record sets with small TTLs."
So a DDoS attack on your own ability to send email. this can
be addressed by a security consideration. If you have to resolve
more than X records then consider the data spurious and reject
the mail.
"As example, a mail server is receiving 50 messages per second that
average 4 K bytes in size."
Assume that three contain powerpoint presentations of 1Mb, four
contain word documents of 500Kb and five pictures of little Timmy.
that would be a more realistic load, but it would prevent the
dire conclusion
"These 10 queries will also add to the traffic at 350 bytes per record a
total of 4K bytes of additional traffic for a doubling of the network
load."
assuming the attack is present on every email. And the mail server
does not get clever and stop accepting emails from malicious IP addresses.
Estimates of the number of compromised hosts on the Internet vary, but
the highest number in a botnet tends to be in the tens of thousands.
If the attacker is using a different bot for each connection that
is 3000 bots per minute, 180,000 per hour.
This is an attack I really really would like to see, we could map
out the zombies on the Internet pretty quick.
[Why not just DDoS the email server direct and have done with it????]
That is an issue that calls for a security consideration, not
hysterical subject headers.
Ah, that's what set you off. Please address paragraphs 1-3 or don't
respond.
Please give a clear statement of the issue you are trying to raise.
Repeated claims that the issue has been stated do nothing at all.
If malicious.com or compromised.com have a malicious record in
their DNS it should become apparent quite quickly.
I don't see how. Say 9/10s of a domain's record resolves.
How is this
domain identifiable as malicious?
Maybe it's just under attack.
If it is under attack then it probably should be ignored until
it recovers. All the mail 'from' that source is most likely spam
anyway.
Also remember that the sender has to be holding an open TCP
session during this process with a known source IP port. This
is not exactly an anonymous attack.
Again, how is a malicious actor identified automatically?
By logging the IP address of the source of the attack.
The argument makes no sense unless you can state which part of the
DNS is going to be attacked and how such an attack would make it
easier to send spam.
Same way taking down BLs works. It makes 'em problematic (e.g
unreliable and/or very resource intensive), so folks stop using 'em.
BLs have a single point of failure that is similar to the problem
of running core DNS, you take down one part of the network and in
time the rest of the net grinds to a halt.
You have failled to show that there is a dependency that looks anything
like the dependency that a mail server has on a BL or on core DNS.
Seems to me that any such attack has the problem that the attack
and likely motive become immediately obvious to sender.com. All
we need to do is to work out a way to close the loop.
And how do we do that?
Reporting mechanism to allow sender.com to tell receiver.com that it
is observing large numbers of packets that appear to be emitted
from that domain.