Subject: Re: Adding TTL information to gethostbyname() and friends
To: NetBSD Networking Technical Discussion List <tech-net@NetBSD.ORG>
From: Greg A. Woods <woods@weird.com>
List: tech-net
Date: 06/04/2003 17:03:09
[ On , June 3, 2003 at 12:57:14 (-0700), Ian Lance Taylor wrote: ]
> Subject: Re: Adding TTL information to gethostbyname() and friends
>
> Mozilla used to always use a 30 minute TTL, then changed to 15
> minutes, and now always uses 5 minutes.  Use the source.
> 
> When I tested IE a couple of years ago on Windows 98, it used a 15
> minute TTL.  I don't know whether this has changed.

Thank you.

From this we can conclude that Mozilla can do no real harm any more
(since it doesn't keep information any longer than the de facto minimum
TTL anyway) and IE won't do enough harm for any ordinary user to ever
notice (since 99.9% of users won't be savvy enough to figure out what's
wrong, and certainly not within the 15-min time limit at which time
things will return to normal for them anyway).

Neither implementation is ideal of course, but just the same neither
requires dirty level-crossing hacks to make it any "better".  The best
solution is still simply to try harder to force/coerce/cajole/entice
applications authors to not implement DNS caching at all.

> Because I am interested in fixing an actual problem.  I'm not
> interested in promoting some fantasy.

The problem is that your proposed hack is making the actual problem
worse, not better.  Your proposal condones their bad behaviour.  Your
proposal effectively forces additional work onto every application
author.  You are ignoring fundamental design goals and limitations.
Your proposal requires that protocol levels be violated.

Perhaps you should try proposing these hacks to the ISC folks first and
see how well they like them.  Perhaps you should even try to go the IETF
route.  If the Internet's key DNS engineers all agree that the situation
is so bad that it has come down to allowing applications to do their own
DNS caching then new standard APIs will be defined and pushed out to
implementors.

Alternatively perhaps you might consider changing your tactics to take
the far easier route of simply campaigning OS vendors (such as NetBSD)
to provide fully RFC 1123 compliant DNS caching by default out-of-the-box.

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


> I understand your point about how it would be better if every system
> ran a correct DNS cache.  I know that.  But even so, that does not
> explain why it is better to hide the TTL.

It should be obvious.  From an application's point of view the DNS is
supposed to be a black box -- i.e. the TTL information that is used by
the DNS to implement cache consistency is private internal information
not to be made available to applications for any purpose.  Hiding the
TTL is supposed to help force application authors into relying on the
caching inherent in the underlying DNS implementation.  Don't give them
information they don't need.  Don't give them information that's
internal to the implementation.  Don't ask them to re-implement features
that are already _required_ to be implemented internally in the DNS.

If the DNS is not being correctly implemented and deployed as required
by RFC 1123 then let us try much harder to fix that problem, not just
hack around it.

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