[ISN] ITL Bulletin for June 2006

[InfoSec News]

Forwarded from: Elizabeth Lennon <elizabeth.lennon at nist.gov>

ITL Bulletin for June 2006

DOMAIN NAME SYSTEM (DNS) SERVICES: NIST RECOMMENDATIONS FOR 
SECURE DEPLOYMENT

Shirley Radack, Editor
Computer Security Division
Information Technology Laboratory
National Institute of Standards and Technology
Technology Administration
U.S. Department of Commerce

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.


Elizabeth B. Lennon
Writer/Editor
Information Technology Laboratory
National Institute of Standards and Technology
100 Bureau Drive, Stop 8900
Gaithersburg, MD 20899-8900
Telephone (301) 975-2832
Fax (301) 975-2378