Would it be possible for someone to sneak in this bugfix in Query.pike at some stage?
--- lib/modules/Protocols.pmod/HTTP.pmod/Query.pike.old 2007-04-15 14:24:41.000000000 +0200 +++ lib/modules/Protocols.pmod/HTTP.pmod/Query.pike 2008-07-29 09:04:35.000000000 +0200 @@ -500,7 +500,9 @@
array hosts = (Protocols.DNS.client()->gethostbyname( hostname )|| ({ 0, 0 }))[1]; - return sizeof(hosts) && hosts[random(sizeof( hosts ))]; + return + hostname_cache[hostname] = + ( sizeof(hosts) && hosts[random(sizeof( hosts ))] ); }
to make the hostname_cache in Protocols.HTTP.Session work as intended.
Mirar @ Pike developers forum wrote:
Would it be possible for someone to sneak in this bugfix in Query.pike at some stage?
- return
hostname_cache[hostname] =( sizeof(hosts) && hosts[random(sizeof( hosts ))] );
to make the hostname_cache in Protocols.HTTP.Session work as intended.
I seem to notice two things:
- We're not using the DNS supplied TTL in the hostname_cache. I'd consider that to be undesirable behaviour of a DNS cache, it leads to all kinds of hard-to-trace bugs in accessing some sites with intentionally low TTLs (load balancing, failover, or dynamic IPs).
- We're not expiring hostname_cache entries anywhere, it seems.
How is this supposed to work?
It's probably a good idea to implement, yes. (But not for 7.8...?)
It works with supplying the query object with the mapping you are using for the session. From HTTP/Session.pike:
q->hostname_cache=hostname_cache;
Mirar @ Pike developers forum wrote:
It's probably a good idea to implement, yes. (But not for 7.8...?)
It works with supplying the query object with the mapping you are using for the session. From HTTP/Session.pike:
q->hostname_cache=hostname_cache;
For a session. Hrm. Well, let's put it this way, I've recently solved a similar problem in mailfromd which supports connections to spamd and clamd over TCP/IP, however the clamd sessions (at least) operate in such a way that *after* the initial connect session, they open up a secondary datachannel (a bit like FTP) over which they send the mail content.
The silly thing here is that if the clamd host is loadbalanced over DNS, this second connection has a high probability of being to the wrong server. So in that case I would like the session/DNS cache to supply me with the exact same IP it did in the previous query.
If that is what this is about, then your patch is fine; if it is not, I'd even advise against having an extra DNS-cache layer (at least as long as it doesn't take the TTL into account).
Browsers are supposed to cache dns<->ip util they are restarted.
http://christ1an.blogspot.com/2007/07/dns-pinning-explained.html
Per Hedbor () @ Pike (-) developers forum wrote:
Browsers are supposed to cache dns<->ip util they are restarted.
http://christ1an.blogspot.com/2007/07/dns-pinning-explained.html
Until the window gets closed, I seem to distill from it, interesting article.
That would mean that inside an ongoing session or as long as you have related sessions, it should reuse the IP-address.
Yes. Most browsers (at least firefox and opera) simply cache the dns until all URL:s referring to the hostname has been unloaded. That is, until they are no longer in ramcache.
pike-devel@lists.lysator.liu.se
-
Mirar ＠ Pike developers forum -
Per Hedbor () ＠ Pike (-) developers forum
-
Stephen R. van den Berg