Azure SQL Managed Instance TLS custom domain issues

Question

Azure SQL Managed Instance TLS custom domain issues

Julie 220

When connecting to Azure SQL Managed Instance via a private DNS zone, the TLS certificate presented by Microsoft only contains the service FQDN (for example, *.database.windows.net). It does not include the private DNS zone we have created (e.g., sqlmi-prod.contoso.local)?

Why doesn’t Microsoft include private/custom hostnames in the TLS certificate for Managed Instance?

Is it correct that the certificates are service-managed and controlled by Microsoft, so customers cannot upload or bind their own certificates?

What is the officially recommended approach if we want to connect using a private/internal DNS alias — should we always use the Managed Instance FQDN, or rely on client-side options such as HostNameInCertificate / TrustServerCertificate?

Julie 220 Reputation points

2025-08-22T10:57:47.8466667+00:00

Thank you so much for the clarification :)

Does this also mean the private DNS zone must be named privatelink.database.windows.net in order for Private Endpoints to work correctly? Or is there a recommended best practice on how to set this up when we also want to synchronize with our on-premises DNS zone?
Ravi Varma Mudduluru 11,075 Reputation points Microsoft External Staff Moderator

2025-08-22T14:51:35.14+00:00
Hello @Julie,

Hope you're doing well!

Yes, the recommendation by Microsoft when setting up private endpoints for Azure SQL Managed Instance is to name the private DNS zone privatelink.database.windows.net. This helps maintain compatibility with Azure's internal DNS resolution processes and also makes it easier to integrate with other Azure services.

Recommendations

Allows automatic DNS resolution of private endpoints and prevents conflicts with Azure's default backend DNS.

Ensures the SQL client resolves the Fully Qualified Domain Name (FQDN) correctly.

Note: Using a custom DNS zone name may result in resolution issues, even when the private endpoint and the managed instance are in the same virtual network (VNet). In that case, Azure may fall back to its backend DNS, ignoring your custom DNS configuration.

To ensure smooth connectivity and DNS resolution both in on-premises and in Azure environments, follow these best practices:

If you want to synchronize with on-premises DNS: Use DNS forwarders to pass queries from your on-premises DNS to Azure’s private DNS zone. Ensure you're on-premises DNS can resolve the public FQDN of the managed instance. Avoid overriding Azure’s internal DNS resolution for SQL MI, as this could break connectivity. Please refer to the public documentation below for guidance on on-premises DNS.

If you want to use Azure Private DNS Zones: Create a private DNS zone named privatelink.database.windows.net and link it to the VNet hosting the SQL Managed Instance. Azure will then automatically register the required A-records for the private endpoint.

Supporting Documents:
Azure Private Endpoint DNS Integration Scenarios | Microsoft Learn
Resolve private domain names - Azure SQL Managed Instance | Microsoft Learn

Kindly let us know if the above helps or you need further assistance on this issue.

Please "up vote" if the information helped you. This will help us and others in the community as well
Ravi Varma Mudduluru 11,075 Reputation points Microsoft External Staff Moderator

2025-08-26T14:11:25.6066667+00:00

Hello @Julie,

Hope you're doing well!

Did you get a chance to review our last response? We just wanted to check if you’ve had the opportunity to go through the previous post.

Looking forward to your reply. Much appreciate your feedback

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Answer accepted by question author

0 additional answers

Your answer

Julie 220 Reputation points

2025-08-22T10:57:47.8466667+00:00

Thank you so much for the clarification :)

Does this also mean the private DNS zone must be named privatelink.database.windows.net in order for Private Endpoints to work correctly? Or is there a recommended best practice on how to set this up when we also want to synchronize with our on-premises DNS zone?
Ravi Varma Mudduluru 11,075 Reputation points Microsoft External Staff Moderator

2025-08-26T14:11:25.6066667+00:00

Hello @Julie,

Hope you're doing well!

Did you get a chance to review our last response? We just wanted to check if you’ve had the opportunity to go through the previous post.

Looking forward to your reply. Much appreciate your feedback

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Answer 1

Hello @Julie,

Hope you're doing well!

Thanks for reaching out to Microsoft Q&A.

When you connect to an Azure SQL Managed Instance using a private DNS zone, the TLS certificate you get from Microsoft only includes the public service name (the public fully qualified domain name or FQDN). It doesn’t include any private or custom DNS names you might have set up. This is how it’s designed.

Microsoft manages these TLS certificates for all SQL Managed Instances centrally to keep things secure, compliant, and scalable. The certificates are issued for the public domain—that’s the domain everyone uses, like *.database.windows.net. They don’t cover any private or custom DNS names customers might create.

If Microsoft were to include private or custom DNS names, they would have to make a separate certificate for every customer’s private DNS. In a cloud where many customers share resources, this isn’t practical or safe.

Here’s why private or custom hostnames aren’t in the certificates:

It would mean Microsoft has to create and manage certificates for every unique private DNS name, which is too complex and not secure for a shared cloud environment.
Certificates are the same across all Azure SQL services to keep security checks consistent and meet Microsoft’s strict policies.
Azure SQL Managed Instance always uses the public FQDN to verify identity. So even if you connect through a private endpoint or DNS alias, your connection has to use the public FQDN so it matches the certificate.

The TLS certificates are fully managed by Microsoft, and customers can’t upload or use their own certificates for the managed instance.

What Microsoft suggests when using a private or internal DNS name to connect:

Always use the public FQDN of the Managed Instance in your connection string, even if you’re using private endpoints. This makes sure the TLS certificate matches and the connection is trusted.
If you must use a private DNS name, configure your SQL client like this:
- Set HostNameInCertificate to the public FQDN.
  - Set TrustServerCertificate=True only if you trust the connection and want to skip hostname checking.

These settings let your client correctly verify the certificate using the public hostname, even if you connect with a private DNS name.

Supporting Documents:

Resolve private domain names - Azure SQL Managed Instance | Microsoft Learn

Connectivity architecture - Azure SQL Managed Instance | Azure Docs

SqlConnectionStringBuilder.TrustServerCertificate Property (System.Data.SqlClient) | Microsoft Learn

Kindly let us know if the above helps or you need further assistance on this issue.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Share via

Azure SQL Managed Instance TLS custom domain issues

0 additional answers

Your answer