Subject: Re: DNS SRV question on priorities

From: Jeffrey Altman <[email-masked]>
Date: Mon, 8 Nov 99 21:07:46 EST

> 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
> 

Kerberos Realms are not limited to being Domain names and there
definitely is not a one to one correspondence between Domains and
Realms.  

Your scheme does not help us find the proper location of the services
we are looking for.    It just finds the machine name.

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.

    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: John Gilmore <[email-masked]>
Date: Mon, 08 Nov 1999 18:46:02 -0800

> definitely is not a one to one correspondence between Domains and

Then why does the draft say to put records labeled with a Realm into
the Domain Name system?

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.

> 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.

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.

> 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

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 09 Nov 1999 10:06:05 -0500

>arbitrary labels that don't match its domain name.

I would personally call it an oversight (one that Ken Raeburn also
pointed out to me).  The draft should explicitly point out this is
only applicable to realms that are in the form of a domain name.
Something for the next revision.

>simpler than SRV records, and requires no extensions to the DNS.

Well, I wouldn't personally call SRV records an "extension", but somehow
I don't think it's a point worth arguing (if Kitchen Sink went forward,
we could use that!  Just kidding ...)

I believe I was the first person to come up with this idea (Microsoft
seemed to start using this at the same time, so they might have been
first, but it's not really important who was first).  Let me explain my
thought process regarding it.

It became apparant very quickly during our deployment that the
configuration file simply didn't scale.  This I believe is not in
dispute.  So I started looking around for solutions.

I came across the Cygnus "hack" (for I believe it can only be
called that).  When talking with other Kerberos people about this,
they pretty much universally said, "Yes, Cygnus did this thing,
but nobody else did".  I got the strong impression from everyone
I talked to that no one was very happy with this idea.  More
importantly, no one seemed to be _using_ it.  The code was only
implemented in the Cygnus Kerberos code, and I didn't get the idea
that many people were using it (this was not based on any hard
numbers .... there may be thousands of sites using it, I don't
know).  Lastly .... it just seems wrong, somehow, to overload
the namespace of A records in this way.

I came across SRV records, and they seemed like The Right Thing.
More specifically:

	- You can specify priorities and do load balancing
	- You can specify alternate port numbers for realms
	  (which I know a lot of people do when running multiple
	   realms on the same machine).
	- There was already precedent for using DNS records to store
	  this information (DCE uses the AFSDB records for locating
	  DCE servers .... okay, I'm not sure that I should use DCE
	  for justification, but I was trying to get a sense of what
	  was out there at the time).

I asked around.  Most comments I got were favorable (some people were
worried about spoofing, but AFAICT the same issue exists with any
DNS-based location scheme).  When I found out that modern DNS servers
supported it _and_ that Microsoft was going to use it, it made sense
to do it.  I wrote some code that implemented it and tested some
deployment - it worked out pretty well.  As Paul has already said,
this is what SRV records were designed for (I know you don't like them,
but other people do :-) ).

>You

Explain, please?

>auto-configure Kerberos.  We proved that at Cygnus four or five years ago.

Your solution doesn't solve the _other_ half of the problem ... how
do you figure out which realm a particular host belongs to?  In my
experience, this has been a HUGE problem, especially in complex
environments.  I admit the solution proposed in the draft isn't wonderful,
but I'm open to better suggestions.

--Ken

---

From: John Gilmore <[email-masked]>
Date: Tue, 09 Nov 1999 15:58:47 -0800

> >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.
>
> Explain, please?

When determining what realm an unconfigured Kerberos client is in, the
Cygnus procedure just added "kerberos." to the front of the domain
name, then started dropping prefixes until it found an A record for
that name.  The realm name was the same as the domain suffix (if you
are on foo.cygnus.com and don't find kerberos.foo.cygnus.com, you try
kerberos.cygnus.com, find it, and your realm is "CYGNUS.COM" and your
master server is kerberos.cygnus.com).

If you follow the same procedure, but looking for a TXT record, the
contents of the TXT record could point you anywhere in the name space
as the realm name.  It could say `_kerberos.cygnus.com TXT
"OUR-FAVORITE-REALM"'.  This realm name cannot be looked up in the DNS
to find the master server, though the code will try.

Furthermore, three Kerberos realms such as "MIT.EDU", "mit.edu", and
"Mit.EdU" are distinct and independent realms in case-sensitive
Kerberos, but these all map to the same domain name.  There is no way
for the DNS to represent different SRV records for these three different
realms.  The draft doesn't even notice this problem, let alone address
it, because it's perpetually confused about the name spaces.

> importantly, no one seemed to be _using_ it.

They all continued to maintain duplicate copies of hand-edited config
files on every host in their realm?  And you are taking their advice
on how to design a scalable system with no manual configuration?

I don't see how looking in the DNS for A records with particular name
prefixes to find a server is any more of a hack than looking in the
DNS for TXT and SRV records with particular name prefixes to find a
server.  The only difference is that the SRV RFC came out in between
and "legitimized" this idea of distinguished prefix labels.  Let's
compromise and agree that if we had looked for MX records it would
have definitely been a hack.  :-)

> but I'm open to better suggestions.

Here's a suggestion.  What's wrong with making the realm name be a
suffix of the domain name?

Keeping the realm name-space and the domain name-space separate
provides some sort of flexibility, but as far as i know nobody needs
that flexibility, and it ties attempts to do simple DNS integration
into knots.  You mention complex environments, and indeed two or three
of those might have to either rename their realms, rename their hosts,
and/or add some cross-certification keys, if they wanted to use your
new proposed protocol -- but isn't that the only cost of unifying the
name spaces?  It's not like Kerberos is wildly popular and hundreds of
thousands of sites would have to change.  Nor would this affect people
running old code and old protocols with config files, which would
continue to work.

> Something for the next revision.

It's more than an oversight -- it's fundamental to the structure.

Declaring a simple rule that realm names and domain names *are* the
same name space would eliminate whole piles of confusion -- not just
in the code, but in the minds of users and administrators.  (Cygnus
documentation recommended making them the same, except making the realm
name be upper case to appease the gods.  But then the rest of the doc
had to explain whether each name in each context was a realm or a domain name.)

The draft perpetuates the separation of name spaces, by having a
record that points from one namespace to the other.  It then compounds
the confusion by attempting to look up one sort of name in the opposite
name space!  A mere statement that "this only works for people who
pick the same domain name and realm name" is insufficient to paper
over the philosophical problem.  What *is* a realm name, and why
should it be *different* from a domain name?  The community has failed
to answer that with anything more than argument from authority.

	John