ngrok custom domain: separating DNS, CAA, and certificate-issuance failures

Where the fault could sit

When an ngrok endpoint on a reserved custom domain shows a hostname-resolution or certificate-validation symptom, the cause could sit in the public DNS record and its CAA rules, in ngrok's asynchronous certificate provisioning, or in the local service behind the agent. The goal is to identify which layer to investigate first before changing any configuration.

Constraints that blur the diagnosis

• ngrok terminates TLS at its edge by default, so the certificate public clients see is served by ngrok, not the local application.
• Managed certificates are provisioned only after the DNS record points at ngrok, and issuance can be blocked by CAA records that do not authorize the authority.
• The agent's DNS-rebinding protection rejects requests whose Host header does not match the tunnel hostname, which can mimic a resolution failure.
• TLS pass-through instead of edge termination moves certificate responsibility to the local service, giving one symptom different owners.

Agent option names and provisioning behavior also vary across releases, so any conclusion needs checking against current documentation.

Open questions

1. Which checks reliably separate an unpropagated or CAA-blocked DNS record from a certificate ngrok has not finished provisioning?
2. Can a Host-header rejection from the agent's rebinding protection be distinguished from an edge or DNS failure through the agent's inspection interface?
3. Between ngrok-managed and uploaded certificates, which expiry and chain failure modes shift to the operator?