Now let's take these Windows Server DNS features and see
how they translate into Microsoft Azure,
specifically the Infrastructure as a Service, or
IaaS, scenario with virtual networks.
Here's a really nice diagram from Microsoft Learn. As always, when I
show you nonoriginal art I provide a citation.
You can see that in the lower left corner of the slide.
So here we're seeing a hybrid cloud environment where we've got an on‑premises,
let's say an Active Directory domain, and therefore we have DNS servers
that are authoritative for that domain. It looks like we have an
ExpressRoute link into a hub virtual network.
This just as well could be a site‑to‑site virtual private network.
It's just going to be a way to extend our on‑premises infrastructure at
OSI layer 3 into our hub virtual network infrastructure.
Now what's happening here?
Well,
in this case it looks like we have our local
on‑premises DNS servers configured for,
I would say, conditional forwarding to go out into
the virtual network in the cloud.
Now,
you could do that if the DNS servers in the cloud were in another
domain. You wouldn't necessarily need to do that if you are just setting
up additional domain controllers in the cloud.
See, so much of this branches in so many different ways.
This example here is showing that on‑prem, if somebody runs a DNS query
for a resource that's in Azure on its own DNS zone,
we need some way locally without going over the
internet to get into that virtual network.
So again, that's what DNS conditional forwarding is all about.
If we're looking for azureprivatenetwork.com,
if that's our zone in Azure,
we would do a conditional forwarding entry for that, and that would bring you
into Azure where you've got an authoritative DNS server VM there that is
resolving private IP addresses within your virtual network infrastructure. Now,
I'll show you more about this in the demo, but this is where things can get more
complicated. We have to remember that virtual networks are completely isolated
from each other by default.
So that means Azure‑provided DNS, or Azure‑provided name
resolution, will not work across virtual networks.
So the idea is that you can do your own DNS solution, but you'll have to
configure forwarding across those VNet peerings. In this case this shows VNet1
and VNet2 with a peering connecting them. And a peering is just a logical,
back‑end routing path between two virtual networks.
All right, it doesn't imply any encryption,
you could also, if you wanted to, do a VNet‑to‑VNet VPN, but the
normal pattern is to link those VNets via a peering and then you
can configure conditional forwarding,
let's say, if you have yet another domain running in VNet2.
Now, what's this 168.63.129.16 stuff? That's a virtual IP
that you should be aware of.
It uses AnyCast, so it's available to all Azure public cloud customers
and it represents the Azure‑provided services called the wire server,
and this is what gives you your DHCP, or Dynamic Host Configuration
Protocol, within your VNets.
And also, very importantly, when you're doing Azure‑provided name resolution,
it handles that within each VNet. Now, that wire server can also come into
play big time when you're integrating with Azure DNS,
particularly private zones and things like private endpoints that we'll get into next.