Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!kddlab!cs.titech!titccy.cc.titech!necom830!mohta
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.unix.internals
Subject: Re: Shared libraries
Message-ID: <182@titccy.cc.titech.ac.jp>
Date: 13 May 91 07:35:33 GMT
References: <1991May11.100712.27111@jarvis.csri.toronto.edu>
Sender: news@titccy.cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 35

In article <1991May11.100712.27111@jarvis.csri.toronto.edu>
	cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) writes:

>| Thus, the capability to return multiple IP addresses are added because of
>| DNS.

> And this is a bug in 4.2BSD, rightfully corrected in 4.3 while they
>were changing it anyways. It just so happens that it doesn't usually
>matter which IP address a gethostname() returns, so few people cared
>about the breakage.

It is not a bug. There is trade off. If multiple IP addresses are
represented by a single hostname, you can't use a hostname to specify a
specific IP address. For example, you can't "ifconfig" with a symbolic
hostname.

If you insist on using symbolic name, you may use hostname alias, which
is unique to each IP address. But, it can not be CNAME. So, it is not
graceful.

On the other hand, with multiple IP addresses, authentification is
simplified, as I already stated.

Your two authentification related examples:

>- things which use hostnames as the permission mechanism,

>- Things which add permissions based on IPs got from hostname lookups;

> Both problems have bitten us locally; they are quite real.

are not problems. It is avoided simply by registering all of hostnames
in the authentification data.

						Masataka Ohta