On Sun, 1 Jun 2003, Andrew Brown wrote:

> >One of the long standing drawbacks to the BSD sockets API is that
> >there is no reasonable way to get the TTL of a DNS entry.
>
> i don't see that this is a failing of the sockets api, per se...though
> perhaps it is of the name service functions.

It's the API. I was working with Ian at Zembu, and felt the pain of this
issue very acutely. :-)

> then again, the name service functions aren't really designed for
> people who want caching.  imho, people who want caching should do dns

No, they weren't. A big part of the problem is that before browsers (and
possibly other than browsers), most programs made relatively few name
lookups. Like telnet or ssh only make one lookup per invocation (unless
you're doing something really weird I don't know about :-).

Browsers, however, issue LOTS of name lookups. Also, they are very likely
making lookups of the same name. Thus an in-program cache will help a lot.

> themselves, probably using routines no more complex than res_mkquery()
> and dn_expand().  those people that want a simple interface should use
> it as that, and trust some other component (local name server, nscd,
> lwresd, or whatever) to do the caching.

res_mkquery() & friends aren't right, as we then ignore /etc/hosts & NIS &
whatever else. Plus whatever nsswitch preferences the admin has chosen.

I don't think local name servers are a good solution. While I doubt they
are a big deal for folks on this list, the fact they aren't widely
deployed and/or are ignored indicates they leave people wanting more.

No one's suggesting that we require programs to start caching name
requests, we're suggesting a way to help the programs that are doing
caching now.

Note that Ian's diff also includes a hook for name lookups that don't have
a TTL - __H_TTL_UNKNOWN. That's for /etc/hosts and NIS. Also, I think it'd
be reasonable to later on add a hook so that an admin could force the TTL
to zero. If you had a local name server, it'd be the setting to use.

Take care,

Bill