Last thing I want to review with you briefly is the
concept of DNSSEC and how that works just,
again, from a relatively high point of view.
Though, boom,
you probably noticed a couple things change on screen just a
moment through the magic of video editing.
I've created another zone here that I can work with
called signed.lan. By the way, in terms of just architecture,
you notice that I'm using a .com even though this is a private
internal DNS domain. Again, that brings up questions.
Some businesses will always use a non‑internet routable TLD, or top‑level
domain, to make sure that internal resources have no possibility of
resolving on the internet. To that point, or as a nod to that, I've created
a new zone here called signed.lan, and I'm going to create a new host record
for my machine, dc10, where the IP address is 10.10.10.10, add that host in
there. And then let me show you just a bit about DNSSEC. So, let's
right‑click the zone, DNSSEC will sign the zone.
This launches the DNSSEC signing wizard. I'm going to leave the
default customized zone signing parameters.
We create a key master.
That's going to be this server.
However,
if we've already got a key master and we're signing a zone on another server,
we would browse to that server using the second radio button.
Let's create our key signing key. It says that the private key corresponding
to our KSK will sign other keys used for signing the zone.
So this is like a database key or a master key.
I'm going to click Add, and I'm going to accept all of the defaults here
in terms of cryptographic algorithm and key rollover.
So, let me click Next.
Next we have our zone‑specific private key. Click Next. Again,
we're going to add a key pair here as well.
And again,
the notion of trust anchors is we're going to need to distribute
the public key to other servers. In order to support
authenticated denial of existence, we'll use NSEC3, and again
I'm going to use the defaults here.
We definitely want to enable the distribution of trust anchors for the zone.
It says if this machine is also a domain controller,
all of those DCs in the forest will receive the trust anchor and
we want to automatically update those trust anchors when we roll
over or regenerate our private key.
Again, I'm going to use defaults here and then click Next.
The zone has been signed.
Good deal.
So now we have a node here for Trust Points. Now, because I told
DNS Manager to make the trust point available,
it's already brought those DNS key entries in. The way that you can
manually import your trust point is you can right‑click and do an Import,
DNSKEY, and you'll want to go to the server that has the trust point in
C\Windows\System32, and the trust anchor file has the name keyset‑, and
then the name of the zone.
All right. So that's that.
And then lastly, we can establish our DNSSEC policy in Group Policy.
I've created a separate GPO called DNSSec Policy, and if we
go under Computer Configuration, Policies,
Windows Settings, Name Resolution Policy,
we can create our Name Resolution Policy Table, which you see I have one
entry in here already. And basically to create a rule,
you specify which part of your namespace the rule applies to. And I
created one for the whole domain, that's pretty broad. Notice that you
can specify FQDNs, subnets, any, so you can be as specific or as broad
as you want for that domain.
So I might call this signed.lan. And then lastly, we're concerned
with the DNSSEC tab. Notice that you can do some things over here
regarding direct access and so on.
But the option is Enable DNS sec in this rule, and then you can specify
required DNS clients to check that name and address data has been validated by
the DNS server. And then optionally, you can layer in IPSec encryption. So you
can really get pretty heavy handed with your both verification, your
validation, as well as your confidentiality.
IPSec, as you know,
can cover not just confidentiality, but it can do mutual authentication
itself. And then when you're ready, you can create that record in your
Name Resolution Policy Table and then apply,
don't forget to hit Apply, and then it's just a
question of updating your Group Policy,
doing a GP update, to put that into effect.
And lastly, in terms of testing this, let me open up an elevated
PowerShell session, and we can use the Resolve‑DnsName cmdlet, and
notice what I'm doing here. I'm saying ResolveDnsName
dc10.signed.lan, the server that I'm querying is dc10, and I want to
see the DNS security records, ‑dnssecok.
And this gives us the A record which maps correctly to our 10.10.10.10
IP address, but what we want to see here is that RRSIG, that signed
resource record that verifies that that record did in fact come from
the server and it's a valid record.
There's another cmdlet that you might want to look at in terms
of validating your DNSSEC Name Resolution Policy Table, and
that's Get‑DnsClientNrptPolicy.
Now there's nothing on this machine.
I haven't yet updated my Group Policy on this machine, but this
is a nice way to verify that a machine is set up to require validation of responses from your DNS.