Update FAQ with Private DNS zone information #591
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Added new FAQ entry regarding Private DNS zone linking in hub-spoke topology.
Contributor
|
@AhmadAbdullah91 : Thanks for your contribution! The author(s) and reviewer(s) have been notified to review your proposed change. |
Contributor
|
Learn Build status updates of commit 6332290: ✅ Validation status: passed
For more details, please refer to the build report. |
Contributor
PRMerger Results
|
Contributor
|
Can you review the proposed changes? Important: When the changes are ready for publication, adding a #label:"aq-pr-triaged" |
There was a problem hiding this comment.
Pull Request Overview
This PR adds a new FAQ entry to the Virtual networking section addressing DNS zone linking requirements in hub-spoke network topologies for Azure AI Foundry Agent Service.
Key Changes
- Adds a new Q&A about Private DNS zone linking requirements in hub-spoke topologies
- Clarifies that spoke VNets must be independently linked to Private DNS zones, as VNet peering does not automatically propagate DNS zone links
| The template provides support for the built-in tools: Code Interpreter, File Search, Azure AI Search, Cosmos DB (all tools that use the Bring-Your-Own (BYO) resource connections). To configure tools that require the creation of a new connection, you must create a private endpoint from your `peSubnet`` and create a private link from the Azure Resource. | ||
| The template provides support for the built-in tools: Code Interpreter, File Search, Azure AI Search, Cosmos DB (all tools that use the Bring-Your-Own (BYO) resource connections). To configure tools that require the creation of a new connection, you must create a private endpoint from your `peSubnet`` and create a private link from the Azure Resource. | ||
| - question: | | ||
| In hub-spoke like topology, If I have Private DNS zone(s) linked to my hub Vnet, do I still need to link them to spoke Vnet(s) such as Agent Vnet? |
There was a problem hiding this comment.
Multiple spelling and capitalization issues in the question:
- "hub-spoke like topology" should be "hub-spoke topology" (remove "like")
- "If" should be lowercase "if" since it's not the first word of the sentence
- "Vnet" should be "VNet" (capital N) consistently throughout to match Azure standard terminology and the capitalization used in the answer
Suggested change
| In hub-spoke like topology, If I have Private DNS zone(s) linked to my hub Vnet, do I still need to link them to spoke Vnet(s) such as Agent Vnet? | |
| In a hub-spoke topology, if I have Private DNS zone(s) linked to my hub VNet, do I still need to link them to spoke VNet(s) such as Agent VNet? |
| - question: | | ||
| In hub-spoke like topology, If I have Private DNS zone(s) linked to my hub Vnet, do I still need to link them to spoke Vnet(s) such as Agent Vnet? | ||
| answer: | | ||
| Yes, you need to link the spoke VNet to the private DNS zone to resolve DNS names from the spoke network. Linking the hub VNet to the private DNS zone is not enough, as VNet peering does not automatically propagate the DNS zone link. To ensure resources in spoke VNets can resolve private endpoints, each spoke VNet (Agent Vnet) must have a link to the private DNS zone. |
There was a problem hiding this comment.
There appear to be trailing spaces at the end of this line. Trailing whitespace should be removed for consistency.
Suggested change
| Yes, you need to link the spoke VNet to the private DNS zone to resolve DNS names from the spoke network. Linking the hub VNet to the private DNS zone is not enough, as VNet peering does not automatically propagate the DNS zone link. To ensure resources in spoke VNets can resolve private endpoints, each spoke VNet (Agent Vnet) must have a link to the private DNS zone. | |
| Yes, you need to link the spoke VNet to the private DNS zone to resolve DNS names from the spoke network. Linking the hub VNet to the private DNS zone is not enough, as VNet peering does not automatically propagate the DNS zone link. To ensure resources in spoke VNets can resolve private endpoints, each spoke VNet (Agent Vnet) must have a link to the private DNS zone. |
| - question: | | ||
| In hub-spoke like topology, If I have Private DNS zone(s) linked to my hub Vnet, do I still need to link them to spoke Vnet(s) such as Agent Vnet? | ||
| answer: | | ||
| Yes, you need to link the spoke VNet to the private DNS zone to resolve DNS names from the spoke network. Linking the hub VNet to the private DNS zone is not enough, as VNet peering does not automatically propagate the DNS zone link. To ensure resources in spoke VNets can resolve private endpoints, each spoke VNet (Agent Vnet) must have a link to the private DNS zone. |
There was a problem hiding this comment.
Inconsistent capitalization: "Vnet" in "Agent Vnet" should be "VNet" (capital N) to match the standard Azure terminology and the capitalization used in the answer text ("Agent VNet", "spoke VNet", "spoke VNets").
Suggested change
| Yes, you need to link the spoke VNet to the private DNS zone to resolve DNS names from the spoke network. Linking the hub VNet to the private DNS zone is not enough, as VNet peering does not automatically propagate the DNS zone link. To ensure resources in spoke VNets can resolve private endpoints, each spoke VNet (Agent Vnet) must have a link to the private DNS zone. | |
| Yes, you need to link the spoke VNet to the private DNS zone to resolve DNS names from the spoke network. Linking the hub VNet to the private DNS zone is not enough, as VNet peering does not automatically propagate the DNS zone link. To ensure resources in spoke VNets can resolve private endpoints, each spoke VNet (Agent VNet) must have a link to the private DNS zone. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Added new FAQ entry regarding Private DNS zone linking in hub-spoke topology.