In <29A22C3B-A7F6-11D8-905D-000A95B2B926(_at_)cisco(_dot_)com> Patrik Fältström
<paf(_at_)cisco(_dot_)com> writes:
Some MARID specific points to ponder:
With the hope being that MARID is a powerful weapon to be used to fend
off spam, it is only a logical conclusion that spammers will resort to
attacks on the DNS given their past redoubling of efforts to defeat
anti-spam measures.
MARID is a weapon to fend of domain name forgery. It will have an
impact on spam, but it is indirect. As such, I think it will be a
much smaller target than other DNS-based anti-spam systems such as
DNSBLs and DNSWLs.
There has been a fairly long history of spammers' attacks on DNSBLs,
mostly in the form of DDoS attacks, legal threats, and social
engineering. Many of these attacks by spammers have had a lot of
resources dedicated to them (money, technical knowledge, bandwidth,
etc.) I have yet to hear of an attempt to do cache poisoning and
such. I think that folks that run the CBL, SpamCop DNSBL, SPEWS, or
SBL are a much more profitable target for cache poisoning and such,
than individual MARID records.
I don't mean to dismiss the concerns with DNS security, but I also
think we should be careful not to overestimate the problems either.
Given the size constraints on DNS records, it be may desirable to
avoid more verbose syntaxes.
As a point of reference, the median size of the SPF record on the SPF
adoption roll is 34 characters, 76.8% are shorter than 50 characters,
91.3% are shorter than 100 characters and 99.8% of them are shorter
than 200 characters.
Therefore, it is possible to define a new record
type with a more bandwidth efficient binary format or perhaps a
tokenized or compressed form of a more verbose text syntax.
For what it is worth, the libspf-alt implementation already
byte-compiles all SPF records into tokenized, network portable binary
format. It is hard to reduce the size of most SPF records much since
they are so short anyway. The libspf-alt format will reduce the size
of most longer SPF records by around a factor of 2. The AOL record,
for example, shrinks from 209 bytes to 74.
Despite this, I an dubious about the usefulness of the savings of such
a binary format.
However,
it should be noted that new DNS record types cannot take advantage of
the existing DNS label compression.
Things like the %{d} macro (which byte-compiles to 2 bytes in
libspf-alt) help reduce the need for DNS name compression.
Consideration should also be given for the need of wizards and other
administrative assistance software in the face of complex text
syntaxes [...]
Taken one step further, it is just as easy for a
wizard to construct a binary form as it is to construct a text syntax.
The SPF wizards are great for constructing your initial SPF record.
They provide a form of learn-by-example. However, I think that many
SPF records are created without the use of such assistance and that
being able to read/understand and tweak the SPF record after the
initial creation is very important.
So, a MARID wizard might be able to let someone easily create a binary
record like:
sshfp TYPE44 \# 22 01 01 c691e90714a1629d167de8e5ee0021f12a7eaa1e
However, that is completely opaque about what it does and how it could
be modified.
-wayne