You are incorrect on both counts.
I wrote at considerable length last week regarding the issues on the
client. They are a very big deal.
You're going to tell me this is a very big deal?
No, I'm not; I did that last week, and, since I won't be able to be more
clear than I already attempted to be, I am not going to repeat my
thoughts.
And, prompted by your mail, I just went and double checked the
server
issue: the DNS server in Windows Server 2003 does NOT support
the syntax
of RFC 3597 or any other means to define instances of new RR types
in
either its GUI editor or in its zone file text parser.
These are implementation issues only, and testing aside, this RFC just
doesn't seem so hard to code for. Expected in Win2K Service Pack 5,
perhaps?
Testing cannot be brushed aside; as I pointed out previously, a full
regression on Windows is more than a calendar month. Especially in
service packs, the bar is very very high regarding changes being
critical and important in order to justify the risk of destabilization.
There is no realistic hope of this sort of new functionality being
introduced in a service pack: the benefit to be gained simply is no
where near large enough compared to the status quo.
Or I could just swap out NTDNS with BIND 9 which supports Active
Directory
and dynamic updates just fine, and support a MARID or other record
type.
I trust this was proposed in jest; it's certainly not the case that as a
product requirement for, say, Microsoft Exchange, that this could be a
necessary course of action for customers.
Moreover, there is significant loss of functionality in this proposed
route, among them the loss of ability to store the DNS zone data *in*
the active directory (which has replication and other administrative
benefits), not to mention the loss of GUI tools, increased training
costs for customers, and so on.
To be as clear as I can: Windows implementations of MARID cannot (and so
will not) query for new RR types, nor can they serve them up from their
DNS servers. Therefore, even if MARID were to adopt some dual-use
approach involving both TXT and some new RR type, the Windows hosted
products from Microsoft will not query for the new RR type, nor will
they serve the new RR type for records that they publish.
I thus believe (though others may disagree, of course) that for reasons
of soon-to-be-legacy deployment that we as an industry will be stuck
with the TXT record variation forever.
Which leads me to the conclusion that having an additional RR type as an
option does nothing more than complicate the world and increase
confusion and operational costs, all for entirely zero gain.
Bob