Subject: Re: DNS SRV question on priorities

From: Jeffrey Altman <[email-masked]>
Date: Tue, 9 Nov 99 1:16:04 EST

> > Kerberos Realms are not limited to being Domain names and there
> > definitely is not a one to one correspondence between Domains and
> > Realms.  
> 
> Then why does the draft say to put records labeled with a Realm into
> the Domain Name system?

Because we are searching for a service in a realm.  Not a service in a
Domain.

> The first example in the draft is in error; it says that SRV records
> go at this label in the DNS: Service.Proto.Realm.  If the Realm is not
> equivalent to a Domain Name, how can the records be labeled this
> way?  The site will not be authoritative for records that have
> arbitrary labels that don't match its domain name.

This is not in error.  A DNS can be authoritative for a Realm as well
as a domain.  

> > Your scheme does not help us find the proper location of the services
> > we are looking for.    It just finds the machine name.
> 
> There is already an assigned port number for each of the services you
> are trying to locate.  All that is needed is a machine name.

Not all of the services have assigned port numbers.  Not all of the
services that now have assigned port numbers have always used them.

> I used to maintain Kerberos for Cygnus Solutions...I know how it works.
> In fact we added the code that defaults to treating the domain name as
> the realm name (mapped to UPPER CASE because of POOR KERBEROS DESIGN) and
> the code that tries the hostnames as above.  The method works, is much
> simpler than SRV records, and requires no extensions to the DNS.  You
> borrowed its method for the draft's TXT record search procedure, but added
> an extra level of indirection that gets the design in trouble.

Please explain to me how the use of Kerberos.domain results in me
being able to find the proper machine to use for password updates.
Or the proper machine to use for Kadmin services?
Or handles load balancing the way we want it?

> > DNS SRV records are the proper tool to use in this situation.  If you
> > have questions about thier use please read the draft in question.
> 
> I just read the draft in question.  SRV records are unnecessary to
> auto-configure Kerberos.  We proved that at Cygnus four or five years ago.
> 
> Mr. Altman, you certainly seem to see everything as a nail, worth
> hammering with SRV records!  There are other worthwhile methods, some
> of which even have deployed operational experience.

John, stop making this a personal issue.  Its not.  I am not the only
one who agrees with this design.  There has been support for this
architecture in the CAT working group.  It is implemented in Windows
2000, MIT Kerberos, and Heimdal.   

    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * [email-masked]

---

From: Jeffrey Altman <[email-masked]>
Date: Sat, 13 Nov 99 11:38:17 EST

> That's not the case.   The DNS is case insenstive for doamain names.
> Elsewhere it is case sensitive.  All queries are domain names, hence
> queries are case insensitive.  Some replies are domain names, so some
> replies can be sent in any case.   The DNS docs did say that servers
> should preserve the case entered, and return that where possible, that
> is, that each domain name would have one true canonical case.   But
> while we know COM is in the root servers (not com), we also know how
> many others actually have COM as their domain name ... and in any case
> (no pun...) domain name compression forces the reply case to be the
> query case many times.
> 
> But ...
> 
>   | Hence, if an
>   | administrator is using all upper case realm names then the search for 
>   |   _kerberos.foo.org IN TXT "UPPER.CASE.REALM"
>   | will return all upper case.  And that 
>   |   _kerberos.bar.org INT TXT "Mixed.Case.Realm"
>   | will return mixed case.
> 
> Yes, because TXT is just storing ctaracter data, no knowledge of case
> appears there, whatever is stored is returned.
> 
>   | The only restriction is
>   | that there cannot be two realms that match on a case insensitive
>   | comparison.
> 
> That means, kerberos realm names are (become) case insensitive....
> (at least for many purposes, for others, I expect they would still
> be case sensitive - that is the worst of both worlds ... in this file
> VIX.COM and vix.com are different things, but in that other one they're
> the same...).

There is only one place where Kerberos names MUST be case sensitive.
When the string 'principal@REALM' plus other data is encrypted by the
user's key.  So the only thing that is required is that the TXT record
preserve the case of the REALM when it is returned from the DNS.

Whether or not DNS queries are case sensitive does not matter.  The
only other impact is whether a site would be allowed to have different
realms

  .MIT.EDU
  .mit.edu
  .Mit.Edu

etc.  We have put text in the draft stating that only one case is
permitted.  And it is recommended that it be all upper case as per
Kerberos practice.