Azure MongoDB vCore (DocumentsDB) not registered at Azure DNS service

Question

Azure MongoDB vCore (DocumentsDB) not registered at Azure DNS service

Iñigo Martinez Lasala 20

After creating two differente DocumentsDB instance, IP address is not registered at Azure DNS. So, no connection is possible.

User's image

Manoj Kumar Boyini 19,590 Reputation points Microsoft External Staff Moderator

2026-05-27T12:28:38.2966667+00:00
Hi @Iñigo Martinez Lasala

After reviewing the behavior, this does not currently indicate that Azure Cosmos DB for MongoDB vCore (DocumentDB) failed to register the endpoint in Azure DNS.

The cluster endpoint uses the mongodb+srv:// connection format, which relies on DNS SRV-based service discovery rather than direct A-record resolution of the cluster hostname. Because of this, performing a direct lookup against:

dig <cluster-name>.mongocluster.cosmos.azure.com

may not return a direct A record and by itself does not confirm a DNS registration issue.

Based on the observed behavior and current troubleshooting guidance, the more likely scenarios are:

Private Endpoint DNS resolution is not returning the expected private endpoint address

Private DNS integration is missing or not linked correctly to the client VNet

Internal/custom DNS is not forwarding Azure DNS requests correctly

Network appliances (NVA/Firewall/UDR) are affecting connectivity

VNet peering or routing configuration is influencing endpoint access

To validate the connectivity path, please perform the following checks:

1. Validate TCP connectivity to the cluster

Test-NetConnection <cluster-name>.mongocluster.cosmos.azure.com -Port 10260

2. Validate MongoDB connectivity using the portal-generated connection string

mongosh "mongodb+srv://<user>:<password>@<cluster-name>.mongocluster.cosmos.azure.com/?tls=true&authMechanism=SCRAM-SHA-256&retryWrites=false&maxIdleTimeMS=120000"

3. Validate SRV-based DNS resolution Linux:

nslookup -type=SRV _mongodb._tcp.<cluster-name>.mongocluster.cosmos.azure.com

Windows:

Resolve-DnsName -Type SRV _mongodb._tcp.<cluster-name>.mongocluster.cosmos.azure.com

4. If using Private Endpoint, verify endpoint resolution Linux:

nslookup <cluster-name>.mongocluster.cosmos.azure.com

Windows:

Resolve-DnsName <cluster-name>.mongocluster.cosmos.azure.com

Expected result:

Endpoint should resolve according to the intended network configuration.

For Private Endpoint scenarios, resolution should align with the configured private endpoint path.

Additionally, please confirm:

Whether connectivity is configured via Public Access or Private Endpoint

Whether Azure-provided DNS or custom/internal DNS is being used

Private Endpoint status in Azure Portal (Approved / Pending)

Once we have these validation results, we can continue narrowing down whether the issue is DNS resolution, Private DNS integration, routing, or network connectivity.
Manoj Kumar Boyini 19,590 Reputation points Microsoft External Staff Moderator

2026-05-27T12:31:16.21+00:00
Hi @Iñigo Martinez Lasala

The SRV lookup is actually returning a valid record, so this does not appear to be a case where the cluster is missing SRV registration in Azure DNS. For Azure Cosmos DB for MongoDB vCore / Azure DocumentDB, the mongodb+srv connection flow relies on SRV-based discovery first, and then the returned hostname(s) must resolve and be reachable on the required MongoDB port.

The A lookup of the cluster hostname returning only the SOA record is not, by itself, proof of a DNS registration failure. The next step is to validate whether the SRV target hostname resolves to the expected IP and whether the client can reach the service over TCP.

Since you mentioned the instance is public, please also confirm that:

the client public IP is allowed in the cluster firewall rules, and

outbound connectivity to the service is not blocked by any local firewall, NVA, or corporate network policy.

For Azure DocumentDB, Microsoft recommends testing connectivity to port 10260 from the affected client machine. If that TCP test fails, it typically indicates a network/firewall block in the path.

Based on the current evidence, this looks more like a client connectivity or network-access issue than a DNS registration bug.
Manoj Kumar Boyini 19,590 Reputation points Microsoft External Staff Moderator

2026-05-27T12:43:45.96+00:00
Hi @Iñigo Martinez Lasala

We also reviewed recent platform health signals for MongoDB clusters in France Central. There was a transient gateway availability event detected for a non-HA cluster in the region; however, monitoring later confirmed recovery and the event was closed without indication of ongoing impact.

Since your DNS validation already shows successful SRV discovery, the next focus is to determine whether connection attempts are reaching the gateway.

To help continue investigation, please share:

Exact timestamp of one failed connection attempt (including timezone)

Full client-side error message returned during connection (mask credentials if needed)

Whether the failure occurs consistently or intermittently

This information will help determine whether requests are failing before reaching the gateway (network path) or during gateway processing.
Iñigo Martinez Lasala 20 Reputation points

2026-05-27T13:46:59.84+00:00

Hi @Manoj Kumar Boyini

Fixed. The problem was not located at public SRV register, but at internal A register in our private zone.

In our private zone privatelink.mongocluster.cosmos.azure.com didn't exists and so SRV register could not be properly resolved.

With this we can solve the issue although we don't understand if this is an issue or it's the default behaviour. We would expect that the A register at private zone would be also filled by provisoning process.

Thank you.

Answer accepted by question author

AI answer

Azure Cosmos DB for MongoDB vCore (DocumentDB) doesn’t expose a direct IP address that must be registered in Azure DNS for connectivity. Connectivity is based on DNS names and SRV records, and clients must use the mongodb+srv connection string provided in the Azure portal.

To verify and troubleshoot DNS/connection issues for the vCore cluster:

Verify the private endpoint (if used)
1. In the Azure portal, open the DocumentDB (MongoDB vCore) cluster.
2. Go to Networking and confirm the private endpoint is listed with status Approved.
3. Select the private endpoint and note the assigned private IP.

Validate DNS resolution from within the virtual network

From a Windows VM in the same VNet/peered VNet:

Resolve the SRV record:

        Resolve-DnsName -Name _mongodb._tcp.<your-cluster-name>.mongocluster.cosmos.azure.com -Type SRV

Resolve each node hostname returned by the SRV record and confirm they resolve to private IPs (10.x.x.x, etc.):
```
        Resolve-DnsName -Name <your-node-hostname>.mongocluster.cosmos.azure.com
```

From Linux/macOS in the same VNet/peered VNet:

Resolve the SRV record:

        dig _mongodb._tcp.<your-cluster-name>.mongocluster.cosmos.azure.com SRV

Resolve each node hostname:

        dig <your-node-hostname>.mongocluster.cosmos.azure.com

Fix common DNS issues
- If DNS returns public IPs or fails:
  1. Ensure the private DNS zone privatelink.mongocluster.cosmos.azure.com exists and is linked to the VNet.
  2. Verify the DNS zone group is correctly configured on the private endpoint.
  3. Confirm the VNet DNS servers are either Azure-provided DNS (168.63.129.16) or a custom DNS that forwards to Azure DNS.
  4. Make sure tests are run from within the VNet or a properly peered VNet.
Fix connection timeouts
- Check NSG rules on the subnet to allow outbound traffic on port 27017.
- Confirm the private endpoint NIC shows the expected private IP.
- Ensure the client uses the exact mongodb+srv:// connection string from the portal (no modifications).
- Verify cluster firewall rules allow access from the private endpoint or required IP ranges.
If DNS still doesn’t resolve correctly
- For custom DNS solutions, run nslookup <fqdn> for each FQDN listed in the private endpoint’s DNS configuration and confirm the returned IP matches the private IP shown in the portal. If not, update the custom DNS configuration so those names resolve to the private IP.

If these checks succeed, the cluster is correctly registered and reachable via Azure DNS, and clients should connect using the provided mongodb+srv connection string rather than a raw IP address.

References:

AI-generated content may be incorrect. Read our transparency notes for more information.

3 additional answers

Your answer

Manoj Kumar Boyini 19,590 Reputation points Microsoft External Staff Moderator

2026-05-27T12:31:16.21+00:00

Hi @Iñigo Martinez Lasala

The SRV lookup is actually returning a valid record, so this does not appear to be a case where the cluster is missing SRV registration in Azure DNS. For Azure Cosmos DB for MongoDB vCore / Azure DocumentDB, the mongodb+srv connection flow relies on SRV-based discovery first, and then the returned hostname(s) must resolve and be reachable on the required MongoDB port.

The A lookup of the cluster hostname returning only the SOA record is not, by itself, proof of a DNS registration failure. The next step is to validate whether the SRV target hostname resolves to the expected IP and whether the client can reach the service over TCP.

Since you mentioned the instance is public, please also confirm that:

the client public IP is allowed in the cluster firewall rules, and

outbound connectivity to the service is not blocked by any local firewall, NVA, or corporate network policy.

For Azure DocumentDB, Microsoft recommends testing connectivity to port 10260 from the affected client machine. If that TCP test fails, it typically indicates a network/firewall block in the path.

Based on the current evidence, this looks more like a client connectivity or network-access issue than a DNS registration bug.
Manoj Kumar Boyini 19,590 Reputation points Microsoft External Staff Moderator

2026-05-27T12:43:45.96+00:00

Hi @Iñigo Martinez Lasala

We also reviewed recent platform health signals for MongoDB clusters in France Central. There was a transient gateway availability event detected for a non-HA cluster in the region; however, monitoring later confirmed recovery and the event was closed without indication of ongoing impact.

Since your DNS validation already shows successful SRV discovery, the next focus is to determine whether connection attempts are reaching the gateway.

To help continue investigation, please share:

Exact timestamp of one failed connection attempt (including timezone)

Full client-side error message returned during connection (mask credentials if needed)

Whether the failure occurs consistently or intermittently

This information will help determine whether requests are failing before reaching the gateway (network path) or during gateway processing.
Iñigo Martinez Lasala 20 Reputation points

2026-05-27T13:46:59.84+00:00

Hi @Manoj Kumar Boyini

Fixed. The problem was not located at public SRV register, but at internal A register in our private zone.

In our private zone privatelink.mongocluster.cosmos.azure.com didn't exists and so SRV register could not be properly resolved.

With this we can solve the issue although we don't understand if this is an issue or it's the default behaviour. We would expect that the A register at private zone would be also filled by provisoning process.

Thank you.

Answer 1

Hi @Iñigo Martinez Lasala

Thank you for confirming the resolution.

This behavior is expected for Private Endpoint connectivity and is not related to missing public SRV registration. In this case, the private DNS zone privatelink.mongocluster.cosmos.azure.com was not present, which prevented the SRV-discovered endpoint from resolving through the private DNS path.

When creating a Private Endpoint, Azure supports automatic DNS configuration if “Integrate with private DNS zone = Yes” is selected, otherwise equivalent DNS configuration needs to be managed manually.

Reference:
https://learn.microsoft.com/en-us/azure/documentdb/how-to-private-link
https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-dns

Hope this helps, Please let us know if you have any questions or concerns.

Answer 2

; <<>> DiG 9.18.39-0ubuntu0.24.04.5-Ubuntu <<>> tdstg2mongodb03.mongocluster.cosmos.azure.com

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1957

;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:

;tdstg2mongodb03.mongocluster.cosmos.azure.com. IN A

;; AUTHORITY SECTION:

mongocluster.cosmos.azure.com. 300 IN SOA ns1-07.azure-dns.com. azuredns-hostmaster.microsoft.com. 1 3600 300 2419200 300

;; Query time: 59 msec

;; SERVER: 10.255.255.254#53(10.255.255.254) (UDP)

;; WHEN: Wed May 27 13:52:29 CEST 2026

;; MSG SIZE rcvd: 146

; <<>> DiG 9.18.39-0ubuntu0.24.04.5-Ubuntu <<>> _mongodb._tcp.tdstg2mongodb03.mongocluster.cosmos.azure.com SRV

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39260

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1232

;; QUESTION SECTION:

;_mongodb._tcp.tdstg2mongodb03.mongocluster.cosmos.azure.com. IN SRV

;; ANSWER SECTION:

_mongodb._tcp.tdstg2mongodb03.mongocluster.cosmos.azure.com. 30 IN SRV 0 0 10260 fc-a7be224f0533-000.mongocluster.cosmos.azure.com.

;; Query time: 100 msec

;; SERVER: 10.255.255.254#53(10.255.255.254) (UDP)

;; WHEN: Wed May 27 13:52:18 CEST 2026

;; MSG SIZE rcvd: 157

No SRV register. No A register. Unable to connect.

Instance is PUBLIC.

Answer 3

Iñigo Martinez Lasala 20

FQDN test has already been done. No IP -> hostname is registered at Azure public DNS service. No response. IP comes in blank.

Repeated twice with two different instances. Some kind of bug is present when provisioning instances.

0 comments