Now Azure DNS has two forms.
There's Azure DNS for public zones and Azure DNS private zones.
The public zone is where you can delegate your domain into Azure.
You can't yet buy a domain in Azure,
but you can delegate your domain from where it's hosted into Azure
and then manage that domain with its internet‑accessible resource
records within your Azure subscription.
It's very convenient.
Now on the other hand,
an Azure DNS private zone uses RFC 1918 non‑internet routable IPs,
and it has some nice conveniences.
For example, as you can see in this diagram,
being able to do fully qualified names with your virtual machines across VNets,
whether they have a peering or not.
On best cases they do have a peering.
But this gives you that ability using all private IPs and staying on the
Azure backbone network to do that fully‑qualified domain name resolution
without relying on that Azure wire server.
Which as I said, I just want to keep repeating,
and I'll show you again yet in the demo,
the wire server can only handle name resolution within a single VNet.
And even at that frankly, it's single label name resolution.
It's nothing special.
Going a bit further yet again,
I want to be careful to not get too far in the weeds here,
the private endpoint is a way to create a back channel that uses private IP
addresses to Azure services that are in the internet by default.
So in this example,
let's say we created a private endpoint connection for
an Azure SQL Database virtual server,
and those always have internet‑resolvable DNS,
like azsql1.database.windows.net.
When you create a private link or a private endpoint,
notice that Azure gives a private IP address to that resource within your
virtual network space wherever you want to create it.
In this case, it's in the snet‑consumer subnet.
And that means that that DNS forwarder is on the same subnet and,
therefore, can communicate with that database server using
private non‑internet routable addresses.
Well,
the name resolution here is where things get interesting because under the hood,
private endpoint is where Azure creates basically a split
horizon scenario where you're always referencing that private
link resource on its public DNS.
But depending upon where the query originates,
it's either going to connect over the internet or on the private link.
So in this example, we've got a Client VM.
Now if Client VM is trying to make a connection to
azsql1.database.windows.net using that name in the absence of forwarding,
then the private endpoint would not be used and the
connection would happen over the internet.
In order to ensure that Client VM uses the private link,
we need a way for that Client VM on‑prem to resolve
the private link private IP address.
So this is a rather complicated example.
You would have to configure conditional forwarding on‑prem in your DNS
such that calls to database.windows.net go to a VM that you've
configured as a DNS server in your virtual network.
That DNS server would be forwarding all of its traffic that it
can't resolve itself to the Azure wire server.
Why do you need that second hop?
Well, you don't if you don't have a hybrid cloud.
If you have an environment that would stop here at the snet‑consumer subnet,
those VMs can go directly to that resource.
Again, they would attempt to resolve the public DNS name.
And the Azure‑provided DNS endpoint knows about the mapping,
that split horizon mapping,
that when you're connecting to that name over the internet,
you go to the public endpoint,
but if you're connecting to the Privatelink endpoint,
you can fetch that,
or Azure‑provided DNS can fetch that mapping in a private DNS zone.
Now, you can create your own mappings with DNS.
I strongly recommend if you're going to do private endpoints,
go ahead and create the private DNS zone so you
have that alias record available.
Long story short, in summary,
to do private endpoint you always connect using its public name.
And in a hybrid cloud,
you need to take a little extra work in terms of conditional forwarding
because your on‑premises environment is not going to be able to
directly use the Azure‑provided DNS endpoint,
and you need that wire server to handle that split horizon translation.
I hope that makes sense.
I know it's super complicated.
Our lab topology here consists of two VNets that are connected with a peering.
I have dc10.
This is a domain controller for the contoso.com zone.
These private IPs are valid.
I have another domain controller in the same zone across the peering.
I also have another machine, a workgroup server, that's hosting its own domain.
And then, lastly, I have a storage account with a private endpoint in the hub.
So we're just going to look at various combinations and
permutations here of how we can get name resolution to work in this peer‑to‑peer virtual network environment.