Scribbling feverishly on January 10, Dave Anselmi managed to emit:
> Kurt Wall wrote:
>
> [...]
>
> > glibc -- particularly, the resolver library and the NSS (Name Service
> > Switch) facilities. Specifically, the file resolv/resolv.h defines
> > the macro _PATH_RESCONF:
> >
> > #define _PATH_RESCONF "/etc/resolv.conf"
>
> Here's a question that came up in our study group. Do name lookups (name to
> IP mappings) get cached on a client machine (one without a nameserver)? Arp
> lookups (MAC to IP mappings) do, but what about DNS?
I suppose this is an implementation detail, but RFC1035 suggests that
resolver libraries should cache all data:
"
7.4. Using the cache
In general, we expect a resolver to cache all data which it receives
in
responses since it may be useful in answering future client requests.
However, there are several types of data which should not be cached:
- When several RRs of the same type are available for a
particular owner name, the resolver should either cache them
all or none at all. When a response is truncated, and a
resolver doesn't know whether it has a complete
set, it should not cache a possibly partial set of RRs.
- Cached data should never be used in preference to
authoritative data, so if caching would cause this to happen
the data should not be cached.
- The results of an inverse query should not be cached.
...
In a similar vein, when a resolver has a set of RRs for some name in a
response, and wants to cache the RRs, it should check its cache for
already existing RRs. Depending on the circumstances, either the data
in the response or the cache is preferred, but the two should never be
combined. If the data in the response is from authoritative data in the
answer section, it is always preferred."
Kurt
--
You will gain money by an immoral action.
_______________________________________________
Linux-users mailing list
Archives, Digests, etc at http://linux.nf/mailman/listinfo/linux-users
