Re: [users@httpd] mod_proxy and DNS resolving

[Luca Toscano <to...@gmail.com>]

2016-05-28 12:25 GMT+02:00 Luca Toscano <to...@gmail.com>:

> Hi Yann,
>
> 2016-05-28 0:31 GMT+02:00 Yann Ylavic <yl...@gmail.com>:
>
>> Hi Luca,
>>
>> On Mon, May 23, 2016 at 2:21 PM, Luca Toscano <to...@gmail.com>
>> 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