0

Looks like VNet integration for Azure SQL Server breaks as soon as the VNet is connected to a private DNS service and that SQL Server has a private endpoint in a different VNet.

The problem starts appearing under following conditions:

  1. App Service and SQL Server connect via VNet integration
  2. SQL Server is exposed via private endpoint in some other Vnet
  3. A private DNS is deployed on the VNet to provide connection to another SQL Server

Consider the following deployment:

2 apps and sql servers deployed in two regions with 1 private endpoint

Here two copies of the app are deployed in separate regions. They are able to connect to SQL Servers in their regions via VNet integration. Also app-service-2 is able to connect to sql-server-1 (cross-region) via private endpoint. That connection requires private DNS deployment to vnet-2. At this point it all works fine.

Now let's add another private endpoint to allow app-service-1 connection to sql-server-2:

2 apps and sql servers deployed in two regions with 2 private endpoints

What I observe at this point is that both SQL Servers become unresolvable by DNS in their corresponding VNets. They are still available via private endpoints cross-region, as well as via internet. Only inside a VNet that has some private DNS configured SQL Servers become unresolvable other than with their private DNS.

I have not found any mentions of that behavior in the documentation. Also the portal shows SQL Server as available via VNet integration, despite the situation being opposite.

  1. Is that some bug in Azure or am I missing something important here?
  2. Can I make SQL Servers available to apps in the same region, other than via another private endpoint?

Edit:

Here are some more scenarios of DNS resolution failures and successes:

More scenarios

  1. DNS resolution for SQL Server with a private endpoint still works from the internet.
  2. DNS resolution for SQL Server with a private endpoint still works from a VNet that doesn't have Private DNS deployed (same as on the first picture)
  3. DNS resolution for SQL Server with a private endpoint fails from a VNet that has Private DNS attached, regardless of private endpoints in that VNet.

DNS resolution for SQL Server without a private endpoint works fine from everywhere.

Arthur Stankevich
  • 372
  • 1
  • 4
  • 11
  • are you using the saame private dns zone ? are your vnet peered ? – Thomas May 08 '23 at 19:18
  • @Thomas private DNS zones are different, VNets are not peered – Arthur Stankevich May 09 '23 at 06:36
  • you have two sql server => is it geo replication ? – Thomas May 09 '23 at 07:17
  • Also can you share the prviate dns zone config ? – Thomas May 09 '23 at 07:22
  • @Thomas Yes, SQL Servers are in a failover group. FWIW at failure they become unresolvable via both SQL Server name and failover group name. – Arthur Stankevich May 09 '23 at 10:13
  • As for private DNS zone config, I don't have it anymore, but it was the default config created when creating a private link. I'm also updating the question with more scenarios to make it hopefully easier to isolate the issue – Arthur Stankevich May 09 '23 at 10:22
  • How about not mixing VNet Service Endpoints and Private Endpoints? Start with each subnet having a Private Endpoint for its local SQL Server, then add a Private Endpoint for the remote SQL Server. – David Browne - Microsoft May 09 '23 at 11:03
  • @DavidBrowne-Microsoft it works with just private endpoints and VNet integration. My intention though was to avoid unnecessary private endpoint for services located in the same region. I don't understand why it shouldn't be able to work that way – Arthur Stankevich May 12 '23 at 12:03

1 Answers1

1

I tried to reproduce the same in my environment I got the results successfully like below:

Created two app services with different regions East us and East us2 like below:

App service 1:

enter image description here

App service 2: enter image description here

Created a virtual network with different address space and separate regions like below:

Virtual network 1: enter image description here

Virtual network 2: enter image description here

Now, created SQL database & SQL server with East us and East us2 like below:

enter image description here

enter image description here

In SQL server -> networking -> private endpoint -> created private endpoint as the same region if App service and SQL are in Eastus created private endpoint with East and same App service and SQL are in East us2 create a private endpoint with EastUS2 like below:

enter image description here

I agree with Thomas Ensure that sql server is in geo-replication and try to peer vnet like below:

enter image description here

Now, when I try to check in the console to connect my app service with SQL server it connected successfully like the below:

App service 1 connected with both the SQL server with different regions like below:

enter image description here

App service 2 also connected with both the SQL server with different regions like below:

enter image description here

Additionally, On Remote desktop I try to validate the connection using nslookup it executed and I try to connect with SSMS it connected successfully like below:

enter image description here

Imran
  • 3,875
  • 2
  • 3
  • 12
  • 1
    Thank you for the detailed instruction Imran. I managed to set this up with just private endpoints and VNet integration. Although my original intention was to avoid unnecessary private endpoints in the same region and just use service endpoint, looks like it just doesn't work like that. – Arthur Stankevich May 12 '23 at 12:05