[ On , June 4, 2003 at 14:17:44 (-0700), Ian Lance Taylor wrote: ]
> Subject: Re: Adding TTL information to gethostbyname() and friends
>
> I'm willing to believe that you believe that except for that part
> about ``your proposal effectively forces additional work onto every
> application author.''  It certainly does not.  Any application author
> is free to rely on the efficient local DNS caching which you will
> arrange to provide.

Monkey see, monkey do.  Believe it or not but your proposal really will
force more application authors to at least consider implementing DNS
caching (and I'm betting even when caching could not benefit them!).

> > Please keep in mind that the particular scenarios where any application
> > level DNS caching can have any benefit whatsoever are rapidly
> > disappearing.  It is quite forseable that in the not too distant future
> > everyone with enough bandwidth to effectively use any application doing
> > DNS caching now will also have a low-latency connection; while those
> > with limited bandwidth will be using variant services (e.g. WAP) where
> > DNS caching in the client application will also be unnecessary (and
> > often unthinkable).
> 
> Someday, perhaps.  As the author of UUCP, I still get my fair share of
> e-mail from people around the world coping with slow connections.

Please do not try so hard to confuse the issues here.  I tried to be
very explicit about where DNS caching is perceived to be needed and
where it is not, but perhaps I need to try again.

First of all "speed" != "latency", and specifically "bandwidth" !=
"latency" either.  You probably know this, but it seems to need
repeating all the same.

UUCP is exactly one of those applications that can usually use
high-latency links without needing to cache DNS results.  It can do so
because usually the transaction sizes will not be so small that users
will perceive a problem because of long-latency DNS lookups, and more
importantly because it's not an application with a direct real-time user
interface.  I.e. UUCP is not very much like a WWW browser.

You have claimed as the basis for your proposal that application
authors, and in particular WWW browser authors have perceived a need for
DNS caching because the lack of proper existing caching has made their
users complain that their products are too slow.  This can only happen
in one scenario and one scenario only, which is that where the
application needs to make several hostname lookups in order to complete
what the user percieves as one unit of execution _AND_ where it is
likely that the it will be the same hostname (few) hostname(s) that are
used during that unit of execution _AND_ where the latency of those
hostname lookups is much longer than it should be.

I've tried to show that part of the problem is with the poor design of
the applications -- i.e. that they fail to use the same hostname lookup
results across a single unit of execution even though it would be
perfectly normal and proper for them to do so.  Perhaps this is because
they are just too finely object-oriented with poor factoring of their
components, or perhaps it is simply because their designers were already
aware of the concept of DNS caching and thus they decided to try to
implement their own caching to make up for the lack of proper caching in
the underlying DNS implementation they're making use of.

I've tried to show that the types of applications which fit this
description are already unlikely to be viable to use in scenarios where
DNS caching will benefit them, and only less likely to be usable as
progress marches on around us.  Web pages get more complex and the
images on them get bigger despite our best efforts.  People with high
latency links are going to find the WWW increasingly unusable with any
fully graphical browser and they will either get a lower-latency
connection (we already see dial-up PPP connections rapidly vanishing in
much of North America) or those who cannot do that will resort to using
protocols more suited to what connectivity they have, such as WAP.

I'm trying to show that your proposal attempts to make it easier for
only one very narrow range of applications in one single scenario, and
it does so by allowing applications to violate the protocol layering
that was intended for the DNS.  It should be obvious that attempting to
solve a problem that, by design, should not exist in the first place,
and in such a way that only works for a very narrow range of
applications in one single scenario, is not productive and is not likely
to succeed.

> I assume then that you feel that functions like res_query(),
> res_search(), and getrrsetbyname() should be removed from libc.  After
> all, they might reveal information to the application which should be
> kept secret.

Actually, yes, that is exactly how I feel.  Those functions are only
needed by a very narrow range of applications and they should be
relegated to separate libraries (e.g. libbind).

Another directly related problem is that libc is far less often updated
than these functions tend-to/should be updated.  As someone who has done
quite a bit of coding and maintenance of portable DNS related tools over
the years I'm very often stimied by broken libc implementtions of these
and related low-level functions, sometimes so broken that it's next to
impossible to replace them without ending up replacing parts of libc too.

However I do wish there were standard functions in libc that made it
easier for applications to retrieve things other than just hostnames and
PTRs from the DNS (e.g. data from RRs such as MX, TXT, etc.).

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