"Theodore Y. Ts'o" <[EMAIL PROTECTED]> 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
