<WIP> Recommendations for PrivateLink DNS setup. - #5285
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📖 Docs PR preview links
|
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| For Namespaces with [High Availability](/cloud/high-availability/ha-connectivity), the PHZ pattern to use depends on how you want Workers to reach the active region. Overriding the Namespace Endpoint directly is read out of the PHZ before public DNS, so the regional CNAME that Temporal Cloud rewrites on failover isn't followed — which is usually not what you want, but can be the right choice in some topologies (for example, multi-cloud HA with one region per cloud, where Workers on each cloud should always reach their local region). Because the trade-offs depend on your setup, see [Connectivity for High Availability](/cloud/high-availability/ha-connectivity) before choosing a pattern. | ||
| In all three patterns the record is a `CNAME` whose value is your VPC Endpoint DNS name (`vpce-….vpce.amazonaws.com`), which resolves to that endpoint's addresses in your VPC. | ||
|
|
||
| #### Pattern A: one record per Namespace |
There was a problem hiding this comment.
📝 [vale] <Temporal.Headings> reported by reviewdog 🐶
'Pattern A: one record per Namespace' should use sentence-style capitalization.
|
|
||
| Create a private hosted zone for the Namespace Endpoint itself and add a single `CNAME` in it. Nothing else resolves through that zone, so a mistake affects one Namespace. Follow the [step-by-step instructions](#step-by-step-instructions) below. | ||
|
|
||
| #### Pattern B: wildcard record for the account |
There was a problem hiding this comment.
📝 [vale] <Temporal.Headings> reported by reviewdog 🐶
'Pattern B: wildcard record for the account' should use sentence-style capitalization.
|
|
||
| ::: | ||
|
|
||
| #### Pattern C: regional records |
There was a problem hiding this comment.
📝 [vale] <Temporal.Headings> reported by reviewdog 🐶
'Pattern C: regional records' should use sentence-style capitalization.
| @@ -144,7 +178,7 @@ Save the **`vpce-*.amazonaws.com`** value — you will target it in the CNAME re | |||
| #### 2. Create a Route 53 Private Hosted Zone (do not yet attach Worker VPCs) | |||
There was a problem hiding this comment.
📝 [vale] <Temporal.Headings> reported by reviewdog 🐶
'2. Create a Route 53 Private Hosted Zone (do not yet attach Worker VPCs)' should use sentence-style capitalization.
|
|
||
| In all three patterns the record is an `A` record whose value is the internal IP address of your PSC endpoint. | ||
|
|
||
| #### Pattern A: one record per Namespace |
There was a problem hiding this comment.
📝 [vale] <Temporal.Headings> reported by reviewdog 🐶
'Pattern A: one record per Namespace' should use sentence-style capitalization.
|
|
||
| Create a private zone for the Namespace Endpoint itself and add a single `A` record in it. Nothing else resolves through that zone, so a mistake affects one Namespace. Follow the [step-by-step instructions](#step-by-step-instructions) below. | ||
|
|
||
| #### Pattern B: wildcard record for the account |
There was a problem hiding this comment.
📝 [vale] <Temporal.Headings> reported by reviewdog 🐶
'Pattern B: wildcard record for the account' should use sentence-style capitalization.
|
|
||
| ::: | ||
|
|
||
| #### Pattern C: regional records |
There was a problem hiding this comment.
📝 [vale] <Temporal.Headings> reported by reviewdog 🐶
'Pattern C: regional records' should use sentence-style capitalization.
❌ Docs build failedBroken anchorsThe target page exists, but the heading/anchor it links to doesn't. Fix the anchor, or add the missing heading to the target page.
Run |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d82ea95b20
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| For step 2, we recommend private DNS that resolves your [Namespace Endpoint](/cloud/namespaces#access-namespaces) (`<namespace>.<account>.tmprl.cloud`) to your Private Endpoint, rather than reconfiguring Clients to dial the Private Endpoint directly. Two things follow from that: | ||
|
|
||
| - **Clients keep the settings they already use.** The address and TLS configuration are the same as they would be over the public internet, so every SDK sample, demo, and existing deployment works unchanged, and no TLS server name (SNI) override is needed. The hostname the Client dials is still the hostname on the certificate Temporal Cloud presents. | ||
| - **Namespaces with High Availability features can follow a failover.** Temporal Cloud repoints the Namespace Endpoint at the active region, so Workers reach whichever region is active without a configuration change. Getting that behavior over a private connection depends on which private DNS pattern you choose. |
There was a problem hiding this comment.
For GCP PSC deployments, this provider-neutral bullet promises that Workers follow the active region without a configuration change, but docs/cloud/connectivity/gcp-connectivity.mdx:24-28 says automatic DNS failover is unsupported and Workers must be manually repointed. Add that GCP exception here, or update the GCP warning if support has changed; otherwise readers can select the linked GCP pattern expecting automatic recovery that the provider guide says they will not get.
AGENTS.md reference: AGENTS.md:L236-L242
Useful? React with 👍 / 👎.
|
|
||
| :::warning A wildcard blocks failover for Namespaces with High Availability features | ||
|
|
||
| The wildcard also matches the Namespace Endpoint of every Namespace with [High Availability features](/cloud/high-availability) in the account. The resolver answers from the PHZ before consulting public DNS, so Temporal Cloud's active-region CNAME is never followed and Workers stay pinned to one region's VPC Endpoint. After a failover, those Workers cannot read or write in the new active region. Use pattern C for those Namespaces. |
There was a problem hiding this comment.
With the default forwarding behavior documented in docs/cloud/high-availability/ha-connectivity.mdx:89-90, requests that reach the old, now-passive endpoint are transparently forwarded to the active region; only Worker-poll forwarding can be disabled. Therefore the statement that wildcard users cannot read or write after failover is too broad. Describe this as losing DNS-based rerouting, explain that access fails when forwarding is disabled, and update the same claim in docs/cloud/connectivity/gcp-connectivity.mdx:144.
AGENTS.md reference: AGENTS.md:L236-L240
Useful? React with 👍 / 👎.
| | Namespace details | Needed to choose the correct override domain pattern below. | | ||
|
|
||
| ### Choose the override domain and endpoint | ||
| ### Choose a private DNS pattern {/* #choose-a-private-dns-pattern */} |
There was a problem hiding this comment.
Adding the A/B/C subsections raises this page from 17 to 21 headings and the parallel GCP page from 13 to 17, putting both above the repository's target of fewer than 15 total headings. Because most of the new pattern-selection material is duplicated across providers, move that shared decision guidance to a dedicated page and leave only the provider-specific Route 53 and Cloud DNS mechanics here.
AGENTS.md reference: AGENTS.md:L246-L252
Useful? React with 👍 / 👎.
1 participant
What does this PR do?
Clarify the options that users have when using Private DNS to have Workers connect over PrivateLink to Temporal Cloud.