Standard mechanisms to manage domain->realm mappings in multi-domain infrastructure

[Newman, Edward (GTI)]

What are the preferred mechanisms to manage DNS domain to Kerberos Realm
mappings in large implementations? 

I want to avoid having to redistribute a krb5.conf to every client each
time this changes so was wondering how others have solved this problem. 

Need some solution that supports a combination of the following
platforms:

- Active Directory 2003
- MIT Libraries
- Sun Java JDK
- Quest Vintela
+ other proprietary implementations

Looking online suggests the following:

1) DNS TXT records

- DNS TXT records used to link a DNS domain to Realm via
_Kerberos.<Domain-name>
- Apparently vulnerable to MITM attacks (is this an issue in closed
environments?)
- Appears to be support by MIT & Heimdal but not by Java JDK Kerberos
libraries or various commercial products
- Still an IETF draft (draft ietf cat krb dns locate 02 txt)

2) Kerberos Server referrals

- KDC returns referrals to client when request made to local environment
- supported by Windows AD 2003 & MIT (limited documentation on how
mappings managed for referral process)
- Still an IETF draft (draft ietf krb wg kerberos referrals 09 txt)

3) Standard krb5.conf/ini [domain_realm] mappings

- appears to be best supported by various products
- pain to deploy in large environments


Thoughts? Suggestions? Is this on the Kerberos-wg plan?
--------------------------------------------------------

This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
--------------------------------------------------------