For other readers with the same question: See also Address to be used to access private ipaddress for AZURE resource from on-premise for some background information.
Before I start to answer a small correction to your question, as you wrote "... same DNS name". I think this is a misunderstanding, as the Azure Cosmos DB is a fully managed service, means PaaS and as such has unique names. In other words, it is impossible that two Azure Cosmos DB services will have the same DNS name. Still, I don't want to correct that in the question, but prefer the reference as part of the answer, as this is indeed a common misunderstanding. It all boils down to the way the name resolution of a hybrid solution is architected.
Resolving such a scenario is easy, by using unique DNS names (which is not a problem as CosmosDB is SaaS and as such has unique names) and to make sure that all the resources can be resolved.
Brief Answer
For each of your subscriptions under corporate account connected to on-premise via ExpressRoute or VPN, configure a Azure private DNS and a DNS forwarder, which is deployed within the same subnet. A Hub connects everything, including on-premise.
Long Answer
Hypothetic example (mission definition)
How it works is better to explain using an example.
Given the hypothetic corporate "NKOTB INC" has 3 departments:
Each department operates 2 Azure subscriptions, one for development, the other for production workload. So we have to deal with at least six subscriptions in total, to meet the requirements.
The network-related requirements are the following:
- Every subscription needs to have connectivity to on-premise.
- Every subscription may or may not use resources which are deployed using private links.
- Because of legal restrictions, all resources within all subscriptions are currently deployed within region "East US".
- It is planned to extend the business, eventually using other regions. Hence, this should be considered in the planning.
Implementation approach
Using this scenario, you may end up with at least 7 subscriptions:
- dev-finance
- prd-finance
- dev-it
- prd-it
- dev-marketing
- prd-marketing
- Hub which connects to on-premise via VPN or ExpressRoute.
All six subscriptions needs to deploy a Azure private DNS and a DNS forwarder. Furthermore, all of them using a VNET which is peered to the central Hub-subscription. So eventually you will end up with this seven internal DNS domains:
- dev.finance.eastus.azure.nkotb
- prd.finance.eastus.azure.nkotb
- dev.it.eastus.azure.nkotb
- prd.it.eastus.azure.nkotb
- dev.marketing.eastus.azure.nkotb
- prd.marketing.eastus.azure.nkotb
- hub.eastus.azure.nkotb
The Hub-subscription has a second set of DNS servers and forwarders configured. Only this set of DNS servers is aware of the other seven DNS forwarders deployed in the other domains, and responsible for name resolution of the Domain "eastus.azure.nkotb". All on-premise DNS servers are configured to forward all DNS requests for *.eastus.azure.nkotb to this set of DNS servers.
Example 1: internal DNS between a subscription and on premise
Given the finance team decides to deploy a database named "Alzheimer" within the production subscription, using a private link. So the internal DNS name (FQDN) for this database would be alzheimer.prd.finance.eastus.azure.nkotb.
Thanks to the internal name resolution which is aligned across all subscriptions and also on-prem, this name could be resolved everywhere within corporate network.
How Example 1 works
- A random client located on-premise is asking the local DNS server there to resolve
alzheimer.prd.finance.eastus.azure.nkotb.
- The local DNS server does not know the answer, but is configured to forward all requests for
*.eastus.azure.nkotb to the the DNS forwarder deployed within the Hub-subscription, so he does. This DNS server is reachable (network-wise), as on-premise is connected to this hub subscription via ExpressRoute/VPN.
- The DNS forwarder deployed within the hub subscription does not know the answer, but is aware of the DNS forwarder which is deployed in the production finance subscription, so the request is forwarded in this direction. This DNS server is reachable (network-wise), as both subscriptions have peered VNET's.
- The DNS server and forwarder deployed in prd.finance.eastus.azure.nkotb can resolve the IP address of the database, and sends the answer back in the chain.
- The client located on-premise receives the answer.
- Each follow-up DNS request (within the TTL of the record) will be answered immediately from the local DNS server, as the answer has been cached.
Example 2: internal DNS between 2 subscriptions
Given the marketing team decides to deploy a database named "Ballyhoo" within the dev subscription, so the internal DNS name would be ballyhoo.dev.marketing.eastus.azure.nkotb. As the other database deployed by finance, this database can be resolved as well from on-prem. But in this scenario, the IT team collects some data within the IT dev subscription, which should be stored using ballyhoo.dev.marketing.eastus.azure.nkotb database. So this scenario describes how a DNS record can be resolved within 2 subscriptions.
How Example 2 works
- The data collection app deployed in dev-IT subscription asks the local DNS resolver deployed within the same VNET for IP address of
ballyhoo.dev.marketing.eastus.azure.nkotb.
- The local DNS server does not know the answer, but is configured to forward all requests to the the DNS forwarder deployed within the Hub-subscription, so he does. This DNS server is reachable (network-wise), as both subscriptions have peered VNET's.
- The DNS forwarder deployed within the hub subscription does not know the answer, but is aware of the DNS forwarder which is deployed in the dev marketing subscription, so the request is forwarded in this direction. This DNS server is reachable (network-wise), as both subscriptions have peered VNET's.
- The DNS server and forwarder deployed in dev.marketing.eastus.azure.nkotb can resolve the IP address of the database, and sends the answer back in the chain.
- The data collection app receives the answer.
- Each follow-up DNS request (within the TTL of the record) will be answered immediately from the local DNS server, as the answer has been cached.
Notes
Your business contact in Azure usually helps to plan such scenarios, so you don't have to work out everything yourself. There are other important aspects to consider during the planning process, but space does not allow them to be outlined here. Realization: It usually helps if the network team is included in the process from the very beginning.
In general, I highly recommend to use the free Microsoft Learn for Azure to build up the necessary knowledge and skills. For your questions, the following courses would be adequate:
