CloudFront intermittent ERR_CONNECTION_RESET on IPv6 — empty ech_config_list in HTTPS DNS record causes TLS handshake RST on specific POP servers

I've been debugging an intermittent ERR_CONNECTION_RESET (net_error: -101) on two CloudFront distributions serving assets from S3 via OAC. After capturing Chrome net-internals logs I've isolated the root cause to an empty ech_config_list in CloudFront's HTTPS DNS record causing TLS handshake failures on specific IPv6 POP servers.

Environment:

• Two CloudFront distributions, default *.cloudfront.net domains (no custom cert)
• S3 origin with OAC
• CloudFront Function on viewer request (simple token check)
• httpVersion: HTTP2, minimumProtocolVersion: TLS_V1_2_2021, enableIpv6: true (now disabled as workaround)
• PRICE_CLASS_100, US/EU geo allowlist
• Client: Chrome 148 on Windows, Cox ISP using doh.cox.net for DoH

Symptoms

• Intermittent ERR_CONNECTION_RESET with no response headers and no entry in CloudFront access logs
• No Connection ID assigned in Chrome DevTools (confirming fresh connection attempt, not stale socket reuse)
• Affects both distributions identically
• Hard refresh does not reliably reproduce or prevent it
• Other users on different networks experience the same issue

Root Cause (identified via Chrome net-internals) Chrome's DNS resolution of the distribution domain returns an HTTPS resource record containing ECH metadata with an empty ech_config_list:

ech_config_list: ''        ← ECH advertised but config is empty
supported_protocol_alpns: ['h2', 'http/1.1']
target_name: 'd2z9j0pvxp0r55.cloudfront.net'

Chrome interprets the presence of ECH metadata in the HTTPS record as ECH being supported and sends a ClientHello with ECH enabled. Specific CloudFront IPv6 POP servers then RST the connection instead of falling back gracefully:

SSL_CONNECT_JOB_SSL_CONNECT: {ech_config_list: '', ech_enabled: true}
→ SSL_CONNECT_JOB_CONNECT: {net_error: -101}
Target: [2600:9000:2105:f600:4:d0e5:9a40:21]:443

The failure is not consistent across all IPv6 POP servers. CloudFront access logs confirm the same client IPv6 address (2600:8800:600f:9900:ede7:786d:6568:d302) successfully completing requests on other IPv6 connections to the same distribution minutes apart — hitting PHX50-P2 over TLSv1.3 with no issue. The RST only occurs on specific POP server threads, making the failure intermittent and hard to reproduce deterministically.

Question: Has anyone else seen this? Is the empty ech_config_list in the HTTPS DNS record for default *.cloudfront.net domains expected behavior, or is this something I'm doing wrong?

I have spent hours/days trying to figure out what's going on - especially given it started happening out of the blue and I can't find anybody else with a similiar issue online.

Any help is much appreciated!