[1051] in Kerberos_V5_Development
Re: full explanation of proposed krb5_sname_to_princ change
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Thu Apr 11 12:15:53 1996
Date: Thu, 11 Apr 1996 12:15:33 -0400
From: Theodore Ts'o <tytso@MIT.EDU>
To: Sam Hartman <hartmans@MIT.EDU>
Cc: "Theodore Ts'o" <tytso@MIT.EDU>, Sam Hartman <hartmans@MIT.EDU>,
krbdev@MIT.EDU
In-Reply-To: Sam Hartman's message of 10 Apr 1996 22:55:55 -0400,
<tsl20lvxydg.fsf@tertius.mit.edu>
Err no. I don't think so.
Consider the following situation.
athena.dialup.mit.edu resolves to 3 ip address 18.172.0.2, 18.172.0.3,
and 18.172.0.4. Each of these address have a reverse pointer to
dialup-1.mit.edu, dialup-2.mit.edu, dialup-3.mit.edu. My solution is to
have a canonicalization function which resolves athena.dialup.mit.edu,
gets an IP address, and then does a reverse-resolve to get one of
dialup-[123].mit.edu. This is an address which when forward resolved,
gets you one and only one IP address.
Alternatively, 18.172.0.2, 18.172.0.3, and 18.172.04 could all reverse
resolve back to athena.dialup.mit.edu. But in that case, your solution
won't work either, unless the three machines share a srvtab key for
host/athena.dialup.mit.edu. If the three machines share a srvtab key,
then everything works fine.
The only case where your solution would work and mine would fail is if
athena.dialup.mit.edu resolves one of the above three addresses --- but
so do dialup-1.mit.edu, dialup-2.mit.edu, and dialup-3.mit.edu. But I'd
just as soon consider that a pathalogical case, and not deal with it. I
can't think of a good excuse for doing anything like that.
- Ted
