"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.
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.)
Ken