Patrik,
PF> As input to the discussion, I am working on a document regarding adding
PF> data to DNS for new applications
excellent!
PF> Therefore, deployment a MARID record must also
PF> consider the near-future deployment of DNSSEC.
On the one hand, it seems clear that the spam hackers will increase
the level of attacks on the DNS, as you suggest.
On the other hand, it's not clear to me what it means for the Marid
efford to "consider the near-future deployment of DNSSEC". I cannot
readily think of what Marid could or should do differentially.
If you are suggesting that Marid can assume that there will be
significant use of DNSSec and that the DNS will, therefore, be more
protected, that's nice but I'm not sure what to do with it. I should
also note the long history of problematic outcomes in making
assumptions about adoption and use levels, especially for capabilities
that have been around for awhile but have not gotten adopted or used
much.
PF> Additionally, the
PF> development and deployment of DNS is not standing still. It is
PF> reasonable to expect new releases of DNS software
Again, how should Marid use this observation?
PF> Given the size constraints on DNS records, it be may desirable to avoid
PF> more verbose syntaxes.
good point.
PF> Consideration should also be given for the need of wizards and other
PF> administrative assistance software in the face of complex text syntaxes
another good point.
PF> Regarding fear for new RR Types, interoperability testing of RFC 3597
PF> has just started,
On the other hand, we again must note the poor record of adoption of
new record types, within any sort of near-term timeframe. While it is
always possible that things will get quicker, an established
performance history suggests caution.
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>