Re: Resolv class caching /etc/hosts entries

Hi Timur,

If you're working with DNS you're going to run into all sorts of caching 
fun in general, so it's a good idea to be prepared for it. Applications 
(eg. browsers), operating systems, ISPs, and nameservers all do their 
own caching of DNS results. Did you know, for example, that the data 
could be over a week out-of-date because you are using an ISP that 
disregards TTLs, and your browser has been caching previous results to 
remain responsive?

The general rationale is that it is expensive to always have the latest 
information available- in terms of amount of data, or just the time 
taken to parse /etc/hosts, or just the initial wait in making the 
request. Resolver libraries are usually called very frequently with 
exactly the same data. To keep libraries responsive, usually the first 
request of a sort is made, and the resolver waits for a response. The 
next similar requests use cached results, rather than waiting for a 
response each time.

I can't speak for the Resolv class myself- I've never used it- but the 
rationale is probably similar. If you've got a hard requirement such as 
checking /etc/hosts for changes, you might want to consider a wrapper or 
proxy class that watches /etc/hosts for changes in its timestamp, and 
then does whatever you need- restarting OS-level resolvers, perhaps 
dropping and recreating the Resolv object, or somehow forcing it to drop 
its cache. Exactly what needs to be done will depend on the problem you 
are trying to solve.

Hope this helps. :)

Cheers,
Garth

On 07/03/13 09:11, Timur Alperovich wrote:
> Hey guys,
>
> I ran into a subtle bug recently where I did not realize that the
> Resolv class actually caches the contents of the /etc/hosts file. This
> is problematic, as if the resolution is done in a long-running
> process, any changes are not visible to the process unless the class
> is reloaded or the process is restarted. I was wondering if anyone
> knows what the rationale is for caching the contents and why there are
> no checks to see if the file has been modified? For now, I've worked
> around this by calling Socket::getaddrinfo, as getaddrinfo does the
> right thing.
>