On 07/03/13 18:15, Timur Alperovich wrote:
Thanks for taking the time to reply!
Not a problem.
amount of time. However, eventually, they should be propagated – the
behavior you’re describing sounds like a bug.
The browser behaviour is an oddity- it’s what you actually want most of
the time, especially if the operating system lookup is sluggish (might
be true on Windows? I’m not sure), but if you’re doing something
involving messing about with hosts, it’s positively painful to work
For the ISP case, it’s more poor behaviour on the part of an ISP rather
than a bug. :} None should ignore TTL, because used properly it is
incredibly useful, especially when migrating hosts. But some do. It
drove me crazy when I had to deal with it- lazy behaviour on the part of
ISPs of which you aren’t even a customer can have nasty effects if your
clients are using that ISP.
does not cache getaddrinfo responses.
You are correct, however, to point out that one can work around it by
reloading the class on every query, but that seems like overkill?
Oh yes, it’s definitely overkill. I was just saying how I’d work around
it if I was faced with a similar problem and needed a solution in the
face of such a shortcoming.
I’d definitely agree that if there is no way to clear the cache short of
dropping the whole object, then there is an issue/shortcoming/bug.
Another thing to bear in mind is that the fault might not be in Resolv
(it might be, I’m not familiar with it). On Linux, for example,
gethostbyname (apparently) goes through nscd, which is providing its own
caching. I know there have been times in the past when I’ve disabled
that, where the caching has caused more problems than it solved. In this
case, even being able to drop the Resolv cache wouldn’t be enough,
because it is layered on something else that is providing caching. Now
this is all thoeretical, but I’m just bringing up something that might
be happening. Is the fault actually with Resolv? If not, you’re going to
find where the problem occurs, and find a way around that issue. If yes,
it does seem like the lack of ability to drop the cache is either a
shortcoming or bug. But in either case, what to do? Suppose no immediate
fix is available, or you need something that works generally. You might
need to add some logic to your app to handle the additional hard
requirement you have (immediate update if /etc/hosts changes), to ensure
that no matter the details of the underlying implementation, your app
behaves as it should. The audience for Resolv might be more geared
toward simpler use cases employed by browsers and net apps, where
ongoing indefinite caching is sufficient.
Having said that- I definitely don’t want to derail any intended
discussion on any shortcomings of the Resolv class. Please don’t take it
that way. I’m just running through some possible concerns and
solutions. I’m not suggesting that Resolv is completely fine and
shouldn’t be changed. From what you’ve described, it sounds like there
is an issue there in there that needs to be addressed- being able to
drop the cache at a minimum, and detecting source changes (eg.
/etc/hosts) at best.