Now in Windows Server, you can create just standard primary and secondary zones,
but we're not interested in that because we're assuming that you
have an Active Directory forest environment,
and so why not store your DNS zone information within Active Directory and
then replicate that zone data to other domain controllers.
You may be following Microsoft's best practice of making sure that all
of your domain controllers are also DNS servers.
When you have a domain hierarchy or maybe a multitree
domain hierarchy in your forest,
we know that DNS is how you do that name resolution and
we want to make sure that your domain controllers are
aware of each other's own data,
especially when you have multiple replica domain
controllers within a single domain.
You should know that in Active Directory there are a number of partitions,
application directory partitions, through which you can control replication
scope, and with Active Directory integrated DNS, the domain DNS zone's
application directory partition is what you want if you want to replicate
your DNS zone within the domain only.
And then there's a forest DNS zone partition that you can use to
replicate your zone throughout the entire forest.
It really depends upon your name resolution needs, how distributed your
environment is, etc. Another feature specific to Active Directory
integrated DNS zones is secure dynamic update, and what this means in a
nutshell is that you can put essentially access control lists on your
domain member devices such that they can only dynamically update their
resource records in the zone if they are in fact proven or authenticated
domain members.
This feature is to prevent rogue updates from happening in your zone.
DNSSEC stands for Domain Name System Security Extensions.
And that last word is important.
Actually, the last two words are important because that defines what DNSSEC is.
This is an extension to the DNS specification.
It's not a Microsoft proprietary technology.
It's an extension to DNS that provides security by
validating that query responses are genuine.
DNS historically is very ripe for attack.
I mean, by default your zone is unencrypted, we're talking TCP or even UDP port
53, it represents a vulnerability for your business, and the notion that there's
so many attacks, DNS cache pollution, there's man in the middle, there's
hijacking, how can you verify or how can you configure your DNS servers to
verify that the responses they provide for their zone data are in fact genuine?
Well, you do that through cryptographic signatures and asymmetric public/private
key encryption.
You need to know that when you sign a zone with DNSSEC and Windows Server DNS,
there are two resource records that you should be aware of.
RRSIG is the digitally signed record that verifies
authoritatively the existence of a record in the zone, and just
as importantly there's NSEC, which validates that the host
that's being queried for does not exist.
So it's an authoritative denial of existence as opposed to some hacker trying
to redirect legitimate DNS traffic to illegitimate sources.
You see what I mean? Now I mentioned this asymmetric key issue.
When you're dealing with public and private keys,
you distribute the public key to your clients and then you
validate with your private key on the server.
In DNSSEC terminology,
we digitally sign each DNS zone that we want to protect and
then we have to distribute trust anchors.
This is really the public key aspect.
We can do that in a number of different ways,
including populating the Name Resolution Policy Table, or NRPT.
Now if you're doing Active Directory integrated zones,
that's an easy way to make sure your trust anchors are at least
distributed to your domain controllers and then you can specify
for your clients that they have to use DNSSEC using Group Policy,
specifically, as I mentioned,
populating something called the Name Resolution Policy Table.
I'll go through some of this in a bit greater detail in the demo.
We don't need to get too into the high weeds here. I'm covering what you need to know about DNSSEC for your AZ‑800 exam success.