Realtime API: DNS resolution timeout before TLS handshake

Question

Problem Overview
When a custom domain is configured for Appwrite’s Realtime service, the client first performs a DNS lookup, then establishes a TLS handshake. A timeout before the handshake indicates a potential DNS or certificate issue.
Goal & Constraints
The objective is to determine whether the failure originates from DNS propagation (missing A record or restricted CAA), from the TLS certificate chain (self‑signed, expired, or untrusted), or from the client’s trust store. The investigation must be performed without altering Appwrite’s internal settings, relying only on publicly available DNS and TLS tools.
Uncertainty
It is unclear whether the custom domain resolves to Appwrite’s infrastructure, whether the certificate authority is permitted by the domain’s CAA record, and whether the client environment accepts the presented certificate chain.
Specific Questions

Does the custom domain’s A record point to the correct Appwrite IP address, and is the response consistent across multiple DNS resolvers?
Are the domain’s CAA records configured to allow the certificate authority that issued the TLS certificate?
Is the TLS certificate chain presented by the Realtime endpoint trusted by the client’s operating system or application trust store?

Tasadduq Burney · Answer

Resolution Strategy
A timeout occurring before the TLS handshake indicates that the client cannot resolve the domain name to an IP address or cannot establish a TCP connection to the resolved IP. This is a network-layer failure, not a cryptographic one.

Likely Explanations
While the symptoms suggest a DNS failure, the root cause typically falls into one of three categories:

DNS Propagation or Misconfiguration: The A record is missing, incorrect, or has not yet propagated globally, leaving the client unable to find the server.
  CAA Restrictions: If a Certification Authority Authorization (CAA) record exists but does not list the CA used by Appwrite, the certificate may not have been issued or renewed, leading to a failure when the client attempts to validate the endpoint.
  Client-Side Trust Issues: If the DNS resolves but the connection drops immediately, the client may be rejecting the certificate chain (e.g., missing intermediate certificates) before the handshake completes.

Verification Steps
Perform these checks using external tools to isolate the failure point without modifying internal settings.

1. Validate DNS Resolution
Verify that the A record points to the correct Appwrite infrastructure IP and is consistent across different resolvers to rule out local cache or propagation issues.
# Check via Google DNS
dig @8.8.8.8 your-custom-domain.com A

# Check via Cloudflare DNS
dig @1.1.1.1 your-custom-domain.com A

2. Inspect CAA Records
Ensure the domain allows the specific CA that issued the Appwrite certificate. If the CAA record is too restrictive, the certificate may be invalid.
dig your-custom-domain.com CAA

3. Analyze the TLS Chain
If DNS resolves but the connection fails, check if the server is presenting a complete certificate chain. A missing intermediate certificate often causes clients to timeout or reject the connection.
openssl s_client -connect your-custom-domain.com:443 -showcerts

Required Diagnostic Detail
To narrow this down further: Does the timeout occur across all client environments (e.g., both a browser and a CLI tool like curl), or is it isolated to a specific operating system/trust store?

Realtime API: DNS resolution timeout before TLS handshake

Problem Overview

Goal & Constraints

Uncertainty

Specific Questions

1 answer

Resolution Strategy

Likely Explanations

Verification Steps

1. Validate DNS Resolution

2. Inspect CAA Records

3. Analyze the TLS Chain

Required Diagnostic Detail

Your perspective belongs here.

0 question comments