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

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

I have no quarrel with this.  But it does not actually fix the
problem, because it doesn't change the browsers.

You need an additional part: a way that the browser can determine,
ideally at configure time but also at run time, that there is a
working local cache, and that therefore it need not cache DNS
information.

Unfortunately, even that is not a complete solution, because the
browser will still want to cache NIS information.  So you also need a
way for the browser to determine whether a host name to IP address
lookup was provided by DNS or by NIS.

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

Not so.  If my patch, or something like it, is accepted, my next step
is to patch Mozilla to detect whether the TTL information exists
(easily done in configure) and to use it when available.  I will then
look at other free software browsers.

Then I can use that as leverage to encourage other operating systems
to adopt the same or similar patch.

As a practical matter, I have to start somewhere.

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

As noted above, this problem does affect NetBSD, whether or not it
ships with a configured caching resolver, because the browsers will
cache the information anyhow.

But you're right that there is nothing special about NetBSD here.
I've just been doing a bit of NetBSD related hacking recently.

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

It's true that I have no input into any environment which is not free
software based.  However, my hope is that once the open source
browsers are patched, there will be some pressure on other
environments to adopt similar changes.  In case I have to admit that I
personally care less about such environments.

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

Frankly, this approach strikes me as being both more difficult to
implement and less likely to succeed.

Besides the problems noted above (how can the browser know there is a
local cache?  how can the browser distinguish DNS information from NIS
information?), any stub resolver must start with a known list of the
IP address of global name servers, and that list sometimes changes.
Right now the administrator is responsible for tracking the relevant
list; if every stub resolver is a cache, then we need a new global
mechanism for updating this list on a running system.

Ian