>> 	hmm.  i'm preferring not to change timings for calling res_init(),
>> 	as your change would call stat(2) every time we call gethostby*...
>> 	maybe having some timer/time offset between stat(2) calls, so that
>> 	we won't check it every time?
>Calling gettimeofday(2) before stat(2) to make such interval would only
>increase overhead, though.  Anyway, gethostby*/get*info call numbers of
>system calls not and the overhead added would be negligible.

	stat(2) won't try to access buffer cache... anyway,  i also fear there
	are applications that relies upon non-re-read of /etc/resolv.conf.
	i do this in operations - like, i want certain daemons to use
	nameserver A, while others to use nameserver B.  I change
	/etc/resolv.conf before invoking A, and after invoking A.

>> 	i guess it nicer if we can add "destination port number" argument,
>> 	so that we can talk with multiple local instances of nameserver, like:
>> 		nameserver 0.0.0.0 10053	# mdnsd
>> 		nameserver 0.0.0.0 53		# normal named
>> 	it would eliminate the need for dynamic res_init().  not sure if
>> 	it is workable or not.
>Adding "destination port number" argument is not a bad idea, but I don't
>think it is the right way to solve this problem.
>	- named running on localhost with normal root.cache isn't usable
>	  to resolve the node in private networks.

	okay,

>	- is mdnsd suitable in any environemnt?

	i don't understand this question.  i'm not advocating mdnsd in the
	above, it's just an example.

>	- you may have to wait some seconds anyway to confirm there is
>	  no response.

	i don't understand the context aither.

itojun