Re: mod_proxy and DNS resolving

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





2016-05-28 12:25 GMT+02:00 Luca Toscano <toscano.luca@xxxxxxxxx>:
Hi Yann,

2016-05-28 0:31 GMT+02:00 Yann Ylavic <ylavic.dev@xxxxxxxxx>:
Hi Luca,

On Mon, May 23, 2016 at 2:21 PM, Luca Toscano <toscano.luca@xxxxxxxxx> wrote:
>
> I replied to the comment that you pointed out with Jim's answer and I
> updated the trunk documentation with a note about DNS resolution:
>
> http://httpd.apache.org/docs/trunk/mod/mod_proxy.html#workers
>
> HTML diff only:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_proxy.html.en?r1=1745170&r2=1745169&pathrev=1745170

I don't think this is correct.
When disablereuse is true (including the default workers), the DNS
resolution occurs for each connection.
But when mod_proxy is reusing connections (including addresses), each
worker/backend address is resolved only once per child process, and
reused for all further connections (until the child is recycled).
AIUI, this is not related to the TTL.


Thanks a lot for the explanation and for the info. So httpd does cache origin DNS resolution and there is no way to control it via mod-proxy settings (maybe the only thing that could be used is MaxConnectionsPerChild?).
 

>From ap_proxy_determine_connection():
                /*
                 * Worker can have the single constant backend adress.
                 * The single DNS lookup is used once per worker.
                 * If dynamic change is needed then set the addr to NULL
                 * inside dynamic config to force the lookup.
                 */
AFAICT, nothing sets "addr to NULL" anywhere in httpd, that would be
racy anyway.

There is indeed a worker 'is_address_reusable' flag distinct from
'disablereuse', but it is not exposed to the admin and seems to be
internally mapped to 'disablereuse'.

I have a patch which introduces 'addressTTL' if one is interested, but
it's not that simple because it addresses the race locklessly (and
leaklessly :), thus with refcounting, address pool...


If I got everything correctly, the description of the TTL might be a bit misleading because it is not clear IMHO that the DNS resolution won't be performed:

"Time to live for inactive connections and associated connection pool entries, in seconds. Once reaching this limit, a connection will not be used again; it will be closed at some later time."

What would happen when an admin performs a change of the origin DNS A or AAAA record? If httpd doesn't happen to recycle workers at that time it will try to connect to the old IP address probably triggering a 502 due to timeouts or connection failures right? 

The perfect thing, IMHO, would be to force the DNS resolution every time a new connection to origin needs to be performed (transparently to all the options), but as you mentioned the implementation could be messy and I am not sure how many people would like this feature. 

Anyhow, I'll wait for some replies to check that I got everything correctly and then I'll updated the documentation (unless somebody wants to do it before me). 


FYI for the interested readers: I fixed trunk's documentation following Yann's advice with http://svn.apache.org/r1748948
Will do more tests and then in case I'll backport it to the 2.4 doc. The HTML now says:

"DNS resolution happens when the socket to the origin domain is created for the first time. When connection pooling is used, each backend domain is resolved only once per child process, and reused for all further connections until the child is recycled. This information should to be considered while planning DNS maintenance tasks involving backend domains."

Any feedback will be really welcome!

Luca 


[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux