Re: Caching of DNS records in tmdns

Ian Lister wrote:
> On Thu, 1 Apr 2004, Robin Perkins wrote:
> 
>>It seems that there are a few people putting out implementations - but
>>they all seem to have their problems in one way or another. Whilst
>>Apple do have an implementation that does provide a standard, it does
>>have licensing  issues with distro's such as Debian that are picky.
>>What I would like to see is one implementation (for say Free *nix),
>>released under the GPL or BSD license, that provides a standard API
>>for application developers - so we don't end up with an environment
>>where we have multiple applications running a wide range of 'custom'
>>zeroconf daemons, that are all incompatible (as in my understanding
>>only one daemon can bind to port 5353 at a time).
> 
> As long as they all use SO_REUSEPORT they should be able to all coexist
> bound to the same port.
> 
> Having a consistent API would certainly be nice.

Agreeed. But what I like about tmdns is the ability to use standard 
resolver and standard tools like "dig" or "nslookup" to search for 
information (PTR/SRV/A-records) in a autoconfiguration network since it 
answers requests to unicast port 53 (i.e. it works as a local DNS-server).

This doesn't work for Rendezvous on Linux since no resolver library 
supports Rendezvous on Linux (as far as I know) and Rendezvous does not 
listen to unicast port 53.

For announcing SRV-records I guess a new API (perhaps similar to 
mDNSResponder) is needed for tmdns.

Since tmdns lacks caching, more network traffic is generated to answer 
similar questions. Tmdns also lacks other things compared to Rendezvous, 
but for me those things are not as important as caching for now.

-- 
Roar


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click