In this demonstration,
I want to walk you through managing DNS for Windows Server VMs that
are running in Azure and then implications for when you need DNS to
work across not only peered VNets in Azure,
but also when you've got a hybrid cloud with an
ExpressRoute or site‑to‑site VPN connection.
As I mentioned earlier, let me minimize my browser,
I'm on a machine named DC10, and it is in fact running in Azure.
So you can see DC10 right here.
So let me click into it here and let's make sure we understand
what's going on in terms of TCP/IP addressing,
but particularly name resolution.
So if we go to the Networking blade,
we can review the full setup of this machine.
We can see the private IP address,
and you might be wondering how do we know at a glance whether this is a DHCP
dynamic address or if it's a statically assigned address.
That's a good question.
That happens at the network interface level.
But what we can do is click into that network interface.
All VMs will need at least one associated virtual network interface.
And if we go under IP configurations,
we can modify the default IP config for that machine,
right here.
So let's select ipconfig1.
Now let's ignore public IP addresses.
I normally advise against associating one of those.
I do have a use case for it here, but let's ignore that.
I want to focus in down here where we see that the virtual
network and subnet that this network interface are
associated with is vnet10/subnet10.
And I flipped the switch, actually,
from using Azure‑provided DHCP to static assignment to make
sure that this machine always has 10.10.10.10.
All right, so that's what's happening behind the curtain there.
Now if I step back to the network interface,
I want you to see that you can override Azure‑provided name resolution.
Notice that by default your network interface inherits DNS
from the settings on the virtual network.
So understand that.
We don't want to go into the network interface card properties on the VM,
that can be a tricky business.
Instead, we want to do our DNS server assignments,
in other words what DNS servers is the VM using through the
Azure Resource Manager control plane.
Though the most common pattern in my experience is to
configure your DNS option at the VNet.
So let's go to vnet10 in another browser tab,
and here we want to come down to the setting DNS servers where
again it defaults to Azure‑provided DNS.
Why would you want to switch this?
Any IP address you put in this array, and it is an array,
it appears to just be one, but when you add one,
it opens up another row, etc,
this is going to instruct the Azure wire server to distribute those IPs to
all VMs on that virtual network that may be too broad.
So again,
you've got the ability at the network interface level
to do an override if you need to, but this is what you want to do.
So if we wanted to join this Azure VM to our on‑premises domain,
assuming that you have a path like ExpressRoute or site‑to‑site VPN,
we would make sure to add our on‑premises domain controller IP addresses,
our private IP addresses,
to this list to make sure that my Azure VM knows
about and will use those servers.
Now a common question is if you do custom DNS,
do you need to create an entry for the wire server?
I haven't seen that hard coded in terms of the Microsoft Docs.
I'm a little bit superstitious sometimes,
so if I'm doing a custom DNS server list,
I will normally add the wire server at the end just to make sure,
no matter what,
that if a VM in my virtual network can't get a resolution using its
other DNS servers that we've provided in this array,
it will fall back to the wire server.
That's just there's so many different ways to do this.
I'm just presenting these different options as things for you to think about,
okay?
Now, what are the implications of doing default Azure‑provided DNS?
Well the main implication, let me open up my PowerShell and do an ipconfig all,
is that you get only single‑label name resolution within the VNet.
Why is that?
Well look at this.
In your virtual network, every resource is going to be on the bx,
I don't know about bx, that may be region specific,
but definitely internal.cloudapp,net.
We remember that all of our Azure VMs are on the internet by default.
And so what you've got is your DNS suffix is this GUID,
this globally unique type identifier for your VNet,
and all virtual machines in that VNet will have the same DNS suffix.
And this would mean on DC10 I could, on another VM in this VNet,
just do a ping dc10 and it would resolve to that.
In fact, let me try that.
Let me do a ping dc10.
Oh, well, I'm using custom DNS so it's overriding that,
but normally it would be dc10.blah.bx.internal.cloudapp.net.
Notice that my DNS server is looking to itself,
as well as the Azure wire server.
Again,
there's some complications there because it is a DNS server and
I have it configured to forward anything it can't resolve
directly to that wire server endpoint, okay?
But we can see that my default gateway,
it appears to be the first private IP address on the subnet,
that's the wire server, and notice that although I've got a static private IP,
my DHCP server is also the wire server.
Unless you're doing custom DNS,
you'll find that DNS defaults to the wire server address as well.
So,
this is going to give us name resolution if we do Azure‑provided
DNS only within the VNet because every VNet has its own suffix
and they're not connected by default.
Now that having been said, if I go in my VNet settings,
you can see that I've created a peering between vnet10 and vnet11.
So that does allow a routing path between those virtual networks.
And I have another virtual machine called DC11 that's running
across the peering in that remote network.
So again, I can test that by doing a cls,
I'll do a ping dc11.contoso.com, and I can resolve that just fine.
Now remember in the previous lesson where we looked
at this machine's DNS settings,
let me bring up the DNS management console really quick,
dnsmgmt.msc, just to refresh your memory.
I have this machine pointed to itself for DNS,
but it's configured with the Azure wire server address
as a forwarder just to make sure,
and we can adjust that forwarder list with edit.
And it says unable to resolve, that's because,
to the best of my knowledge,
there's not a customer‑facing FQDN for the wire server,
so it does connect, it's validated,
but Azure's not able to do a reverse lookup on it.
That's fine.
That helps us out quite a bit in terms of name resolution.
Lastly, let's take up the subject of conditional forwarding.
Let me switch over to another machine just to get our context here.
I'm on a machine named DC12, and if I bring up my DNS Manager,
I have a forward lookup zone called techtrainertim.com.
What if we want to ensure that we can resolve hostnames for
contoso.com on the other side of the peering?
This brings up conditional forwarding.
This is a topic that's very much an exam alert for AZ‑800,
and it comes into play in so many different contexts,
including the Private Link service that I mentioned a little
while ago in the lecture portion of this.
You might need to configure conditional forwarding on‑prem to an Azure
DNS server that then forwards to the wire server,
or in this case we're on a DNS server on one side of the
VNet peering and we want to set up that whenever we're
looking for a contoso.com address,
we're going to forward to a particular authoritative server in Azure.
So, let me show you how that works.
We right‑click the Conditional Forwarders folder,
select New Conditional Forwarder,
and then you specify the domain that you're looking for and then an IP address,
one or more IP addresses, that map to those servers.
Now I've already created one down here.
It's erroring out here, unknown error occurred.
The idea is your DNS server will attempt a reverse lookup on that IP.
Now don't be freaked out if it says unable to resolve for server FQDN.
If you don't have an inverse lookup zone or if the
destination server doesn't have a pointer record,
it's not going to be able to resolve the server FQDN.
But you do in fact want to validate that connection.
But what the conditional forwarder does at the end of the
proverbial day is that if a client of this server is looking
for a resource on contoso.com,
only in that context will the conditional forwarder come into play.
And in this case we go across the peering the one of the contoso.com DNS,
or I actually have a domain controller on this side of the peering,
it might hit that one as well,
but that's the idea with the conditional forwarder.
And that also, as I mentioned, comes into play with Private Link.
Let me give you an example.
I created a private link for the blob service of
one of my Azure storage accounts.
The storage account is twaz800stor1,
and when I did that I accepted the default configuration,
which will create an Azure DNS private zone that uses the
root of that public namespace by default.
In fact, I can quickly show you.
Here we are in my subscription,
and Azure created a private zone called privatelink,
and then it will be the namespace of the service.
So I created a private link for the blob service of a storage account.
So the private zone is privatelink.blob.core.windows.net.
And we can see that Azure created a private IP address
mapping down here that maps to twaz800stor1,
and that will be dynamically updated if that were to change in the account.
Again, we don't need to get too far into the weeds,
but how this impacts you is that you want to make sure that in the
network where you want to access the private link,
you can get to the Azure wire server.
And in my case I can, so I should have no problem.
If I do an nslookup against that name,
we get a nonauthoritative answer on that name.
And notice that in this case we're going over the public internet.
So what this means is that we are not on the subnet
that the private link is created on, so we're going to use the public name.
But what I want you to see here is that there's the alias for the public name,
internet name of the service, as well as the private one.
So, how does that factor in?
Well, if I come to a machine that's on the same subnet as the private endpoint,
I can do the same thing.
Let me clear the screen and do an nslookup on the public DNS name,
and in this case I'm coming directly on the private IP address of that server.
Please check the exercise files for more info on DNS
configuration for the Private Link service because it
definitely has a learning curve to it.
Microsoft Docs has a great article that will supplement the demo I just did for you.