Subject: DNS SRV question on priorities

From: Ken Raeburn <[email-masked]>
Date: Mon, 8 Nov 1999 16:09:22 -0500

We're looking at using SRV records for locating Kerberos servers.

In the normal case, we want to find the KDCs, do load balancing with
prioritization (and maybe someday, weights and whatever dynamic info
we may have).  This fits in nicely with the current draft.

In certain uncommon cases, though, we need them in an order that
reflects the order in which their databases get updated.  The "master"
KDC would be first priority, first-tier slaves would be second,
second-tier slaves (if any) would be third, etc.  This is for cases
where the password has just been changed and the database update
hasn't propagated yet, for example.  Our current heuristic, the KDC on
the same host as the admin server or password-change server, has
several shortcomings I can describe if anyone cares.

But both cases are the same service, the same protocol.  Part of the
goal is to make do without config files, so storing the information in
DNS is highly desirable.

Using "_kerberos._udp.REALMNAME" (where REALMNAME is a domain-style
Kerberos realm name) for the normal case is pretty straightforward.
Two suggestions have come up for finding the more-quickly-updated
servers, if any.

    _kerberos-master._udp.REALMNAME

This isn't using an assigned service name.

    fast-update._kerberos._udp.REALMNAME (or _fast-update?)

This is using the right service name, and generalizes easily, but adds
more structure to the naming than is indicated in the SRV spec.

We Kerberos developers that have discussed it seem split on which way
to go.  (Not a big point of contention, just different preferences.)
Any suggestions from the DNS side?  We could just go off and flip a
coin, but if this (multiple prioritizations based on different
characteristics) is something anyone else is likely to be able to make
use of, maybe a general recommendation can be made by those with The
DNS SRV Vision, and we'll just follow it for Kerberos.

Everyone I've talked to about it at IETF so far has said, "well, you
could do <one of the two above>; you should really talk to Paul,
though, but he's not here"... :-)

Ken

---

From: John Gilmore <[email-masked]>
Date: Mon, 08 Nov 1999 17:21:16 -0800

Putting Kerberos realm info into the DNS?

Has the Kerberos crowd finally bought into the idea that a Realm really
is the same thing as a Domain Name?  I tried proposing that years ago
and was shot full of holes.

If so, what's wrong with the old scheme of "kerberos.REALM.NAME" as
the master, and "kerberos-1.REALM", "kerberos-2.REALM", etc as
additional slave servers?  Doesn't need any bogus SRV records.

	John

---

From: Greg Hudson <[email-masked]>
Date: Mon, 08 Nov 1999 21:40:36 -0500

> Has the Kerberos crowd finally bought into the idea that a Realm
> really is the same thing as a Domain Name?  I tried proposing that
> years ago and was shot full of holes.

We got better.  (I don't know who made what arguments back then,
really.)

It's interesting to draw an analogy between Kerberos ("the realm
identifier should look like a domain you own, but nobody can do any
DNS operations with it") and XMLNS ("the namespace identifier should
look like a URL you own, but you can't actually look it up").

> additional slave servers?  Doesn't need any bogus SRV records.

Is there any precedent for a standard protocol hardcoding A records
with specific names within a domain as server names?  What if I want
to set up Kerberos within a domain and somebody already holds the
hostname "kerberos" from six years ago because they like Greek myths?
Why should Kerberos use a method which was rejected for name servers
and mail, when it could use an emerging standard instead?

---

From: Paul A Vixie <[email-masked]>
Date: Mon, 08 Nov 1999 18:54:27 -0800

> Putting Kerberos realm info into the DNS?

mapping, not putting.

> and was shot full of holes.

and rightfully so.  the character sets are differently restricted, for example.
so if you tried to say they were the same, you should've been shot down.  but
if you'd said that one could map to the other, that should've been alright.
see [RFC1034 3.3] for what i mean by "mapping."

> additional slave servers?  Doesn't need any bogus SRV records.

as it's just a convention and nobody outside cygnus ever automated it, i don't
see that it has the weight of an installed base.  therefore we're going at this
from first principles -- and this is the type of thing SRV was *made*for*.  (i
guess i'd love to know why SRV is bogus?)  and furthermore, microsoft's Win2K
product uses SRV RR's to locate kerberos servers, and we all think that that
product will have the weight of an installed base.

---

From: Robert Elz <[email-masked]>
Date: Tue, 09 Nov 1999 16:52:43 +1100

Date:        Mon, 08 Nov 1999 18:54:27 -0800
    From:        Paul A Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | the character sets are differently restricted, for example.

This is a bit difficult to believe, as the character sets in the DNS aren't
restricted at all.

Which says nothing at all about whether Kerberks realms ought be treatable as
domain names, or whether SRV records ought be used for finding Kerberos
servers - just that as a reason why not (of the former of those) this would
not be it.

kre

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 09 Nov 1999 09:39:23 -0500

>several shortcomings I can describe if anyone cares.

You can use the priority field in the SRV record to do this.

>    _kerberos-master._udp.REALMNAME

There is no need for a second name, but DNS dos not care how many 
names are used. 

>though, but he's not here"... :-)

My suggestion is: talk to Levon, the current editor of the document. 

	Olafur
--------
Olafur Gudmundsson - NAI Labs 			(443)-259-2389 
The Security Research Division of Network Associates, Inc.
[email-masked]  [email-masked]  Private: [email-masked]

---

From: Ken Raeburn <[email-masked]>
Date: 11 Nov 1999 00:44:12 -0500

> You can use the priority field in the SRV record to do this.

?

In my mail I described two different situations in which we may want
to look them up.  Both may use priorities, but with different goals,
and therefore different prioritizations.  Each, by itself, can make
use of the priority and weight fields.  Without some bizarre
interpretation of these fields, I can't get two different
prioritizations without two different names.

> There is no need for a second name, but DNS dos not care how many 

I think there is a need for a second name.  DNS itself may not care
how many names we use (after all, they're just names), but if this
could in any way be interpreted as a precedent for services that might
want different prioritizations under different circumstances, it
should be the right precedent.

> My suggestion is: talk to Levon, the current editor of the document. 

Yes, I probably should have grabbed him after the SRV discussion here
at IETF, but I didn't, and I probably won't recognize him if I see him
again (poor memory for faces).  But I expect he and the other authors
of the current and preceding versions, and anyone else with a strong
opinion (hi John :-) will see the mail here...

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 17 Nov 1999 08:41:10 -0600

I counsel against finding the "quicker update" KDCs by means of any
records stored at a node like foo._kerberos._udp.REALM, since by and
by there's likely to be a standardized getsomethingbyname(...)
function that will only put together _service and _transport.
Instead, I'd suggest a new name which in an /etc/services file is
just a nickname for the "kerberos" service, but which in DNS points
to the desired subset of KDCs.  Perhaps kerberos-pri.

			Matt

---

From: Ken Raeburn <[email-masked]>
Date: 18 Nov 1999 05:45:33 -0500

> function that will only put together _service and _transport.

If this function maps <service,transport,hostname> to a list of ports
and host names/addresses, then it'd be appropriate for Kerberos only
if it does *not* fall back to using /etc/services port numbers and the
"host" name supplied, in the case where no SRV records exist.
Assuming a KDC for ATHENA.MIT.EDU can be found at port 88 on the host
athena.mit.edu is not currently a good idea; we'd be better off with
John's kerberos{-N}.REALM heuristic.

In time, I hope SRV records will become the dominant means of
distributing Kerberos server information, and perhaps then we can do
away with static config files (at least, for the hostname info), and
then this might be a reasonable fallback, similar to not having an MX
record.  But for now, I think it's better to report that the realm's
KDCs aren't known, because in the absence of such records, missing
config file entries are far more likely than a site actually choosing
to use the realm name (which is frequently the name of the domain) as
the KDC host name.

And there are a few sites around still not capable of entering SRV
records in their zone files.  Embarassingly enough, we (MIT) seem to
be one of them.

> to the desired subset of KDCs.  Perhaps kerberos-pri.

If no such fallback is in place, no /etc/services entry for the second
name is needed, and since the getsomething routine would basically be
doing only the SRV lookup, Jeffrey's "foo._kerberos" service name hack
would almost have to work, *if* the implementation simply joins the
strings with appropriate separators to get an FQDN string to look up,
or something functionally equivalent.

This last point sort of emphasizes why I wanted to make sure this
question was brought up here.  The getsomething function (AFAIK) has
not been standardized yet.  There's probably still time to decide what
should happen if a dot is present in the supplied service name, which
might be implied by which approach, if any, is "blessed" for use in
this sort of situation.  Or maybe a different function should be
defined, with an additional parameter.

Ken