Subject: Re: Adding TTL information to gethostbyname() and friends
To: NetBSD Networking Technical Discussion List <tech-net@NetBSD.ORG>
From: Ian Lance Taylor <ian@airs.com>
List: tech-net
Date: 06/02/2003 16:52:32
"Greg A. Woods" <woods@weird.com> writes:

> Note that some vendors have indeed tried to provide other forms of
> solutions for this problem, e.g. the SunOS' nscd.  They're not always
> exactly the "right" solution, and the example of 'nscd' is one that still
> avoids fixing the TTL problem to such an extent that it often causes
> even more problems of its own than it solves.  Even so 'nscd' is still
> conceptually better than every individual application instance trying to
> do the same thing (even if the applications were to manage to honour DNS
> TTLs properly).

Please name one other existing solution for this issue, given that
nscd is a total bodge (which I agree with).  (Other than running your
own local DNS cache, which at present means pushing a sysadmin task on
to every end-user.)

> As I understood things the reason for not including TTL information in
> gethostbyname() and friends in the first place was specifically to
> prevent applications from trying to cache it (for too long).

I believe it was actually because gethostbyname() originally simply
read the /etc/hosts file, for which TTL is unknown and fairly
meaningless.

> I think it really would be a very large step backwards to invent and
> implement a new API to pretend to work around this perceived problem,
> and then hope that application authors will universally use this new
> API, when much better solutions have effectively always been staring
> everyone right in the face.  It would be far less of a botch to
> implement a secret in-core cache in the libc resolver (i.e. to add
> caching to our stub resolver), but it may still be a waste of time and
> effort since it would really only solve the problem in a scenario where
> it usually doesn't exist, and/or where better solutions can be far more
> easily deployed.

This amounts to an argument for doing nothing.  Yet the problem exists
today--actually has existed for several years now--and should be fixed
soon rather than, say, never.

So, do you have any recommendations for fixing the existing problems?
Please include the recommendation for fixing the existing browsers.

Ian