Azure SQL Server VNet integration fails as soon as private endpoint is created

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:

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:

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:

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.

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:

App service 2:

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

Virtual network 1:

Virtual network 2:

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

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:

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

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:

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

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: