aarond10
HTTPS Client intermittently fails to connect to cloudflare-dns.com (libcurl v8.5.0)
I am having issues with the https client intermittently failing to connect (via curl) to cloudflare-dns.com after approx. 5 minutes of up time, resulting in a DNS reply outage from https_dns_proxy to my downstream DNS server.
After about another 5 minutes, the connection is then restored. This repeats in cycles.
I am using a Docker container using Alpine base image and v8.5.0 of libcurl.
Log output below.
Any ideas? Is v8.5.0 of libcurl not yet supported?
[I] 1705691664.509830 main.c:218 Version: 2023.12.27-8afbba7
[I] 1705691664.509843 main.c:219 Built: Jan 19 2024 19:13:15
[I] 1705691664.509873 main.c:220 System c-ares: 1.24.0
[I] 1705691664.557248 main.c:221 System libcurl: libcurl/8.5.0 OpenSSL/3.1.4 zlib/1.3 brotli/1.1.0 c-ares/1.24.0 libidn2/2.3.4 nghttp2/1.58.0
[W] 1705691664.678521 main.c:235 HTTP/3 is not supported by current libcurl
[I] 1705691664.687691 dns_server.c:57 Listening on 10.5.0.3:5053
[I] 1705691664.701509 main.c:308 DNS polling initialized for 'cloudflare-dns.com'
[W] 1705692511.570344 https_client.c:353 3C19: curl request failed with 0: No error
[W] 1705692511.570388 https_client.c:355 3C19: curl error message: Failed to connect to cloudflare-dns.com port 443 after 2 ms: Couldn't connect to server
[W] 1705692511.570405 https_client.c:382 3C19: No response (probably connection has been closed or timed out)
[W] 1705692511.570445 https_client.c:426 3C19: CURLINFO_OS_ERRNO: 99 Address not available
[I] 1705692511.570457 https_client.c:510 3C19: Response was faulty, skipping DNS reply.
"99 Address not available" presumably means it's trying to bind to an address for the hostname (via gethostname()) that the docker container can't use. The fact it happens after 5 minutes is weird and possibly related to something else you have going on (NAT or VPN configuration perhaps).
On Sat, 20 Jan 2024 at 07:07, Paul Harris @.***> wrote:
I am having issues with the https client intermittently failing to connect (via curl) to cloudflare-dns.com after approx. 5 minutes of up time, resulting in a DNS reply outage from https_dns_proxy to my downstream DNS server.
After about another 5 minutes, the connection is then restored. This repeats in cycles.
I am using a Docker container using Alpine base image and v8.5.0 of libcurl.
Log output below.
Any ideas? Is v8.5.0 of libcurl not yet supported?
[I] 1705691664.509830 main.c:218 Version: 2023.12.27-8afbba7 [I] 1705691664.509843 main.c:219 Built: Jan 19 2024 19:13:15 [I] 1705691664.509873 main.c:220 System c-ares: 1.24.0 [I] 1705691664.557248 main.c:221 System libcurl: libcurl/8.5.0 OpenSSL/3.1.4 zlib/1.3 brotli/1.1.0 c-ares/1.24.0 libidn2/2.3.4 nghttp2/1.58.0 [W] 1705691664.678521 main.c:235 HTTP/3 is not supported by current libcurl [I] 1705691664.687691 dns_server.c:57 Listening on 10.5.0.3:5053 [I] 1705691664.701509 main.c:308 DNS polling initialized for 'cloudflare-dns.com' [W] 1705692511.570344 https_client.c:353 3C19: curl request failed with 0: No error [W] 1705692511.570388 https_client.c:355 3C19: curl error message: Failed to connect to cloudflare-dns.com port 443 after 2 ms: Couldn't connect to server [W] 1705692511.570405 https_client.c:382 3C19: No response (probably connection has been closed or timed out) [W] 1705692511.570445 https_client.c:426 3C19: CURLINFO_OS_ERRNO: 99 Address not available [I] 1705692511.570457 https_client.c:510 3C19: Response was faulty, skipping DNS reply.
— Reply to this email directly, view it on GitHub https://github.com/aarond10/https_dns_proxy/issues/167, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABTOXVGFN7DHCEPHNVO7ELYPLG65AVCNFSM6AAAAABCCO6O7GVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA4TCMZQGM3TQMI . You are receiving this because you are subscribed to this thread.Message ID: @.***>
"99 Address not available" presumably means it's trying to bind to an address for the hostname (via gethostname()) that the docker container can't use. The fact it happens after 5 minutes is weird and possibly related to something else you have going on (NAT or VPN configuration perhaps). … On Sat, 20 Jan 2024 at 07:07, Paul Harris @.> wrote: I am having issues with the https client intermittently failing to connect (via curl) to cloudflare-dns.com after approx. 5 minutes of up time, resulting in a DNS reply outage from https_dns_proxy to my downstream DNS server. After about another 5 minutes, the connection is then restored. This repeats in cycles. I am using a Docker container using Alpine base image and v8.5.0 of libcurl. Log output below. Any ideas? Is v8.5.0 of libcurl not yet supported? [I] 1705691664.509830 main.c:218 Version: 2023.12.27-8afbba7 [I] 1705691664.509843 main.c:219 Built: Jan 19 2024 19:13:15 [I] 1705691664.509873 main.c:220 System c-ares: 1.24.0 [I] 1705691664.557248 main.c:221 System libcurl: libcurl/8.5.0 OpenSSL/3.1.4 zlib/1.3 brotli/1.1.0 c-ares/1.24.0 libidn2/2.3.4 nghttp2/1.58.0 [W] 1705691664.678521 main.c:235 HTTP/3 is not supported by current libcurl [I] 1705691664.687691 dns_server.c:57 Listening on 10.5.0.3:5053 [I] 1705691664.701509 main.c:308 DNS polling initialized for 'cloudflare-dns.com' [W] 1705692511.570344 https_client.c:353 3C19: curl request failed with 0: No error [W] 1705692511.570388 https_client.c:355 3C19: curl error message: Failed to connect to cloudflare-dns.com port 443 after 2 ms: Couldn't connect to server [W] 1705692511.570405 https_client.c:382 3C19: No response (probably connection has been closed or timed out) [W] 1705692511.570445 https_client.c:426 3C19: CURLINFO_OS_ERRNO: 99 Address not available [I] 1705692511.570457 https_client.c:510 3C19: Response was faulty, skipping DNS reply. — Reply to this email directly, view it on GitHub <#167>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABTOXVGFN7DHCEPHNVO7ELYPLG65AVCNFSM6AAAAABCCO6O7GVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA4TCMZQGM3TQMI . You are receiving this because you are subscribed to this thread.Message ID: @.>
I thought it could be do do with my Docker network set up as you mention, but to rule it out, I changed my docker base image to Debian (which has older libcurl v7.88.1) and it works and never drops connection. As soon as I switch back to Alpine and libcurl v8.5.0, the upstream server connection instability comes back. Very strange.
Could be something else running in your container that is killing the network after a few minutes perhaps?
On Fri, 26 Jan 2024, 10:29 am Paul Harris, @.***> wrote:
"99 Address not available" presumably means it's trying to bind to an address for the hostname (via gethostname()) that the docker container can't use. The fact it happens after 5 minutes is weird and possibly related to something else you have going on (NAT or VPN configuration perhaps). … <#m_1398698875816594125_> On Sat, 20 Jan 2024 at 07:07, Paul Harris @.> wrote: I am having issues with the https client intermittently failing to connect (via curl) to cloudflare-dns.com http://cloudflare-dns.com after approx. 5 minutes of up time, resulting in a DNS reply outage from https_dns_proxy to my downstream DNS server. After about another 5 minutes, the connection is then restored. This repeats in cycles. I am using a Docker container using Alpine base image and v8.5.0 of libcurl. Log output below. Any ideas? Is v8.5.0 of libcurl not yet supported? [I] 1705691664.509830 main.c:218 Version: 2023.12.27-8afbba7 [I] 1705691664.509843 main.c:219 Built: Jan 19 2024 19:13:15 [I] 1705691664.509873 main.c:220 System c-ares: 1.24.0 [I] 1705691664.557248 main.c:221 System libcurl: libcurl/8.5.0 OpenSSL/3.1.4 zlib/1.3 brotli/1.1.0 c-ares/1.24.0 libidn2/2.3.4 nghttp2/1.58.0 [W] 1705691664.678521 main.c:235 HTTP/3 is not supported by current libcurl [I] 1705691664.687691 dns_server.c:57 Listening on 10.5.0.3:5053 http://10.5.0.3:5053 [I] 1705691664.701509 main.c:308 DNS polling initialized for 'cloudflare-dns.com http://cloudflare-dns.com' [W] 1705692511.570344 https_client.c:353 3C19: curl request failed with 0: No error [W] 1705692511.570388 https_client.c:355 3C19: curl error message: Failed to connect to cloudflare-dns.com http://cloudflare-dns.com port 443 after 2 ms: Couldn't connect to server [W] 1705692511.570405 https_client.c:382 3C19: No response (probably connection has been closed or timed out) [W] 1705692511.570445 https_client.c:426 3C19: CURLINFO_OS_ERRNO: 99 Address not available [I] 1705692511.570457 https_client.c:510 3C19: Response was faulty, skipping DNS reply. — Reply to this email directly, view it on GitHub <#167 https://github.com/aarond10/https_dns_proxy/issues/167>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABTOXVGFN7DHCEPHNVO7ELYPLG65AVCNFSM6AAAAABCCO6O7GVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA4TCMZQGM3TQMI https://github.com/notifications/unsubscribe-auth/AABTOXVGFN7DHCEPHNVO7ELYPLG65AVCNFSM6AAAAABCCO6O7GVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA4TCMZQGM3TQMI . You are receiving this because you are subscribed to this thread.Message ID: @.>
I thought it could be do do with my Docker network set up as you mention, but to rule it out, I changed my docker base image to Debian (which has older libcurl v7.88.1) and it works and never drops connection. As soon as I switch back to Alpine and libcurl v8.5.0, the upstream server connection instability comes back. Very strange.
— Reply to this email directly, view it on GitHub https://github.com/aarond10/https_dns_proxy/issues/167#issuecomment-1911163292, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABTOXSDRJI6DL6HRULJY5TYQLTE3AVCNFSM6AAAAABCCO6O7GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJRGE3DGMRZGI . You are receiving this because you commented.Message ID: @.***>
I don't think so. The image just has the https_dns_proxy binaries and runtime dependencies installed and Alpine is even slimmer than Debian so far as I understand.
Has it been tested with libcurl v8.5.0? Having said that, I'd be surprised if it was that since I read the major version change from v7 to v8 wasn't actually a major update and didn't break the API, it was just to reset the minor version numbers which were getting a bit too high.
Did anything happen here? I'm running curl 8.8.0 just fine. Closing for now. Feel free to reopen if it's still an issue.