DNSSEC works by combining public key infrastructure (PKI)
cryptography with DNS to use digital signatures and cryptographic keys
to sign DNS zones and validate that DNS responses are authentic. Figure 1 shows the steps involved in the
name-resolution process when DNSSEC has been implemented in a Windows
Server–based network. The basic steps involved are as follows:
-
A client such as a Windows 8 computer issues a DNS query to
its local DNS server. -
The client’s local DNS server has DNSSEC enabled but is not
authoritative for the zone being queried, so it issues a recursive
query to the authoritative server for the zone to request an
authoritative response. -
The authoritative server has DNSSEC enabled and is the
authoritative server for the zone being queried. This means that
the zone has been digitally signed on this server. When the
authoritative server receives the recursive query, it returns an
authoritative response to the client’s local server. This response
includes one or more DNSSEC resource records, which can include
the following types:
-
Resource Record Signature
(RRSIG) These resource records contain digital
signatures for all records in a zone. -
DNS Public Key (DNSKEY)
These resource records contain the public keys for a
particular zone. -
Delegation Signer (DS)
These resource records indicate the public key for a child
zone. -
Next Secure (NSEC or
NSEC3) These resource records allow the validation of
a negative response.
-
The local server uses the public key of the signed zone on
the authoritative server to validate the response it received from
the authoritative server. -
The local server returns the requested response to the
client that issued the query. The client can now access the
network resource represented by the name it was querying
for.
Deploying DNSSEC using Windows Server 2012 into an existing
Active Directory environment involves performing the following
steps:
-
Begin by introducing Windows Server 2012 domain controllers
into your environment. These domain controllers should also have
the DNS Server role and be configured to use Active
Directory–integrated zones. -
DNSSEC is implemented by signing zones on your DNS servers.
After deciding which DNS zone to implement DNSSEC on, sign the
zone by opening the DNS Manager console, selecting the DNS server,
right-clicking on the zone, and selecting DNSSEC, followed by Sign
The Zone:
-
Follow the prompts of the Zone Signing Wizard to complete
the process of signing the zone. The simplest approach is to use
the default settings to sign the zone:
For example, selecting this option when signing the
corp.contoso.com zone on your first Windows Server 2012 domain
controller DC-1.corp.contoso.com would have the following
results:
-
The domain controller becomes the key master for the
corp.contoso.com zone. The key master is
the DNS server that generates and manages signing keys for a
zone that is protected with DNSSE -
A key signing key (KSK) with a length of 2048 bits is
generated using the RSA/SHA-256 cryptographic algorithm. The
KSK is an authentication key that signs all of the DNSKEY
records at the root of the zone, and it is part of the chain
of trust. By default, the KSK has a rollover frequency of 755
days, and any DNSKEY records signed using the key have a
signature validity of 168 hours. Key rollover and signature
refresh are enabled by default on Windows Server 2012 DNS
servers. -
A zone signing key (ZSK) with a length of 1024 bits is
generated using the RSA/SHA-256 algorithm. The ZSK is used to
sign zone data, such as the SOA, NS, and A resource records
found in a typical zone. By default, the ZSK has a rollover
frequency of 90 days, and any zone resource records signed
using the key have a signature validity of 240 hours. Key
rollover and signature refresh are enabled by default on
Windows Server 2012 DNS servers. -
NSEC3 is used by default for providing authenticated
denial of existence. The NSEC3 hash algorithm used is
RSA/SHA-1 with 50 iterations and a salt length of 8. -
Trust anchors are not distributed. A trust
anchor is a preconfigured public key associated
with a specific zone. The trust anchor enables DNS servers to
validate DNSKEY resource records for the corresponding zone
and establish a chain of trust to child zones, if any exist.
Validating DNS servers must be configured with one or more
trust anchors in order to perform DNSSEC validation. If the
DNS server is running on a domain controller, trust anchors
are stored in the forest directory partition in Active
Directory.
-
If the zone you signed is an Active Directory–integrated
zone, private zone-signing keys now replicate automatically to all
domain controllers hosting the zone through Active Directory
replication. Each zone owner signs its own copy of the zone when
it receives the key, as long as the zone owner is a domain
controller running Windows Server 2012.
Most of the key-management process is automated for DNSSEC
in Windows Server 201. After the key rollover frequency has been
configured for a zone using the Zone Signing Wizard, the key
master automatically generates new keys and replicates via Active
Directory. The zone owner rolls over keys and re-signs the zone,
and secure delegations from the parent are also automatically
updated within the same forest. -
At this point, the zone has been signed and contains the
necessary RRSIG, DNSKEY, DS, and NSEC3 resource records to support
DNSSEC validation:
-
When zone data is updated by a client sending a DNS dynamic
update to an authoritative DNS server, that DNS server updates its
own copy of the zone and generates the required signatures. The
unsigned update is then securely replicated to all other
authoritative servers, and each DNS server adds the update to its
copy of the zone and generates the required signatures. -
Trust anchors must then be distributed to the DNS servers in
your environment to enable the DNSSEC validation process to be
performed by nonauthoritative (recursive or caching) DNS servers.
If the DNS servers are running on domain controllers, trust
anchors are stored in the forest directory partition in Active
Directory and are replicated to all domain controllers in the
forest. On standalone DNS servers, trust anchors are stored in a
file named TrustAnchors.dns and can be manually imported to these
servers using the DNS Manager console or Windows
PowerShell.
For example, the standalone DNS server running Windows
Server 2012 shown next displays its configured trust anchors in
the DNS Manager console tree in the Trust Points container. Note
that two DNSKEY trust points are displayed: one for the active key
and one for the standby key.
-
Trust Anchor updates are then automatically replicated via
Active Directory to all servers in the forest, and automated Trust
Anchor rollover is used to keep trust anchors up to date. -
The final step in deploying DNSSEC is to ensure security
between the nonvalidating DNS client (which can be computers
running Windows 7, Windows 8, Windows Server 2008 R2, or Windows
Server 2012) and their local DNS servers. The recommended way to
do this is to use IPsec to protect the last mile between the
client and its local DNS server. The DNS clients must also be
configured to check that responses have been validated by their
local DNS server, and this is done by configuring the Name
Resolution Policy Table (NRPT) on the clients. The NRPT is a table
that contains rules you can configure to specify DNS settings or
special behavior for names or namespaces. The NRPT can be
configured by using either Group Policy or Windows
PowerShell.
|
