On 6/28/04 7:53 PM, Hallam-Baker, Phillip sent forth electrons to convey:
Again, how is this domain identifiable as malicious? Many of your
points are predicated on having this ability.
I don't see how. Say 9/10s of a domain's record resolves.
How is this
domain identifiable as malicious?
If malicious.com or compromised.com have a malicious record in
their DNS it should become apparent quite quickly.
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
Sorry, but what attack? You have to identify the attack as an attack
first; see above.
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.
What part of "it makes them very resource intensive, so folks stop using
'em" don't you understand?
Same way taking down BLs works. It makes 'em problematic (e.g
unreliable and/or very resource intensive), so folks stop using 'em.
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.
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.
Here's the three paragraphs, with some editing by me.
I'm sorry if you don't understand them, but they are clear.
It has nothing to to with XML (which is dead, WRT MARID), at least now.
Any mechanism introduced that stems the flow of UCE will be subjected to
intensive attack. ... As the allowable answer from DNS is small, any chained
records further increases vulnerabilities by increasing both resources
and time required to process a message.
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. The attacker then sends messages from
their domains in an attempt to exhaust resources as a means to have
recipients disable the checking processes within the channel. (If on
average a small enterprise uses two outside services, then normally
there will be a need to chain these records as it would be prohibitively
difficult to administer otherwise. These outside vendors may in turn
also outsource for yet more chaining.)
For example, a mail server is receiving 50 messages per second that
average 4 K bytes in size. If using the SPF mechanism, checking DNS
data is indeterminate as there is no limit for the number of sequential
queries required to converge upon an answer. RFC1035 indicates 5 to 10
seconds should be considered a worst case resolver interval. If there
becomes an average of 10 queries with an average of 5 seconds a query,
then this limits each process to about 1 message about every minute.
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. The mail server may normally handle 1,500 simultaneous processes,
but at 60 seconds per process, the mail server is reduced to only
running 25 messages a second. This may still represent the same amount
of network traffic, just half as much mail gets through the network.
You cannot redefine the size of the emails the attacker sends to make the attack less effective.