Azure SQL Managed Instance resolves through on-prem AD DNS without an A record in AD DNS

Imran Sayyad 0 Reputation points
2026-09-04T06:35:24.11+00:00

Hello Community,

I am looking to understand the DNS resolution behavior of an Azure SQL Managed Instance deployed with private connectivity.

Environment:

  • Azure SQL Managed Instance: sqlmi-db-qppoc-dev-ci
  • Public network access is disabled
  • Connectivity is through private networking only
  • On-premises AD DNS server is being used as a custom DNS server
  • We are NOT using Azure Private DNS Zones for name resolution
  • Users are successfully connecting to the SQL Managed Instance from the on-premises environment

Observation:

When I run the following command:

nslookup sqlmi-db-qppoc-dev-ci.18455edec727.database.windows.net

the result resolves successfully to a private IP address:

Name: tr7461.indiacentral1-a.worker.vnet.database.windows.net

Address: 10.65.3.201

Aliases:

sqlmi-db-qppoc-dev-ci.18455edec727.database.windows.net

sqlmi-db-qppoc-dev-ci.privatelink.18455edec727.database.windows.net

Concern:

Since public access is disabled and we are not using Azure Private DNS Zones, I expected the SQL Managed Instance FQDN to only resolve if a corresponding DNS record existed within our custom DNS infrastructure.

However:

  • I cannot find a corresponding A record in our Active Directory DNS server.
  • We are using a custom/on-premises DNS server.
  • The FQDN still resolves successfully to a private IP address.
  • End users and applications are able to connect successfully to the SQL Managed Instance over the private network.

Questions:

  1. Is this expected behavior for Azure SQL Managed Instance?
  2. How is the FQDN resolving when no A record exists in the AD DNS server?
  3. Could Azure be using Conditional Forwarders, DNS Forwarding, Azure DNS Private Resolver, or another Azure-managed DNS mechanism even though Azure Private DNS Zones are not being used?
  4. What is the significance of the hostname:

tr7461.indiacentral1-a.worker.vnet.database.windows.net?

  1. How can I validate the complete DNS resolution path from the client through the custom DNS server to Azure?
  2. What DNS components should I review to determine how this resolution is occurring?

I would appreciate guidance on understanding the DNS architecture involved and why the SQL Managed Instance endpoint continues to resolve and function successfully despite the absence of a visible A record in our AD DNS environment.

Azure DNS
Azure DNS

An Azure service that enables hosting Domain Name System (DNS) domains in Azure.

0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. TP 163K Reputation points Volunteer Moderator
    2026-09-04T06:57:45.51+00:00

    Hi,

    What you are seeing is normal and expected for Azure SQL Managed Instance. The VNet-local endpoint domain name (sqlmi-db-qppoc-dev-ci.18455edec727.database.windows.net in your case) resolves to the private IP address for the SQL MI in the VNet. This is resolved through Azure's public DNS automatically.

    In your case when on-premises PC attempts to connect it sends DNS lookup to your AD DNS server, which forwards it to public DNS resolver, which performs recursive lookup. Azure's public DNS returns the private IP for the VNet-local endpoint.

    Below is excerpt from Azure SQL MI connectivity documentation:

    VNet-local endpoint

    The VNet-local endpoint is the default means to connect to SQL Managed Instance. The VNet-local endpoint domain name is in the form of <mi_name>.<dns_zone>.database.windows.net. This domain name resolves to an IP address from the subnet's address range. Use the VNet-local endpoint to connect to a SQL Managed Instance in all standard connectivity scenarios. The VNet-local endpoint accepts connections on port 1433.

    The VNet-local endpoint supports Proxy and redirect connection types.

    When connecting to the VNet-local endpoint, always use its domain name and allow inbound traffic on the required ports across the entire subnet range, as the underlying IP address can occasionally change.

    To find the VNet-local endpoint domain name for an instance:

    • Azure portal: On the Overview pane after you select your SQL managed instance, in the Essentials section, the Host value shows the VNet-local endpoint domain name.
    • PowerShell: Get-AzSqlInstance -ResourceGroupName <resource-group> -Name <mi-name> shows the VNet-local endpoint domain name as the fullyQualifiedDomainName property.
    • Azure CLI: az sql mi show -g <resource-group> -n <mi-name> shows the VNet-local endpoint domain name as the fullyQualifiedDomainName property.

    For improved security, specify an encrypted connection, and don't trust the certificate. For more information, see Security overview.

    Please click Accept Answer and upvote if the above was helpful. If something is unclear, please add comment below.

    Thanks.

    -TP

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.