DNS provides a user-friendly way of naming hosts and services on a
TCP/IP network. DNS servers perform name resolution to convert DNS names
into IP addresses so that DNS clients can access network services. DNS
servers thus play a critical role in enabling users and applications to
locate hosts and services on the network or on the Internet. However, no
authentication or integrity checking is done when name resolution is
being performed using traditional DNS. As a result, communications
between DNS clients and servers is inherently insecure, and by spoofing
DNS traffic or otherwise poisoning the DNS cache on clients, an attacker
could hijack network communications and redirect users and applications
to malicious sites and services.
To help organizations address this problem, Windows Server 2012
includes enhanced support for DNS Security Extensions (DNSSEC), a suite
of extensions that add security to the DNS protocol by enabling DNS
servers to validate DNS responses. In a practical sense, this enables
users to be confident that the site they are accessing on their
corporate intranet is in fact the site they believe it to be, and not
some malicious site masquerading as a legitimate site. This lesson helps
you understand the benefits of DNSSEC, how it works, and how to
implement it in an Active Directory environment based on Windows Server
2012.
DNS is used for locating resources on a TCP/IP network and the
Internet. For example, when a user types www.bing.com into the address bar of
Internet Explorer, the DNS client on the user’s computer sends a name
query request to a DNS server. The DNS server then either responds
with the IP address for the site being accessed (Bing) or forwards the
query to another DNS server for consideration. When the client has the
site’s IP address, it can access the site to download content.
But the question arises, how can the user or application be
confident that the site being accessed is genuine and not some fake
site masquerading as the real one? To a certain extent, the Secure
Sockets Layer (SSL) protocol already does this. SSL is used whenever
the user or application accesses a resource using Secure HTTP
(HTTPS).SSL does this by authenticating the site being accessed and
encrypting the data returned over the network. However, SSL is of no
use if the DNS server being queried returns a spoofed IP address
instead of the real one. This could be accomplished, for example, if a
malicious DNS server intercepted name-resolution traffic and inserted
a spoofed response to a query from a DNS client or a recursive DNS
server. And not only could such an attack hijack a particular DNS
session, it would also poison the local DNS cache on the client
server, recursive server, or both, which could lead to further
erroneous responses to name-resolution requests until the cache data
expired.
To address these issues, the Internet Engineering Task Force
(IETF) developed DNSSEC to add a layer of security to the inherently
insecure DNS protocol. Specifically, DNSSEC helps prove two
things:
-
The information the client is accessing is coming from the
correct source. In other words, it confirms the
authority of the originator of the data being
returned by a DNS server.
-
The information you have received is the same as the
information that was sent. In other words, it confirms the
integrity of the data being returned by a DNS
server.
DNSSEC also provides authenticated denial of
existence when the information the client is trying to
access does not exist. In other words, it provides proof that the site
being requested really doesn’t exist.
What DNSSEC does not provide is
confidentiality of the data being returned by a
DNS server. In other words, it does not guarantee that the data hasn’t
been intercepted and examined while en route to the client. DNSSEC
also does not provide any protection against a distributed denial of
service (DDoS) attack against an organization’s DNS infrastructure. So
while DNSSEC provides two of the requirements of the information
security CIA triad (Confidentiality, Integrity, and Availability), it
is not in itself a complete solution to the problem of protecting an
organization’s DNS infrastructure and traffic.
Note
Why you should
deploy DNSSEC
There are several reasons why organizations today need to
consider deploying DNSSEC in their Windows Server–based
environments:
-
DNSSEC provides protection from DNS cache poisoning and
other types of attacks that can compromise an organization’s
security.
-
DNSSEC provides an additional layer of security for
enterprises that have private clouds deployed or use extranets
for business communications.
-
Revision 3 of National Institute of Standards and
Technology (NIST) Special Publication (SP) 800-53 mandates the
requirement of DNSSEC for internal DNS zone signing on U.S.
federal government information systems.
In addition, DNSSEC is likely to become a regulatory
requirement for some industries, such as finance and banking.
DNSSEC in previous Windows Server versions
Basic support for DNSSEC was introduced in Windows Server 2003
to allow DNS servers to act as secondary DNS servers for existing
DNSSEC-compliant secure zones. Windows Server 2003 DNS servers,
however, were not capable of signing zones and resource records or
validating the Signature (SIG) resource records. In addition, all
DNSSEC configuration had to be performed by editing the registry on
DNS servers.
Support for DNSSEC was enhanced in Windows Server 2008 R2 but
was limited by being intended as a solution only for file-backed,
static zones and not for dynamic Active Directory integrated zones.
The DNS server command-line management tool (Dnscmd.exe) could be used
to perform offline key generation and zone-signing capability through
a signing tool. Windows PowerShell scripts were later released through
the TechNet Script Center for performing DNSSEC administration tasks
such as signing zones and for adding, rolling over, and verifying
trust anchors. However, the DNS client in Windows 7 and Windows Server
2008 R2 is DNSSEC-aware but nonvalidating. In other words, the DNS
client can examine a response received from a DNS server to determine
whether the response has been validated by the DNS server, but the
client cannot itself validate the response it receives from the DNS
server. This means that some other method, such as Internet Protocol
security (IPsec), must still be used to secure the last mile between
the client and its local DNS server, even when DNSSEC has been
configured on DNS servers running Windows Server 2008 R2.
Windows Server 2012 now includes full DNSSEC support for Active
Directory–integrated DNS scenarios, including DNS dynamic updates in
DNSSEC signed zones, automated trust-anchor distribution through
Active Directory, automated trust-anchor rollover support per RFC
5011, and validation of records signed with updated DNSSEC standards
(NSEC3, RSA/SHA-2). An updated user interface with deployment and
management wizards is also included, as well as full Windows
PowerShell support for configuring and managing DNSSE. However, the
DNS client in Windows 8 and Windows Server 2012 is still DNSSEC-aware
but nonvalidating, which means IPsec should still be used to secure
the network connecting the client to its local DNS server.
