RE: gethostbyname (was Re: (DNS) draft wording for W.G. review. )

If the API change will require new implementations of gethostbyname(),
why not get it (and friends) to do the caching, or reasonably efficient
access to the local resolver's cache, instead of pushing this into the
app layer? 

>From: 	Donald E. Eastlake 3rd[]
>Sent: 	Wednesday, March 27, 1996 11:48 AM
>Cc: 	Anawat Chankhunthod;;
>Paul Vixie;
>Subject: 	gethostbyname (was Re: (DNS) draft wording for W.G. review. )
>Note that for DNS security, the prefered interface to the gethostbyname
>functionality needs to change anyway to return an indicator as to
>the information has been authenticated, is from an insecure zone so it 
>can't be authenticated, etc.  Perhaps while that additional return info
>in being added, adding return of the TTL so an applicaiton could cache 
>the data and discard it properly would be reasonable...
>On Wed, 27 Mar 1996 wrote:
>> Date: Wed, 27 Mar 96 14:08:11 -0500
>> From:
>> To: Anawat Chankhunthod <>
>> Cc:,
>> Subject: Re: (DNS) draft wording for W.G. review. 
>> >- dns is a real performance pain
>> >- gethostbyname call doesn't give you ttl information back
>> >  So, if a ttl info is needed, you have to basicially integrate all 
>> >  resolver code, talking udp to DNS server. Also server selection,
>>timing out,
>> >  exponential back off and all that. Basically, it is a integration
>>of the 
>> whole
>> >  BIND into client/server.
>> Gethostbyname is not rocket science. Its a few UDP calls and a bit of
>> It should not be very hard. I wrote an interface in a couple of days. 
>> Not using the Berkley interface is an obvious thing to do to improve
>> if you do not have threads. It is a bit sad that Netscape hangs while
>>waiting to 
>> do a dns lookup.
>> I don't think we should restrict the spec on the basis of an
>>inadequate API to 
>> what is only a few lines of code. The complexity of BIND lies in the
>>server not 
>> in the client. Anwat's post pretty much describes what one has to do.
>> Note that there are some platforms where it is difficult to interface
>> to the bind daemon because someone has tried some half baked
>>optimisations. I 
>> remember when we used to ship libwww with two versions of code, one
>>for the 
>> people using the O/S version and the other (and by far the more widely
>> which used a direct interface to dns. I don't know whether that is
>>still an 
>> issue.
>> If people like I will post the code [just don't clutter the list with
>> or JG will be upset]. It may requires some tweaks since I use a garbage 
>> collector and a few layers of macros, I think its only about 100 lines
>>of code 
>> though].
>> 	Phill
>Donald E. Eastlake 3rd     +1 508-287-4877(tel)
>   318 Acton Street        +1 508-371-7148(fax)
>Carlisle, MA 01741 USA     +1 703-620-4200(main office, Reston, VA)

Received on Wednesday, 27 March 1996 12:05:03 UTC