In this demonstration, you will implement DNS security within the environment.
You will work from the domain admin machine and you will secure the DNS zones between the primary DC
and DC two.
Let's look at the current DNS zones which reside on the domain controller, and you will do this by
navigating to tools DNS and connecting to the DC and the forward lookup zones.
You'll notice that we have the normal company DOT primary forward lookup zone and we've got another
one which is section company DOT Primary.
You need to implement DNS security on the section company DOT primary zone.
To get started, you'll right click on the zone and under den sec.
You'll click on same the zone.
You'll click on next to go through the wizard and you have a few options.
You can go and use an existing zone for the parameters.
You can use the default settings to sign the zone, or you can customize the zone sign and parameters.
Let's go ahead and customize it so we can see the options that are available.
You'll click on next and you will choose the key master.
Since the DC is the primary domain controller and authoritative DNS server, we will keep DC as the
key master.
You'll click on next and now it will bring you to the key signing key.
Let's proceed under key sign in key.
You have the ability to add multiple algorithms.
You'll click on ADD and you have the ability to customize the grid in your key generation signing keys,
key properties, and the key rollover.
Since we do not have any pre generated keys, let's go ahead and create a new signing key.
Under the cryptographic algorithm, you have a number of choices that you can select.
So we will stick with S-H are two, five, six the key length.
We will leave it 248 bits and we will leave the key storage provider as the Microsoft software key storage
provider.
You have a few options that you can select, but we'll leave the defaults for now.
The signature validity period you can configure as well as the key rollover.
So we will leave these as the default.
You can of course tweak this to enable a quicker rollover period and a shorter validity period.
So we'll click on Okay and you will click on next.
Now you have the ability to define the zone signing key, which is essentially the authentication key
to sign the zone data you'll click on next.
And again, you have the ability to add multiple algorithms for the zone signing key.
We will leave these as defaults and click on okay, you'll click on next and now you have the ability
to choose the next secure version that you want to use for the resource records.
Let's use next secure version three.
And you also want to enable the distribution of trust anchors for the zone.
This ensures that the trust anchors are distributed to all DNS servers, which are running on domain
controllers within the forest.
Since our forest has two domain controllers and both of them are DNS servers, this will automatically
distribute the trust anchors.
So now you'll click on next and you can configure the signing and polling periods which we will leave
as the defaults for now and we'll click on next and complete.
Now you'll notice that there is a lot next to the DNS zone and this depicts that the zone has been secured
with DNS security.
Here we have the resource record signatures and the DNS keys as well as the various trust anchors that
are showing.
After a couple of minutes, replication will take place and the configuration settings for the same
DNS zone will be replicated to DC two.
Let's take a look at DC two, will connect to it and under forward lookup zones you'll notice that the
security accompanied DOT primary zone is now also secured and we have the trust points which are reflecting
in the secondary DNS server.
Now we will open up PowerShell and verify the dense SEC is working.
Let's first perform a query on the normal company DNS zone to see the difference between a query on
a normal zone and the query on assigned zone.
And you will issue the command result DNS name followed by the host record specifying the server and
will perform the dense SEC check.
Now let's perform the exact same command, but this time we will specify the zone which is protected
with DNS security.
Notice the output difference between the two in the first output, we simply add the record response
with no additional data.
In the second one, we can see now we've got the same date who signed the record and of course, the
cryptographic signature.
Now let's validate if we have an NP policy on the client machines.
And in our policy, which stands for a name resolution policy table, enables you to enforce name resolution
policies on security aware DNS clients to verify if there are any policies in place.
You can issue the command, get DNS client in our policy and right now you'll see there are no policies
enforced.
Let's go ahead and create this policy so that we can ensure the dense SEC is being used within the environment.
To do this, you will navigate to group policy management, and under group policy objects, you will
create a new group policy and we'll call this den sec.
You will go ahead and edit this policy.
And under computer configuration policies, window settings, name resolution policy, you will go ahead
and configure a new policy in the Create Rules section.
Under suffix, you will define the dense EC protected zone and you will go ahead and enable den sec.
In this rule you can require validation and if you want to enforce IP set communication, you can enable
this as well.
Bear in mind that there might be some additional configuration options required for IP seq.
So for now we will leave this disabled.
You will click on Create.
Another rule has been created.
We will apply this and now we will go ahead and link this group policy.
Since we have the admin workstation, which resides in its own view, let's go ahead and link the den
SEC policy to the EU.
And now you will force a group policy update so that the new group policy with the DNS policy can be
applied.
Once the update has completed, we'll switch back to the PowerShell window, an issue to get DNS client
in our policy command again.
And this time you'll notice that we have a policy defined and under DNS as a CE validation.
The value is now set to true.
This will ensure the client's use den sec.
When performing DNS lookups, we will perform a query again to ensure that we have not broken anything.
I rerunning the dense query, we can confirm that the results are the same as before the validation
was required.
This confirms that that policy that we have just applied has not broken anything in relation to dense
queries.
You can confirm that the secondary DNS server, which resides on DNS two, is also using dense EC by
issuing the same command but changing the server name.