"Greg A. Woods" <woods@weird.com> writes:

> > I have no quarrel with this.  But it does not actually fix the
> > problem, because it doesn't change the browsers.
> 
> I think you've made the "fatal" assumption that changing the browsers is
> both possible and "likely", as well as being necessary.  I'm saying
> neither assumption is now, or ever will be, true.

Wrong.  The browsers right now cache DNS entries for the wrong amount
of time.  The browsers right now do the wrong thing.  Any plan for
fixing this problem must include a plan for changing the browsers.

> If indeed you care less about non-free environments then I would guess
> that youcan see that attempts to make non-standard changes to an API
> used across free and non-free environmetns are even more futile since
> doing so can only complicate things for both OS vendors as well as
> application authors and maintainers.  Only strong standards will likely
> be implemented in non-free environments, but I'm sure you know already
> that standards which try to invent new APIs from whole cloth, or even
> just API extensions, are often prone to failure.

I know nothing of the sort.  I see many APIs which come from free
software implementations adopted into proprietary implementations.

> > Besides the problems noted above (how can the browser know there is a
> > local cache?
> 
> The browser is not supposed to know if there is a local cache being used
> or not.  If local caching is not available then performance suffers, but
> the browser just browses and doesn't care either way how long it takes
> to do what it does.  If the user complains about performance loading
> pages with too many URLs then the user is told to try using a more local
> and proper DNS cache.  All of us "experts" always knew that recursive
> DNS caching was critical to the successful deployment and use of the
> DNS, but now excessively poor HTML design is showing this need to
> ordinary users as well, just not in such concrete and obvious ways as we
> might have hoped for.

Wrong.  If the browser is too slow, the user blames the browser.  The
browser writers may be willing to use a local cache, but they will
require some way to tell that there is a local cache.

> >  how can the browser distinguish DNS information from NIS
> > information?),
> 
> The browser is not supposed to know the difference between DNS names and
> NIS (or whatever) names.  The whole idea of integrating NIS (and even
> /etc/hosts) into gethostbyname() is to make local naming conventions
> vs. Internet naming transparent to the users.  The browser makes use of
> this transparency through a common API and just asks for the name to
> address translation without knowing where the name comes from.

Wrong.  The browser will want to either cache NIS information, or will
want to know that there is a working nscd implementation to cache it
locally.  So the browser either needs to know that NIS information is
cached locally, or it needs to distinguish it from DNS information in
order to cache it itself.

> > if every stub resolver is a cache, then we need a new global
> > mechanism for updating this list on a running system.
> 
> No, not really -- this information is extremely static already, and is
> trivially updated at runtime after just one query to even just one well
> known address.  The whole list doesn't always have to be correct any
> more than it is necessary for all root servers to be equally reachable
> from all clients world-wide at all times.

Fair enough; a good stub resolver needs to periodically update the
entries and write them into permanent storage.

> > Right now the administrator is responsible for tracking the relevant
> > list;
> 
> I can't remember the last time a root server address was ever changed or
> removed, and for certain they change or disappear far less often than
> even ordinary people manage to upgrade their OS software and I don't
> think the whole list has ever been turned over.  I.e. for all practical
> purposes the OS vendor is the one reponsible for tracking the current
> list of global root servers.

The last change was November 5, 2002.  I haven't updated the OS on my
server since May, 2000, and I haven't updated the resolver since
January 2001.

Ian