CURL is stuck in invalid state after DNS resolution failure

[devgs]

I did this

There seems to be some broken state in CURL handle. To enter this state the request must fail in DNS resolution. Specifically in our case the DNS server goes down and doesn't respond for some time.

In older versions of cURL the subsequent attempt to reuse handle (keep-alive) in this broken state immediately (no delays) leads to an CURLE_BAD_FUNCTION_ARGUMENT error. The only option is to just drop this state, because the curl_easy_reset() doesn't have any effect.

In the most recent version (and several earlier versions that I checked, as well) behavior is a bit different. Request fails with timeout in DNS but then all subsequent requests to the same CURL handle, again hang for a duration of configured timeout value and then fail with CURLE_OPERATION_TIMEDOUT. As in older versions, curl_easy_reset() has no effect and the only option is to discard such CURL handle.

I've tracked down the issue to ares. It seems that after the original failure on timeout and call to ares_cancel() the ares channel itself stays in an invalid state. Seems that its internal socket is still open but isn't operable. On call to Curl_ares_getsock() we get its file descriptor and a request to poll it to become readable. But it never does and we basically always wait until the timeout is exhausted.

It seems that in this specific case, when DNS resolution is timed out, the ares channel must be closed, at least in curl_easy_reset(). Otherwise we may end up with a permanently broken state.

I expected the following

I expect CURL handle to not become broken.

curl/libcurl version

curl 8.5.0
curl 8.14.1
curl 8.15.0

operating system

FreeBSD 14.0
FreeBSD 14.2

[devgs]

More info.

When built with cURL's own thread-based resolver the issue doesn't reproduce. Maybe because it always uses the system API (getaddrinfo()) that doesn't have this broken state issue.

Also, the easiest way to reproduce is to modify your /etc/resolv.conf by setting a nonexistent server. Then issue a request and wait for it to fail (Resolving timed out after XXXX milliseconds). Set the valid server in /etc/resolv.conf and issue a request again, through the same CURL handle.

[icing]

@devgs thanks for the detailed report. I made #18217 to address this, always destroying the ares channel when async resolving is shut down.

[devgs]

@icing you're welcome. Thanks for such a fast fix.

[bagder]

@devgs did you confirm that it fixes your case?

[devgs]

@icing Yes, I confirm the fix. There is no longer a broken state and same CURL handle stays operable, even after DNS server issues. Thanks.