It is both; a list of alias names for a host, and a list of addresses
that correspond to the canonical name ...
>So all machines support char **h_addr_list rather than the older
>h_addr? We can probably differentiate using #ifdef h_addr
Probably not, unfortunately
>which is set to a macro if there IS a list. I assume you need then
>separate entries for the virtual duplicate node and the actual
>real nodes, so that you can speak to them sepately. Is this normal
>and OK?
Yes, you need seperate entires for the pseudo host and the real hosts
that are actually providing the service. This looks like the following:
www-server.foobar.domain. A 1.2.3.4
A 1.2.5.6
A 1.2.7.8
aeschylus.foobar.domain. A 1.2.3.4
euripides.foobar.domain. A 1.2.5.6
sophocles.foobar.domain. A 1.2.7.8
ie. the virtual hosts www-server appears to be multi-homed, but each
"home" is on a different real machine.
>Is this normal and OK
Well, it's technically acceptable, but it is hardly a normal requirement
in the first place.
There is one possible gotcha here: some machines verify DNS lookups
by checking the forward lookup against the reverse. In this case such
a check would fail, as the reverse is likely return either aeschylus,
euripides or sophocles (this depends on what you put in the relevant
in-addr.arpa domain, whcih is how reverse lookups work). I hope that
this checking is done by apps calling gethostbyaddr after each
gethostbyname, rather than being being built in gethostbyname
Adding support for multiple addresses into the clients is useful
anyway... if only to support real multihomed machines
Kevin Hoadley, Rutherford Appleton Laboratory, khoadley@ib.rl.ac.uk