On Thu, 2011-05-12 at 12:42 +0200, Matthias Förste wrote:[...]

Thank you for the patch. For the moment I am quite sceptical about it,
as DNS lookups are expensive operations (the reason the results are
cached). We'll look at it again if there is massive demand for it.

As an aside, just for my curiosity: what is the usage pattern that would
require such a scenario?[...]

Speaking as a user of Pound within Amazon's EC2, we find the current 
behavior to be painful since IP addresses for our backend servers are 
dynamic. Currently we have to restart Pound any time a backend server is 
restarted. I'm hopeful that you'll consider this patch or an alternate 
method to achieve the same result.

Thanks,

Rob

On 06/24/2011 11:06 AM, Robert Segall wrote:[...][...][...]

Hello,

Robert Segall <roseg(at)apsis.ch> (Fri Jun 24 18:06:50 2011):[...]
…[...]
…[...]

For this reason an extra option was invented. Thus the extra DNS lookups
are only done if the backend is marked as "dynamic". For (at least our)
usage pattern performance is not important, but flexibility.
[...]

(Speaking as part of the same company as the OP and as initiator of the
patch in question.)

1) From my Android phone I'm connecting to the our calendar server. This
   server runs at a cheap dialin DSL connection, changing it's IP once a
   day. (But updating it some dyndns service.)

   The used software on the android is stupid enough to resolve the IP
   address of the calender server at configuration time.

   Now we're using the patched pound on a central server (having a fixed
   IP) to forward the requests to the moving target.

2) At the some server behind a cheap dialin DSL connection some https
   based service is running, but unfortunately the IP address changes
   once a day.

   Some software is stupid enough not to allow an import of our own CA
   certificate.

   Now a patched version of pound is used to service as man in the
   middle on a central server, using an "officially singed" certificate.
   Based on the URL requested it forwards/proxies the requests via
   https to the above mentioned service.

*) I've split it into two use cases, but actually both cases are
   combined.
[...]