Subject: RE: DNS SRV question on priorities

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Thu, 11 Nov 1999 16:46:53 -0800

I like two names. I.e., the master should be
    _kerberos-master._udp.REALMNAME

If the client follows the lookup algorithm in 2052, then use of of the
priority field means that all queries would be divided among the highest
priority servers, unless they are all down. That isn't what you want, I
daresay. It would mean that the mast would get all the AS_REQ and TGS_REQs,
wherease you probably want to load balance.

More bluntly, I do not want each protocol that uses SRV records to say how
to interpret the priority and weight fields -- I want to have a single
function that lots of clients for different protocols can use that will
handle the SRV records processing for them. That means that I want the
priority and weight handling to be as specified in 2052 (or any successor).

Paul

---

From: Paul A Vixie <[email-masked]>
Date: Thu, 11 Nov 1999 20:33:17 -0800

well then at least let's make it master._kerberos._udp.REALMNAME
rather than _kerberos-master._udp.REALMNAME, unless kerberos masterhood
is about to become a separate service?

---

From: Robert Watson <[email-masked]>
Date: Fri, 12 Nov 1999 00:36:23 -0500 (EST)

I agree with Paul's description of the situation and conclusions -- the
two name approach distinguishes the two services that Kerberos offers
(effectively read and write on a database), which seems appropriate. While
this does require Kerberos-specific use of the SRV record, it does not
require Kerberos-specific interpretation of the SRV record fields (such as
load balancing fields), which encourages consistent use of the record for
different protocols/services.  Service requests requiring different load
balancing properties would seem to be different services?

An RFC describing how Kerberos could make use of SRV to retrieve realm
information makes sense.  Dealing with the character set and case issues
is, of course, important, and probably should go into the Keberberos/SRV
draft.  As DNS provides lookup only based on a DNS name (and reverse
lookup as a special case) and is not a general directory service, allowing
DNS to only specify realm information for realm names that can be mapped
to a single DNS name seems to make the most sense.  Given that realm names
can be allocated locally with no regard for the availability of a domain
name (i.e., I can use WHITEHOUSE.GOV as my Kerberos realm name), it would
seem to be impossible to map all realm names to equivilent Kerberos names
anyway :-).  Similarly, presumably there is no expectation that if I
choose as my realm name an unallocatable domain name due to the political
environment (SUCKY.NAME.) that it be resolvable corerctly and return my
realm information.

Dealing with multiple realms mapped to the same domain names is
not something that Kerberos handles well either--krb.realms already
assumes a mapping of one domain name to one realm, and so a given client
generally assumes that if it is performing a realm lookup by name, it will
not have to make a choice between which realm is the right one.  Choice
between local configuration information (krb.realms) and distributed
configuration (DNS) might be implementation, site, or host-specific.  As
sites already have to, on a host-by-host bases, decide which names map to
which effective realm, it would seem to be consistent that DNS reflect
only one realm mapping, and that host administrators wishing to see
another make use of a host-specific local configuration.

This email is largely based on experience with KerberosIV and changes in
KV are probably not accurately reflected. :-)

  Robert N M Watson 

[email-masked]              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services