DOMAIN NAME SYSTEM (DNS) SERVICES: NIST
RECOMMENDATIONS FOR SECURE DEPLOYMENT
Shirley Radack, Editor
Computer Security Division
Information Technology
Laboratory
National
Domain Name System (DNS) services
have an important function in helping users readily access the many resources
that are available through the Internet. DNS services make communications convenient
for the user by translating the unique resource identifier that is known as the
Internet Protocol (IP) address into a domain name that is easy for the user to
remember. The IP address to which a user wishes to be connected is represented
by four groups of numbers separated by dots, such as123.67.43.254. The
computers in the network route communication packets across the Internet based
on the IP addresses of the packets. However, when accessing websites and using
e-mail services, the user can simply employ a domain name such as nist.gov, which is easier to remember
than the full IP address. The DNS transforms human-readable domain names into
machine-readable IP addresses and also does the reverse process, taking a query
with an IP address and returning the domain name associated with it.
The DNS infrastructure, which carries out the domain
name translation, is made up of computing and communication entities that are
geographically distributed throughout the world. There are more than 250
top-level domains, such as .gov and .com, and several million second-level
domains, such as nist.gov and ietf.org. As a result, there are many
name servers in the DNS infrastructure that contain information about only a small
portion of the domain name space. The different servers work together to
provide DNS services. The domain name data provided by DNS is intended to be publicly
available to any computer located anywhere in the Internet.
While DNS services are not the primary target of most
attacks on information systems today, the DNS infrastructure is expected to become
more vulnerable as more applications use DNS for network operations. NIST’s
Information Technology Laboratory (ITL) has developed guidance to help
organizations protect their DNS components, prevent possible future attacks on domain
name information, and maintain the availability of DNS services and data.
NIST Special
Publication (SP) 800-81, Secure Domain
Name System (DNS) Deployment Guide
NIST SP 800-81, Secure
Domain Name System (DNS) Deployment Guide, presents NIST’s recommendations
to help organizations analyze their operating environments and the threats to
their DNS services, and to apply appropriate risk-based security measures for
all DNS components. Written by ITL’s Ramaswamy Chandramouli and Scott Rose, the
publication provides guidelines for the secure deployment of each DNS component
through the use of configuration options and checklists that are based on
policies or best practices. Development and publication of the guide were
carried out in collaboration with the Department of Homeland Security (DHS).
NIST SP 800-81 explains the
structure and operations of DNS data, software, and transactions and discusses
the threats, the security objectives, and the security approaches that can be
employed. Extensive guidance is provided on maintaining data integrity and
performing source authentication, and on configuring DNS deployments to protect
the availability of DNS services and prevent denial of service attacks. Other
topics covered include how to secure DNS query and response activities, how to
minimize information exposure through DNS data content control, and how to
maintain secure operations. The appendices explain the technical terms and the
acronyms used in the publication and contain extensive references to publications
and websites with additional information.
The publication is available
on NIST’s web pages at: http://csrc.nist.gov/publications/nistpubs/index.html.
The Domain
Name System Infrastructure
The Domain Name System is composed of several
components. Users enter domain names to access Internet resources, through a program
such as a web browser. The browser calls the DNS to provide the IP address for
the appropriate web server and web page. This function of mapping domain names
to IP addresses is name resolution, and
the client system uses the DNS protocol to perform the
name resolution function. The DNS has a data repository where the domain names
and their associated IP addresses are stored. Software manages this data
repository, which may be distributed, and provides name resolution service. This
function is the name server. The
function, which accesses the services provided by a DNS name server on behalf
of user programs, is called the resolver. The DNS infrastructure is composed of the communication
protocol, the various DNS components, the policies governing the configuration
of these components, and procedures for creation, storage, and usage of domain
names.
Securing the
Domain Name System
The primary security goals for DNS are data integrity
and source authentication, which are needed to ensure the authenticity of
domain name information and to maintain the integrity of domain name
information in transit. The availability of DNS services and data is also very
important; DNS components are often subjected to denial of service attacks
intended to disrupt access to the resources whose domain names are handled by
the attacked DNS components. Misdirection of DNS data to a malicious site is
another major security concern.
DNS
Vulnerabilities
The DNS is susceptible to many of the same
vulnerabilities as other distributed computing systems. These include
vulnerabilities at the platform, software, and network levels. For most
distributed systems, the security objectives of confidentiality, integrity, and
availability of information apply. A loss of confidentiality is the
unauthorized disclosure of information. A loss of integrity is the unauthorized
modification or destruction of information. A loss of availability is the
disruption of access to or use of information or an information system.
However, because the DNS serves as an infrastructure
system for the global Internet, it has the following special characteristics
not found in many distributed computing systems.
* There are no well-defined system boundaries. Participating
entities are not subject to geographic or topologic confinement rules.
* There is no need for data confidentiality, one of
the three security objectives for information. Public DNS data should be
accessible to any entity regardless of the entity’s location or affiliation.
Because of these special characteristics, conventional
network-level attacks, such as masquerading and message tampering, and attacks
that tamper with the integrity of the hosted and disseminated data, can have significant
functional impacts on the entire Internet and on its users.
For example,
a masquerader who spoofs the identity of a DNS node can deny access to services
to the entire collection of Internet resources for which the node provides
information. All of the domains served by the node would be affected, and the
denial of service would impact all clients needing access to the resources.
False DNS
information provided by a masquerader or intruder can corrupt the information
cache of the DNS node providing that subset of DNS information. The name server
providing Internet access service to the organization’s users would be
affected, and all users would be denied services and access to the resources provided
by the server.
When the
integrity of DNS information is attacked, the entire information retrieval
process would be broken. The information maintained by the authoritative system
or the information cache of an intermediary that has accumulated information from
several historical queries would be affected. This situation can cause a denial
of service for the DNS name resolution function or a misdirection of users to the
wrong resources.
If the name
resolution data hosted by the DNS system is inaccurate, there could be an increased
workload on the DNS system or the provision of obsolete data that could result
in denial of service to Internet resources. For most software, such as
conventional database management systems (DBMS), the independence of the program
data acts as a buffer to protect against the adverse impacts due to erroneous
data. In the case of DNS, the data content determines the integrity of the
entire system.
NIST Recommendations
NIST
recommendations to protect DNS information are based on specifications
developed by the Internet Engineering Task Force (IETF), an open international
community of network designers, operators, vendors, and researchers concerned
with the evolution of the Internet architecture and the smooth operation of the
Internet. See the More Information
section below for information about the IETF’s Domain Name System Security
Extensions (DNSSEC)
specifications, Transaction Signature (TSIG) specification, and for a link to
IETF web pages.
Because of the functional impacts of attacks on the
DNS, NIST recommends that organizations take the following actions to protect
their DNS services:
* Implement
appropriate system and network security controls for securing the DNS hosting
environment, such as operating system and application patching, process
isolation, and network fault tolerance.
* Protect
DNS transactions such as the update of DNS name resolution data and data
replication that involve DNS nodes within the organization’s control. The
transactions should be protected using hash-based message authentication codes
based on shared secrets, as outlined in the IETF TSIG specification. Message
authentication codes (MACs) are cryptographic functions that provide assurance
to the receiver of data that the sender of the data is truly the sender and
that the data has not been modified since it was authenticated. A hash function
is a one-way function that produces a short representation of a longer message
and is used to determine whether or not data has been changed after it was
transmitted.
* Protect
the ubiquitous DNS query/response transaction that could involve any DNS node
in the global Internet using digital signatures based on asymmetric
cryptography, as outlined in IETF’s DNSSEC specification.
* Enforce
content control of DNS name resolution data using a set of integrity
constraints that are able to provide the right balance between performance and
integrity of the DNS system.
NIST recommends that organizations secure their DNS
name server through the deployment of the DNSSEC for zone information. A zone
may be either an entire domain or a domain with one or more sub-domains. A zone
is a configurable entity within a name server under which information on all
Internet resources pertaining to a domain and a selected set of sub-domains is
described. Zones are administrative building blocks of the DNS name space, just
as domains are the structural building blocks.
Protection
approaches for DNS software include choice of version, installation of patches,
running the version with restricted privileges, restricting other applications
in the execution environment, dedicating instances for each function,
controlling the set of hosts where software is installed, placing the software
properly within the network, and limiting information exposure by
logical/physical partitioning of zone file data or running two name server
software instances for different client classes. The latest version of name
server software should be used.
Organizations
should:
* Install a
DNSSEC-capable name server implementation.
* Check zone file(s) for any possible integrity errors.
NIST SP 800-81 details the technical steps that a DNS administrator can take in
generating a zone file to keep network exposure to a minimum. This
process should be done prior to signing a zone to authenticate security. Network
information that should be kept absolutely private should not be published in
DNS at all.
* Generate an asymmetric key pair for each zone and
include them in the zone file. The DNSSEC specifies generation and verification
of digital signatures using
asymmetric keys. This requires generation of a public key-private key pair. Although
the DNSSEC specification requires the use of just one key pair, experience from
pilot implementations suggests that at least two different types of keys are
needed for easier routine security administration operations such as key
rollover (changing of keys) and zone re-signing. NIST SP 800-81
provides guidance on the use of NIST-approved algorithms for digital signatures
and for hash algorithms to be used as part of the algorithms suite for
generating digital signatures.
* Sign the
zone. The process for signing a zone file consists of generating a hash,
generating a signature, and capturing the signature information in a file.
* Load the
signed zone onto the server.
* Configure
name servers that deploy DNSSEC-signed zones or query-signed zones to perform
DNSSEC processing. NIST SP 800-81 discusses the mechanisms involved in the
DNSSEC approach, the operations that those mechanisms entail, and a secure way
of performing those operations by using checklists.
Other NIST recommendations deal with the basic steps
of DNSSEC deployment for caching name servers.
* Install a DNSSEC-capable resolver implementation.
* Obtain one or more trust anchors for zones that the
administrator wants to be validated. Until all zones become signed zones, there
could be a situation in which a zone is signed but its parent zone is not
signed. A chain of trust should be established through all of the zones in the
DNS tree to assure the authenticity of the public key of a zone signer.
* Configure the
resolver to turn on DNSSEC processing.
Other recommendations in the guide deal with the secure
configuration and the operations of name servers.
More Information
NIST recommendations for securing the DNS are based on
the following primary security specifications that were developed by the IETF,
an open international technical group:
* Internet
Engineering Task Force (IETF) Domain Name System Security Extensions (DNSSEC)
specifications, covered by Request for Comments (RFCs) 4033, 4034, 4035, and
3833; and
* IETF
Transaction Signature (TSIG)
specifications, covered by RFCs 2845 and 3007.
Documents produced by the
Internet Engineering Task Force are referenced in Appendix C of NIST SP 800-81.
General information about IETF is available at http://www.ietf.org/.
The IETF community’s ultimate
goal is for DNSSEC to be fully deployed across the entire domain tree on the
infrastructure side, and implementation in applications that can demand the
services provided by DNSSEC. At present, there are no operational nodes in the
DNS domain tree that provide DNSSEC capabilities. The first step towards full
deployment is to provide DNSSEC capability for domain sub-trees that have high
security needs. Once DNSSEC capabilities become widely available in the
infrastructure, application developers will be able to develop DNSSEC
applications and use DNSSEC as a means for network security. In the future, all
DNS name servers and clients should be able to perform at least some of the
operations detailed in the DNSSEC specifications and in NIST SP 800-81.
NIST publications assist
organizations in planning and implementing a comprehensive approach to IT
security. For information about NIST standards and guidelines that are
referenced in the DNS guide, as well as other security-related publications,
see http://csrc.nist.gov/publications/index.html.
Recent standards and
guidelines of particular interest to the federal community address the process
that federal agencies should apply in determining appropriate and effective
security controls for their systems. Federal Information Processing Standard
(FIPS) 199, Standards for Security
Categorization of Federal Information and Information Systems, requires
agencies to categorize their information systems as low-impact,
moderate-impact, or high-impact for the security objectives of confidentiality,
integrity, and availability. FIPS 200, Minimum
Security Requirements for Federal Information and Information Systems,
specifies the minimum security requirements for information and information
systems in seventeen security-related areas. Federal agencies must meet the
minimum security requirements through the use of the security controls in
accordance with NIST SP 800-53, Recommended
Security Controls for Federal Information Systems. NIST SP 800-53 has been
revised to include safeguards and countermeasures for information systems that
reflect the state of the practice, including DNSSEC. Information about the
proposed revision and the public review period is available from the NIST
publications website.
Disclaimer
Any mention of commercial
products or reference to commercial organizations is for information only; it
does not imply recommendation or endorsement by NIST nor does it imply that the
products mentioned are necessarily the best available for the purpose.