Hello, Cloud Gurus, and welcome back for this lesson
where we're going to take a look at
Implementing Domain Name System Security Extensions
on Windows Server, more commonly known as DNSSEC.
Let's take a look at what we're going to cover.
First up, we'll take a moment to understand
why do we need DNSSEC?
What are the vulnerabilities associated
with DNS that we need into secure?
And then we'll do a demo
showing how you can implement DNSSEC using Windows Server.
Let's get started.
First, let's take a look at why we need DNS security.
When a DNS client requests
DNS resolution for a given domain name,
it will first check if it's in its cache.
And if it's not found there,
it will forward the request to configured DNS server.
The DNS server will check if it is authoritative
and if it is, it can respond.
There is no need
for the DNS server to validate the response.
But what if the server is not authoritative?
If the DNS server is not authoritative,
it will first check its cache,
if the record is not in its cache,
it will need to forward the DNS request.
When the DNS server is forwarding requests
to other DNS servers,
it's sometimes referred to as a recursive DNS server.
Well, that process will occur.
It will forward the request to the additional DNS server
and then send the request back to the client.
So why is that a problem?
Well, there are 2 ways this can be a problem.
The first is,
what happens if an attacker responds to the client,
instead of the DNS server responding?
Or, what happens if the attacker responds
to the first DNS server?
That entry could be cached
by the duration specified by the attacker.
DNSSEC hopes to solve this problem
by allowing DNS servers and DNS clients
to verify the authenticity
of the response using digital signatures.
A digital signature basically allows the client
or DNS server
to verify that the request hasn't been modified
or tampered with.
You won't need to know DNSSEC
in depth for the AZ-800 exam, but a basic understanding
of how it protects DNS and how to implement it is important.
Let's take a look at the most important components.
The first of these is a signed DNS zone.
The authoritative DNS server signs the zone.
Then you distribute the trust anchors,
sometimes referred to as trust points
to the non-authoritative DNS servers,
so they can validate the DNSSEC data.
And then finally, on the DNS client,
you can figure the Name Resolution Policy Table Rules,
which define which zones should be secured.
Now, if you're using Active Directory,
distributing the trust anchors
on DNS servers that are also domain controllers is easier
because you can distribute them using Active Directory.
And if your DNS clients are Active Directory domain joined,
you can distribute the security settings to them too.
Now there is a lot more to know about DNSSEC
than what I've covered here
but you won't need to know everything about DNSSEC
to be a good hybrid administrator
or to pass the AZ-800 exam.
Now let's take a look at a demo of implementing DNSSEC.
If we go back to our demonstration environment
where we have our internal network and our external network,
we have an internal DNS server
hosting corp.barrierreefaudio.com
and we have an external DNS server
hosting barrierreefaudio.com.
In this demo,
we're going to sign the external parent domain
and then we're going to distribute the trust anchors
to the internal DNS server
and then we'll configure the Name Resolution Policy Table
on the client to require DNS signing.
Let's take a look.
All right,
So here we are logged onto our ADM 01 server,
which will serve as the DNS client for this demonstration.
We're going to use PowerShell to test DNS name resolution.
Go ahead and launch PowerShell
and we'll use the Resolve-DNSName PowerShell commandlet.
Now I've created a test record in the external DNS zone,
so I'm going to go ahead and use that record
for testing name resolution
and then I'm going to use the dnssecok parameter
to tell the DNS server,
that the DNS client that I'm using is DNSSEC capable.
Now this doesn't enforce DNSSEC,
but if the server was returning a signed response,
we would get that signed response.
Now this client is pointing to our internal DNS server
and we can see
that we've received a standard unsigned DNS response
from our internal DNS server.
Now the first step in implementing DNSSEC
is to sign the zone.
Let's go to our external DNS server and sign the zone.
Here we are on our external DNS server. We're
going to go ahead and launch the DNS Management console.
We'll double click the server
and we'll double click our Forward Lookup Zones
and then we'll right-click the zone
and we'll select DNSSEC
and then we'll select to Sign the Zone.
We'll get a little bit of a welcome message here,
explaining why you would implement DNSSEC.
Let's go ahead and click Next.
Now you don't need to have a deep understanding
of all the cryptography that goes in the backend of DNSSEC
to be a good hybrid administrator
or to pass the AZ-800 exam.
So we're going to sign the zone with the default settings
and then we'll go ahead and click Next.
We can go ahead and click Next again.
Now that the zone has been successfully signed,
we can go ahead and click Finish.
All right, with the zone successfully signed,
the trust anchors sometimes referred to as trust points
have been copied into the System32 directory of this server.
Let's go ahead and navigate to that directory
and we'll copy those trust anchors,
which we need for the second step,
which is to distribute those trust anchors
to our internal DNS server.
So we'll navigate into Windows Explorer
and we'll navigate into C>windows>system 32,
and then the DNS folder.
Now we have 2 trust anchors created here.
We're going to go ahead and copy the keyset-trustanchor
and then we're going to jump over to our internal DNS server
and copy that file across.
Here we are on our internal DNS server,
we're just going to launch File Explorer
and we'll create a folder and paste in the trust anchor
so that we can import them using the DNS console.
We'll go ahead and create a new folder
and then we'll paste in the trust anchors.
All right,
now that we've copied across the trust anchors,
let's go ahead and import them using the DNS console.
We'll navigate into Administrative Tools
and then DNS.
We'll expand the DNS server.
We'll select Trust Points
and then we'll import the trust anchors.
We're using DNS key.
We'll browse for the file that we copied across
and then we can select OK.
All right,
with the trust anchors has successfully copied
to our internal DNS server,
we can now go and configure the Name Resolution Policy Table
on our DNS client.
Let's jump over to our DNS client, which is ADM 01.
All right, so here we are back on ADM 01.
Let's go ahead
and configure the Name Resolution Policy Table.
To do that, We're going to use gpedit,
which allows us to edit the local policy on this computer.
Now, if you were using Active Directory
and this computer was domain joined,
you could use group policy to distribute these settings
to your DNS clients,
but because this computer is not domain joined,
we're going to use the local policy editor
to configure the Name Resolution Policy Table.
We'll go ahead and launch the gpedit.
I'm just going to expand this window
to make it a little bit easier to see.
All right, now in the local policy editor,
we need to navigate
to Computer Configuration > Windows Settings
and then Name Resolution Policy.
Now we can go ahead and add a rule
to our Name Resolution Policy Table.
To do that, we first need to provide the DNS suffix
and for our purposes,
that's our external DNS zone that we've signed.
So we're going to go ahead and provide that DNS name
and then we're going to go ahead
and enable DNSSEC for this rule.
And then we're going to require
that this DNS client checks the response
has been secured using DNSSEC.
And then we can click Create to add the rule
and then we need to scroll down to the bottom
and with our rule added,
we can now go ahead and Apply the network policy table rule.
All right, with the Name Resolution Policy Table applied,
let's go ahead and confirm that the rule is active
using PowerShell.
We'll launch PowerShell
and we're going to run the Get-DNSClientNRPTRule cmdlet.
to verify that the rule is active.
And we can see that the rule is active for our
barrierreefaudio DNS zone.
Let's go ahead and test name resolution using DNSSEC.
We'll press up to get back to our previous command
and we'll run the Resolve-DNSName commandlet again,
requesting a DNSSEC secured response.
And we can see
that our DNS server has returned a response
signed by DNSSEC.
All right, that concludes this demo.
Let's wrap up with a bit of a summary
of what we've covered in this lesson.
So what have we covered in this lesson?
DNSSEC allows you to sign the zone
on an authoritative DNS server and allow other DNS servers
and DNS clients to validate the responses.
Trust anchors, sometimes referred to as trust points,
must be distributed on the recursive DNS server
and that's the server that your DNS clients are pointing to.
It's also important to remember
that the Name Resolution Policy Table rules
must be configured on the DNS client to enforce DNSSEC.
And finally, active directory
can be used to distribute both trust anchors
and Name Resolution Policy Table settings.
All right, that wraps up this lesson.
Thanks for being with me
and I hope you found this useful
and I look forward to seeing you in the next lesson.