James Webster wrote privately *and* to the list, but misplaced an 'f'; I
won't be snipping much, to save him the trouble of resending. Comments
are inline.
To: ieft-mxcomp(_at_)imc(_dot_)org
James Webster wrote:
Luis Bruno wrote:
they can't query for a new RR type when behind an ISA firewall.
I don't believe that the issue is ISA, but rather that the Microsoft DNS
server isn't able to support new RR types, and they don't plan to do so in
the next 5 year OS development cycle.
The ISA rpc issue that was mentioned was a limitation with the ISA Client.
I would not expect that any sane administrator would install an ISA client
on an internet facing box. ISA support port mapping, and as such has no
issues with pointing to a DNS server that supports new RR types.
I was assuming that a MTA might want to query for MARID info, even behind an
ISA server. So either I've misunderstood your points, or Jim Lyon's in:
http://www.imc.org/ietf-mxcomp/mail-archive/msg01822.html
From what I understood of Jim Lyon's message, if you protect your MTA with
ISA it can't reach out and fetch unknown-to-ISA records.
BTW, my knowledge of Microsoft's products is at user-level.
That said, I suspect there would be MS job security issues with suggesting
that a Microsoft customer use a non-Microsoft product because of
deficiencies in the Microsoft product.
There's an implicit corollary to "Don't fix what ain't broke.". Job security
isn't a valid argument here.
That's the "clean" approach. However, I don't know how hard that is for
the sysadmins. The MTA must be upgraded, that's a given. Would upgrading
DNS be a showstopper?
I suspect the requirements of deploying both MTA and DNS upgrades would be a
showstopper to organizations that have different administrators for Mail and
DNS.
I was thinking about cost of upgrading *lots* of DNS servers; could you give
an example? The one you provided seemed to go around politics; I'd appreciate
if you could explain a bit more.
You should be able to put structured, binary data in TXT anyway; that's
how I read the RFC, anyway.
If you are going to use structured binary data, then this should be a new RR
type. There are bound to be more then a few DNS servers that do not support
this. So once again its the RR/TXT argument.
I've not tested serving random binary data with TXT. However, as I read the
RFC, TXT records contain a string of arbitrary bytes.
Short term (0-5 years) TXT provides a method to quickly deploy a solution.
SPF/XML doesn't really matter since within that time period the vast
majority of the DNS reponses will be no record found. As such the short
term solution should be concerned less with performance and more with ease
of deployment.
Long term (5+ years) there needs to be a solution that is small and fast,
thus a new binary RR record. It is also likely that any solution will
include deployment tools that can convert records from the short term
solution to a long term solution record.
Arguing over the details of the short term solution only moves the
deployment of both solutions out without solving the problem. Making sure
the long term solution is designed correctly is far more important.
Thanks for your time, everyone.
--
Luis Bruno UTM: 29T 629481E 4511776N 576m
"14) Always remember that Windows NT administration is to Unix and WAN
administration, as _Herbie The Love Bug_ is to _Citizen Kane_. Respect
your elders and don't trivialize their work." -- Christian Wagner's Tips