In this demonstration,
let's take a look at some select Windows Server DNS features. Now,
full disclosure, this Windows Server 2022 machine that we're on right now,
it's a domain controller named dc10.contoso.com, it is in fact
running in Azure. But we can just disregard that at this point
while we take a look at what's going on.
Now of course I've installed the DNS server role on
this machine. And you might wonder, well,
what do you do in terms of DNS for the server itself?
I'm going to open up good old ncpa.cpl, and I'm sure you're well
familiar with this routine of modifying the TCP/IP configuration of
your server. And so looking at the properties of our Ethernet
connection, now again I'm in Azure,
so I'm not setting a hard coded static IP here, nor am I doing a hard coded
DNS, but on‑prem, of course, you want to make sure that your DNS server
addresses start with the IP of the local server.
Again,
things change in Azure because, as I always recommend, you
should do your TCP/IP configuration from Azure,
not within the guest OS of the Azure virtual machine.
Now,
what do we need to review in terms of DNS management in Windows Server for our
AZ‑800 exam? Well there's a couple things. As you can see,
I have dc10 and dc11 loaded in here.
These are both domain controllers in the same domain. And speaking of
which, we've got our forward and reverse lookup zones.
And if we create a new zone,
let's just take a look at this for a moment, some of the
options, we can do primary, secondary,
this is old‑school DNS where we're not integrating or we're not
replicating our zone with Active Directory where you've got a
primary/secondary relationship between replicated servers.
Note that you can combine primary and secondary with Azure AD integration,
but normally with domain controllers we want to be authoritative for the zone.
Secondaries are not authoritative.
Stub is just a way to create a shortcut name resolution path.
This is relevant, for example, when you have a complicated multidomain,
multidomain tree hierarchy in your forest and you want to
create stub zones for some of those remote domains just to
shorten the name resolution iteration.
And again,
here's the Active Directory integration. And then
we choose our replication scope.
Notice that the options are To all DNS servers that are domain
controllers in the forest, all DNS servers that are domain
controllers in the domain, and then if you've created custom
application directory partitions, you can specify that as a last option.
We give the zone a name, and then we can choose our dynamic updates.
And if you're doing AD integrated, as I mentioned,
you want to allow only secure dynamic updates so that your client
devices need to be domain members in order to register,
modify, and unregister the resource records in the zone.
So, just wanted to review that. In my contoso.com zone I have just
the standard issue records, start of authority.
Let's take a look. If we go to zone properties, we
can browse some of those things.
For example, on the General tab we can change the replication scope.
This is that same dialog we saw before. We have our Dynamic
updates setting here, None, Nonsecure, and Secure,
or Secure only. We have our Start of Authority that gives you
your authoritative primary server, your refresh,
these are just your metadata, your client metadata.
Here's our authoritative Name Servers list. And then I think
that's all we need to worry about for that.
In terms of creating a new resource record,
we can right‑click and create any of those records.
I'm going to create an alias called app that actually maps to, I
can browse the zone file, the dc10.contoso.com.
Let me select that record. And this is going to allow me to
contact dc10 using the hostname app or I could just do
app.contoso.com. That's just an example of that.
Let's take a quick look at the server properties.
If we right‑click the server itself,
we can modify cache, aging, and scavenging of orphaned or old records.
If we go to Properties, this has some important options actually,
particularly we can make sure that the interface IPs that we
want associated with that zone are enabled.
I have my private IPv4 and IPv6 addresses. Forwarders, this is critical in
Azure particularly, so I don't want to say too much of it now,
but because this machine is an Azure VM, notice that I have the Azure
wire server endpoint, 168.63.129.16, as my forwarder.
This is critical because I want the server to be able to
resolve IPs from outside contoso.com, my private zone.
I still can use the root hints if no forwarders are available, and
you can even customize the root hints as such. All right.