[ On , June 2, 2003 at 16:52:32 (-0700), Ian Lance Taylor wrote: ]
> Subject: Re: Adding TTL information to gethostbyname() and friends
>
> 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.)

Well, I've heard there are other similar solutions in other domains
though no specific other example come to mind at the moment.

> > 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.

Perhaps I should re-phrase my claim:

As I understood things the reason for not changing or replacing the
gethostbyname() API to include TTL information at the time the DNS was
first introduced was specifically to prevent applications from trying to
cache it (for too long).

It has been a very long time since I asked this same question you've
effectively asked and I really forget where I may have learned this from.

> This amounts to an argument for doing nothing.

Well, no, not exactly "nothing".

It is an argument for NetBSD (and any other capable similar system) to
turn on 'named' by default and to have it configured by default as a
caching nameserver, with the libc stub resolver congigured by default to
point to the full resolver now running at 127.0.0.1.  (And if 'named' is
not the correct choice then something else can be.)

>  Yet the problem exists
> today--actually has existed for several years now--and should be fixed
> soon rather than, say, never.

You've proposed a non-standard hack for NetBSD which is not going to fix
the problem from the point of view of any realiastic multi-platform WWW
browser author, at least not any time in the future.

You've smoothed over the fact that this problem doesn't really affect
NetBSD in particular, and it especially would not if NetBSD were
delivered out-of-the-box with a full resolver running locally on every
host and with the stub resolver configured to point at the local host.

How do you propose to fix the problem for non-*BSD (and non-GLIBC)
platforms where the majority of browser authors still concentrate their
efforts and where what you proposed will not likely be implemented in
any timely fashion anyway?

You'd be far better off proposing that caching be implemented in all
stub resolvers and campaining for the removal of any longer-term DNS
caching in all applications.  At least then caching would be available
to even those without a full resolver within a reasonable RTT.  At least
then vendors (and system administrators) would have a choice as to
whether they run a separate full resolver on every client or whether
they implemented the stub cache.  At least then you wouldn't have to
fight for standardization of an API extension.  :-)

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>