From: Ken Raeburn <raeburn(_at_)MIT(_dot_)EDU>
Date: 19 Dec 2000 09:02:52 -0500
"Theodore Y. Ts'o" <tytso(_at_)MIT(_dot_)EDU> writes:
> Kerberos tried to deal with this problem by talking about "canonical
> domain name", which it tried to define as being the name that you got
> when you took a DNS name, forward resolved it to get an A address, and
> then reverse-resolved it to get a DNS name. But this didn't work in
> many cases, sometimes we got back an unqualified name, and in many cases
> this scheme totally failed due to load balancing DNS servers, etc. I
The MIT implementation does that, but I always thought that was just
because certain gethostbyname implementations wouldn't return the
canonical name (in the CNAME-processing sense) without doing this
dance. Because of the server-cluster or load-balancing case, I've
been thinking we should change it. The spec has never been quite that
precise on this point; probably something we should fix for
RFC1510bis.
RFC-1510bis always ignored this issue, and at some level, it strikes at
the heart of the whole name canonicalization mess. RFC-1510 assumes
that you know the authentication name of the service. The problem is
that it's silent on that the issue of how you discover said
authentication name. What was implemented in the MIT implementation
isn't actually specified anywhere; it's a local implementation hack.
And, as Microsoft rightly points out, because we rely on the DNS, it's
not really secure, either. Unfortunately, fixing this problem is hard!
The problem with using the CNAME target as the authentication name is
that that while it works for some load-balancers, it fails for others.
It all depends on whether the load-balancers return a CNAME or an A
address. Simply just using the CNAME also means that you need to also
replicate the domain name search rules. If I type "telnet tsx-prime", and
I have a domain name search rule of "valinux.com mit.edu", then the name
which should be used is tsx-prime.mit.edu. Yet if I type "telnet
shells", I should get the name shells.valinux.com. This reason is
historically the reason why we played the forwards and backwards dance
--- because we wanted to get that case right.
So when checking gethostbyname implementations, if you have to check to
see whether they return the FQDN both in the CNAME case, and in the case
where an unqualified domain name is typed by the client. Many
gethostbyname implementations will fail on one or the other....
> suspect the reason is that as our domain name friends would tell us,
> there is no such thing as a "canonical domain name" for a host.
> Kerberos tried to invent such a concept, but it didn't work all that
> well. I would much rather have some real IP-level endpoint identifier.
> If that's what we're securing, that's what we should be using.
If you get hosts with multiple addresses (or, under IPv6, multiple
prefixes), an address-based identifier is still not unique. (And,
unpleasantly enough, there are server implementations that split a
single IP address across multiple machines.)
True enough. (Although some people actually want to be able to
authenticate and distinguish between specific ethernet interfaces; they
mostly fall into the category of "sick puppies", but it's indicative of
the naming problem that we have. We don't have general agreement on
what the semantics of the names that we do have, and as a result the
semantics are overloaded as all hell, with different people taking
advantage of different aspects of the overloaded semantics, making it
extremely difficult to separate them out cleanly. Ack!)
- Ted