Forwarded from: Elizabeth Lennon <elizabeth.lennon@private> 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 _________________________________ Attend the Black Hat Briefings and Training, Las Vegas July 29 - August 3 2,500+ international security experts from 40 nations, 10 tracks, no vendor pitches. www.blackhat.com
This archive was generated by hypermail 2.1.3 : Tue Jul 04 2006 - 22:28:02 PDT