`ssl_shutdown_timeout=0` default in 3.12.11+ causes intermittent "ssl:default cannot contact to DNS server" errors in high-concurrency environments

[arthurhuangzh]

Describe the bug

Environment

• aiohttp version: 3.12.11+ (specifically tested with 3.12.13)
• Python version: 3.9
• Platform: AWS Lambda (Python runtime)
• Related dependencies: aiodns (latest), pycares (latest), aiosignal (latest)

Problem Description

Intermittent connection failures occurring after Lambda functions run for extended periods under high load, presenting with the misleading error message:

ClientConnectorError: Cannot connect to host api.xxxxx.com:443 ssl:default cannot contact to DNS server

Root Cause Analysis

The change in aiohttp 3.12.11+ where ssl_shutdown_timeout default value changed from 0.1 to 0 causes aggressive connection closure without proper SSL shutdown handshake.
Technical Mechanism

1. Connection Creation: Lambda instance establishes HTTPS connections normally
2. Aggressive Closure: ssl_shutdown_timeout=0 causes immediate TCP RST instead of graceful SSL shutdown
3. State Inconsistency: DNS cache retains valid entries while connection pool references become stale
4. Subsequent Failures: New Lambda instances attempt to use cached DNS data with inconsistent connection states
5. SSL Handshake Failure: Server-side detects previous connection anomalies during new SSL handshake
6. Error Misreporting: SSL handshake failures get incorrectly reported as DNS contact failures

This Represents a Significant Breaking Change

We believe the ssl_shutdown_timeout default value change from 0.1 to 0 in version 3.12.11+ constitutes a significant breaking change that warrants more prominent documentation and community awareness.

To Reproduce

TBD

Expected behavior

The application should continue to function as expected after upgrading aiohttp, aiodns, aiosignal, and pycares to their latest versions.

Logs/tracebacks

ClientConnectorError: Cannot connect to host api.xxxxx.com:443 ssl:default cannot contact to DNS server

Python Version

$ python 3.9

aiohttp Version

aiohttp version: 3.12.11+ (specifically tested with 3.12.13)

multidict Version

$ python -m pip show multidict

propcache Version

$ python -m pip show propcache

yarl Version

$ python -m pip show yarl

OS

AWS Lambda (Python runtime)

Related component

Client

Additional context

While we understand that the ssl_shutdown_timeout change may have been intended as an optimization, its impact in production environments qualifies it as a breaking change that deserves prominent documentation. This would help the community avoid the costly debugging and production issues we experienced.

Code of Conduct

• I agree to follow the aio-libs Code of Conduct

[bdraco]

I think what this issue is saying in In AWS Lambda's constrained environment, abrupt connection closures (TCP RST) can exhaust file descriptors or network resources faster, and take longer to cleanup. In that case, the DNS resolver can report "cannot contact to DNS server" because it can't establish a connection to the DNS server - not because of DNS issues, but because of system resource limits.

This suggests the Lambda is likely doing something like:

  # Bad pattern - creates resource exhaustion
  async def handle_request():
      async with aiohttp.ClientSession() as session:  # New session per request
          async with session.get(url) as response:
              return await response.text()
      # Session closed here - all connections aborted with TCP RST

Instead of:

  # Good pattern - reuses session
  session = aiohttp.ClientSession()

  async def handle_request():
      async with session.get(url) as response:
          return await response.text()

Is there a reason you can't reuse sessions? This should avoid the problem entirely.

[arthurhuangzh]

Hi @bdraco, thank you for your prompt response. I agree that this is an edge case related to OS network conditions, which will not be an issue with version 3.11. While I don't consider this a bug and recognize there are several ways to avoid the issue, I believe it is worth mentioning in the changelog. The aggressive change in connection handling, specifically modifying the ssl_shutdown_timeout default value from 0.1 to 0, could potentially cause applications to crash post-upgrade of the aiohttp library. We encountered this issue in our application running on AWS Lambda.

[Dreamsorcerer]

will not be an issue with version 3.11
The aggressive change in connection handling, specifically modifying the ssl_shutdown_timeout default value from 0.1 to 0

This functionality didn't exist in 3.11. It was added in 3.12.5 and dropped to 0 in 3.12.11 (while also deprecating the parameter again) after causing too many issues for other users. I certainly wouldn't consider this an "aggressive change".

[Dreamsorcerer]

What does the actual code you are using look like though? We need that to understand the problem, as per bdraco's comment.

[arthurhuangzh]

Hi @Dreamsorcerer, I've been using aiohttp as an HTTP client to send requests, like the example below. It worked fine for us until we upgraded to version 3.12.x from 3.11.x. After the upgrade, we started encountering the error ClientConnectorError: Cannot connect to host api.xxxxx.com:443 ssl:default cannot contact DNS server. Upon investigating the issue, we discovered that the new version of aiohttp attempts to reuse a TCP socket that has an incorrect status between the target and source servers(could be caused by the default value change from 0.1 to 0 of ssl_shutdown_timeout). It appears that several other dependency libraries(aiodns, pycares, aiosignal) are also causing this issue. We tried reverting the version of the aiohttp library, but the problem persisted until we reverted the versions of all dependencies.

def new_session():
    # 1 minute
    default_timeout = ClientTimeout(total=60)
    return ClientSession(raise_for_status=False, trace_configs=[trace_config], timeout=default_timeout)

[Dreamsorcerer]

version 3.12.x from 3.11.x
could be caused by the default value change from 0.1 to 0 of ssl_shutdown_timeout

Again, the change only happened in 3.12.11 for functionality that was introduced in 3.12.5. If you have the problem in 3.12.4, then it is completely unrelated to that functionality. If you have the problem in 3.12.10, then it is not related to the value of the parameter. You could also just change the value to 0.1 on the latest release and see if that has any impact.

The code you provided is just a function that returns a session. We want to see the code for how that session is used in the overall code.

If you don't do further testing or provide more useful code, you're making it extremely difficult to help you...