So it sounds like their database *will* support the additional RR
values, it's just that they don't make it easy to use them.
Until they get their standard interface fixed, it sounds like Microsoft
(or a 3rd party) could provide an alternative interface that
additionally stored the RRs in a separate database that would survive
the reboot, and included a service that ran at boot time that would
reload those additional RRs into the real database.
Please correct me if I'm misunderstanding something here.
Tony Hansen
[EMAIL PROTECTED]
Hallam-Baker, Phillip wrote:
> The statement made by Microsoft was that none of the Microsoft DNS
> servers have the ability to publish new RRs without breaking the
> administration model completely. In particular they have no
> administration tool for entering the RRs and no way to save them out.
>
> It is possible to enter RR values into the database by non standard
> administration interfaces but not by a method that survives a reboot.
>
> Given the amount of disinformation and the refusal of the DNS group to
> accept the statements made by Microsoft then I am not too inclined to
> accept heresay statements on the subject now.
>
> For deployment of a new RR to be possible it must be supported to
> production quality for the platform concerned. On the windows platform
> that means that it has to be possible to enter the RR through the
> standard administrative interface.
>
>
> There are a few changes in Windows 2003 R2. In particular the server can
> be configured to allow through DNSSEC records from other DNS servers and
> to accept zone transfers for unsupported records. I am unable to find a
> description of how to enter an unsupported RR through either the command
> line or GUI.
>
> On the plus size the default UDP packet size is 1260 bytes, not 512. If
> we are all so confident that new RRs will work then why does everyone
> (Olafur included) pay such strict attention to this particular limit?
>
> I think that what we are seeing here is more wishful thinking by people
> who are not going to be damaged by the consequences. If they can get us
> to make DKIM dependent on deployment of the infrastructure necessary to
> support new RRs then they don't have to do that job.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
