Executive Summary

The Internet is the world’s largest computing network, with hundreds of million of users. From the perspective of a user, each node or resource on this network is identified by a unique name—the domain name—such as www.nist.gov. However, from the perspective of network equipment that routes communications across the Internet, the unique identifier for a resource is an Internet Protocol (IP) address, such as 172.30.128.27. To access Internet resources by user-friendly domain names rather than IP addresses, users need a system that translates domain names to IP addresses and back. This translation is the primary task of an engine called the Domain Name System (DNS).

The DNS infrastructure 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. Accordingly, there are many name servers in the DNS infrastructure, which each contain information about a small portion of the domain name space. The DNS infrastructure functions through collaboration among the various entities involved. The domain name data provided by DNS is intended to be available to any computer located anywhere in the Internet.

This document provides deployment guidelines for securing DNS within an enterprise. Because DNS data is meant to be public, preserving the confidentiality of DNS data pertaining to publicly accessible IT resources is not a concern. The primary security goals for DNS are data integrity and source authentication, which are needed to ensure the authenticity of domain name information and maintain the integrity of domain name information in transit. This document provides extensive guidance on maintaining data integrity and performing source authentication. 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. This document presents guidelines for configuring DNS deployments to prevent many denial-of-service attacks that exploit vulnerabilities in various DNS components.

DNS is susceptible to the same types of vulnerabilities (platform, software, and network-level) as any other distributed computing system. However, because it is an infrastructure system for the global Internet, it has the following special characteristics not found in many distributed computing systems:

+ No well-defined system boundaries—participating entities are not subject to geographic or topologic confinement rules

+ No need for data confidentiality—the data should be accessible to any entity regardless of the entity’s location or affiliation.

Because of these characteristics, conventional network-level attacks such as masquerading and message tampering, as well as violations of the integrity of the hosted and disseminated data, have a completely different set of functional impacts, as follows:

+ A masquerader that spoofs the identity of a DNS node can deny access to services for the set of Internet resources for which the node provides information (i.e., domains served by the node). This denial is not only for a limited set of clients but for the entire universe of all clients needing access to those resources

+ Bogus DNS information provided by a masquerader or intruder can poison the information cache of the DNS node providing that subset of DNS information (i.e., the name server providing Internet access service to the enterprise’s users), resulting in a denial of service to the resources serviced by it

+ Violation of the integrity of DNS information resident on its authoritative source or the information cache of an intermediary that has accumulated information from several historical queries may break the chained information retrieval process of DNS. This could result in either a denial of service for DNS name resolution function or misdirection of users to a harmful set of illegitimate resources.

+ If the name resolution data hosted by the DNS system violates content requirements as defined in DNS standards, it could have adverse impacts such as increased workload on the DNS system, or serving obsolete data that could result in denial of service to Internet resources. In most software, program data independence (as in conventional Database Management Systems (DBMS)) provides a degree of buffer against adverse impacts due to erroneous data. In the case of DNS, the data content determines the integrity of the entire system.

Based on these functional impacts, the deployment guidelines for secure DNS presented in this document broadly consist of the following generic and DNS-specific recommendations:

+ Implement the usual 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 update of DNS name resolution data and data replication that involve DNS nodes within an enterprise’s control. The transactions should be protected using hash-based message authentication codes based on shared secrets, as outlined in Internet Engineering Task Force’s (IETF) Transaction Signature (TSIG) specification.

+ 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 Domain Name System Security Extension (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.This guide contains recommendations for securing a DNS name server. Part of those recommendations is deployment of the DNS Security Extensions (DNSSEC) for zone information. The basic steps to accomplish that part of security are below:

+ Install a DNSSEC capable name server implementation (See Section 7.2.1)

+ Check zone file(s) for any possible integrity errors (See Section 10)

+ Generate asymmetric key pair for each zone and include them in the zone file (See Section 9.2 and 9.3)

+ Sign the zone (See Section 9.5)

+ Load the signed zone onto the server

+ Configure name server to turn on DNSSEC processing (See Section

+ (OPTIONAL) send copy of public key to parent for secure delegation

Note that this guide focuses on authoritative name servers for the most part, but the basic steps of DNSSEC deployment for caching name servers are below:

+ Install a DNSSEC capable resolver implementation (See Section 7.2.1)

+ Obtain one or more trust anchors for zones administrator wants validated (See Section9.6)

+ Configure resolver to turn on DNSSEC processing

The rest of the guide covers recommendations for secure configuration and operations of name servers.

1. Introduction

1.1 Authority

The National Institute of Standards and Technology (NIST) developed this document in furtherance of its statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002, Public Law 107-347.

NIST is responsible for developing standards and guidelines, including minimum requirements, for providing adequate information security for all agency operations and assets; but such standards and guidelines shall not apply to national security systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), “Securing Agency Information Systems,” as analyzed in A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in A-130, Appendix III.

This guideline has been prepared for use by Federal agencies. It may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright, though attribution is desired.

Nothing in this document should be taken to contradict standards and guidelines made mandatory and binding on Federal agencies by the Secretary of Commerce under statutory authority, nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other Federal official.

1.2 Purpose and Scope

This publication seeks to assist organizations in understanding the secure deployment of Domain Name System (DNS) services in an enterprise. It provides practical, real-world guidance on securing each facet of DNS within an organization based on an analysis of the operating environment and associated threats.

Currently, the DNS is not the target of most attack, but as hosts become more security aware, and applications begin to rely on the DNS infrastructure for network operations, the DNS infrastructure will become a more tempting target. The ultimate goal for DNSSEC is full deployment across the entire domain tree, and implementation in applications that would benefit from DNSSEC. However, full deployment will take time, so the immediate goal of DNSSEC is deployment on systems that have high security needs first. This will provide security for key parts of the DNS infrastructure first, and then spread deployment to the rest of the domain tree. As the infrastructure becomes secure, application developers will be able to use DNSSEC to support network security.

In this guide, DNSSEC deployment is targeting the DNS infrastructure, not individual hosts. However, as the infrastructure becomes more secure, DNSSEC will naturally push down to the individual clients that make DNS queries. DNSSEC was designed with backward compatibility in mind, so that current network applications can gain some security from DNSSEC, provided that servers upstream are using DNSSEC, but in the future, it is hoped all systems (DNS name servers and clients) will be able to proform at least some of the operations detailed in the DNSSEC specifications and this document.

1.3 Audience

This document has been created for the administrators of DNS deployments, as well as computer security staff and system administrators who are responsible for performing duties related to DNS.

1.4 Document Structure

The remainder of this document is organized into the following ten major sections:

+ Section 2 provides an introduction to DNS and DNS infrastructures. It also discusses the security objectives of DNS and gives additional information on which aspects of DNS are addressed by this document.

+ Section 3 introduces some basic DNS components, such as the zone file that holds DNS data, and the name servers and resolvers that provide DNS services.

+ Section 4 defines the different types of DNS transactions.

+ Section 5 discusses the threats, security objectives, and protection approaches involving the DNS hosting environment. Section 6 provides the same types of information for DNS transactions.

+ Sections 7 and 8 present guidelines for securing the DNS hosting environment and DNS transactions (except DNS query/response), respectively.

+ Section 9 provides recommendations for securing DNS query/response Transaction.

+ Section 10 focuses on guidance for minimizing information exposure through DNS.

+ Section 11 presents guidelines for DNS security administration operations.

The document also contains appendices with supporting material. Appendix A presents definitions of important DNS security terminology. Appendix B contains an acronym list, and Appendix C contains a bibliography.

2. Securing Domain Name System

This document provides deployment guidelines for securing the Domain Name System (DNS) in an enterprise. The term enterprise includes a U.S. Federal government agency or a corporate entity. The deployment guidelines follow from an analysis of security objectives and consequent protection approaches for all DNS components. The rationale for security objectives and mechanics for development of deployment guidelines are given below:

+ Security objectives for each DNS component are developed on the basis of analysis of operating environment and associated threats.

+ Secure deployment guidelines for each DNS component are provided through a combination of configuration options and checklists that are based on policies or best practices.

The primary security specifications (with associated mechanisms) for which this document provides deployment guidelines are as follows:

+ Internet Engineering Task Force (IETF) Domain Name System Security Extensions (DNSSEC) specifications, covered by Request for Comments (RFC) 4033, 4034, 4035, and 3833 [6,7,8,1][1]

+ IETF Transaction Signature (TSIG) specifications, covered by RFCs 2845 and 3007 [12,9].[2]

2.1 What is the Domain Name System (DNS)?

The Internet is the world’s largest computing network, with more than 580 million users. From the perspective of a user, each node or resource on this network is identified by a unique name: the domain name. Some examples of Internet resources are:

+ Web servers—for accessing Web sites

+ Mail servers—for delivering e-mail messages

+ Application servers—for accessing software systems and databases remotely.

From the perspective of network equipment (e.g., routers) that routes communication packets across the Internet, however, the unique resource identifier is the Internet Protocol (IP) address, represented as a series of four numbers separated by dots (e.g., 123.67.43.254). To access Internet resources by user-friendly domain names rather than these IP addresses, users need a system that translates these domain names to IP addresses and back. This translation is the primary task of an engine called the Domain Name System (DNS).

Users access an Internet resource (e.g., a Web server) through the corresponding client or user program (e.g., a Web browser) by typing the domain name. To contact the Web server and retrieve the appropriate Web page, the browser needs the corresponding IP address. It calls DNS to provide this information. This function of mapping domain names to IP addresses that is provided by DNS is called name resolution. The protocol that DNS uses to perform the name resolution function is called the DNS protocol.

The DNS function described above includes the following building blocks. First, DNS should have a data repository to store the domain names and their associated IP addresses. Because the number of domain names is large, scalability and performance considerations dictate that it should be distributed. The domain names may even need to be replicated to provide fault tolerance. Second, there should be software that manages this repository and provides the name resolution function. These two functions (managing the domain names repository and providing name resolution service) are provided by the primary DNS component, the name server. There are many categories of name servers, distinguished by type of data served and functions performed. To access the services provided by a DNS name server on behalf of user programs, there is another component of DNS called the resolver. There are two primary categories of resolvers (caching/recursive/resolving name server and stub (non-caching) resolver),[3] distinguished by functionality. 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 constitute the DNS infrastructure.

2.2 DNS Infrastructure

The DNS infrastructure is made up of computing and communication entities that are geographically distributed throughout the world. To understand this DNS infrastructure, it is necessary to examine first the structure behind the organization of domain names. The domain name space (the universe of all domain names) is organized in the form of a hierarchy. The topmost level in the hierarchy is the root domain, which is represented as a dot (“.”). The next level in the hierarchy is called the top-level domain (TLD). There is only one root domain, but there are many TLDs. Each TLD is called a child domain of the root domain. In this context, the root domain is the parent domain because it is one level above a TLD. Each TLD, in turn, can have many child domains. The children of TLDs are called second-level or enterprise-level domains.

In a domain name representation, the symbol for the root domain usually is omitted. For example, consider the domain name marketing.example.com. The rightmost label in this domain name (“com.”) is a TLD. The next label to the left (“example”) is the second-level or enterprise-level domain. The leftmost label (“marketing”) is the third-level domain. It also is possible to have a fourth-level domain, fifth-level domain, and so forth. Because each of the labels in marketing.example.com is called a domain (TLD, second-level domain, third-level domain, etc.), the concatenation of all these labels from the current level to the TLD is a fully qualified domain name (FQDN). In this document, however, the FQDN is referred to as simply a domain name, and the level name is used to identify individual labels.

There is only one root domain. There are more than 250 TLDs, categorized into the following three types:

+ Country-code TLDs (ccTLDs)—domains associated with countries and territories. There are more than 240 ccTLDs. Examples include .uk, .in, and .jp.

+ Sponsored generic TLDs (gTLDs)—specialized domains with a sponsor representing a community of interest. These TLDs include .edu, .gov, .int, .mil, .aero, .coop, and .museum.

+ Unsponsored generic TLDs (gTLDs)—domains without a sponsoring organization. The list of unsponsored gTLDs includes .com, .net, .org, .biz, .info, .name, and .pro.

There are several million enterprise-level (second-level or lower) domains. In fact, as of September 2004 there were more than 60 million registered domain names. A partial DNS name space hierarchy is shown in Figure 2-1.

Figure 2-1. Partial DNS Name Space Hierarchy

There are many name servers in the DNS infrastructure. Each name server contains information about a portion of the domain name space. Name servers are associated with levels as far as the first three levels of domain name space are concerned. There are 13 name servers associated with the root level; they are called root servers. Two of the root servers are currently run by the U.S private-sector corporation VeriSign; the rest are operated by other organizations around the world as a service to the Internet community. The organizations that run name servers associated with a TLD are called registries. Generally, ccTLDs are run by designated registries in the respective countries, and gTLDs are run by global registries. For example, VeriSign currently manages the name servers for the .com and .net TLDs, a nonprofit entity called Public Internet Registry (PIR) manages the name servers for the .org TLD, and another nonprofit organization called EDUCAUSE manages the name servers for the .edu TLD. All of these registry organizations are subject to change, however. Domain registrants should be familiar with the points of contact (called registrars) for their particular registry. The name servers associated with enterprise-level domains and below are either run directly by the organizations that own those domains or outsourced to Internet service providers (ISP) or other service providers.

The DNS infrastructure functions through collaboration among the various entities involved (organizations that manage root servers, registries that run TLDs, etc.) A nonprofit, private-sector corporation, the Internet Corporation for Assigned Names and Numbers (ICANN), acts as the technical coordination body for aspects of DNS. For example, ICANN formulates policies for management of root servers. ICANN also is the authority for creation of new TLDs. ICANN was established in 1998 by the U.S. Department of Commerce.

A user (i.e., an individual or corporation) wishing to register a domain name (which can only be an enterprise-level domain under a TLD) must contact an authorized entity called a registrar (which may charge a fee, depending on the TLD in question). Registrars are companies that are authorized to register domain names in a particular TLD (or even in a sub-domain of a TLD e.g. co.uk.) to end-users. There are registrars all over the world. When the registrar receives the user’s registration request, the registrar verifies that the name is available by checking with the registry that manages the corresponding TLD (or sub-domain under the TLD). If the name is available, the registrar registers the name with the appropriate registry. The registry then adds the new name to its registry database and publishes the new name in DNS. Note that in some domains (some country codes and gTLDs for example), the same organization acts as the registry and registrar for names in the domain. There is no middle organization that registers names on behalf of the domain holder.

Organizations that register and obtain an enterprise-level domain name often have to create child domains to properly identify Internet resources associated with various functional units. For example, the owner of the domain name example.com might create the subdomain shipping to create and identify resources associated with the shipping department of the organization. Similarly, many other subdomains (in this context, third-level domains) may be created to properly identify all of the Internet resources of the organization. Often, however, in any one organization (that is, the owner of a second-level domain) there will be many third-level domains but few Internet resources (Web servers, application servers, etc.) in each of these domains. Hence, it is not economical to assign a unique name server for each of these third-level and lower-level domains. Furthermore, it is administratively convenient to group all information pertaining to an organization’s primary domain (i.e., a second-level or enterprise-level domain) and all its subdomains into a single resource and manage it as a unit.

To facilitate this grouping, the DNS defines the concept of a zone. A zone may be either an entire domain or a domain with one or more subdomains. 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 subdomains is described. Thus, zones are administrative building blocks of the DNS name space just as domains are the structural building blocks. As a result, the term zone commonly is used even to refer to a domain that is managed as a standalone administrative entity (e.g., the root zone, the .com zone). This document uses the term zone to refer to a resource entity that contains domain name information about one or more domains and is managed as a single administrative entity. In other words, the zone is the configurable resource inside a deployed name server installation that contains the domain name information.

With this overall knowledge of DNS infrastructure (name servers and resolvers), domain names, zones, name servers of various levels (i.e., root servers and TLD servers) and resolvers, the name resolution function can now be defined in more detail. When a user types the URL www.example.com into a Web browser, the browser program contacts a type of resolver called a stub resolver that then contacts a local name server (called a recursive name server or resolving name server). The resolving name server will check its cache to determine whether it has valid information (the information is determined to be valid on the basis of criteria described later in this document) to provide IP address for the accessed Internet resource (i.e., www.marketing.example.com). If not, the resolving name server checks the cache to determine whether it has the information regarding the name server for the zone marketing.example.com (since this is the zone that is expected to contain the resource www.marketing.example.com). If the name server’s IP address is in the cache, the resolver’s next query will be directed against that name server. If the IP address of the name server of marketing.example.com is not available in the cache, the resolver determines whether it has the name server information for a zone that is one level higher than marketing.example.com (i.e., example.com). If the name server information for example.com is not available, the next search will be for the name server of the .com zone in the cache.

If the complete search of the cache (as described above) does not yield the required information, the resolving name server has no alternative but to start its search by querying the name server in the topmost zone in the DNS name space hierarchy (i.e., the root server). If the cache search is successful, the resolving name server has to query the name servers in one of the levels below the root zone (in this context, either marketing.example.com, example.com, or .com). Because the set of iterative queries starting from the root server subsumes the set starting from any of the lower-level servers, this section describes the name resolution process starting from the query sent to the root server by the resolving name server at the enterprise-level.

Contact with the root servers is enabled by a file called the “root hints” file that is usually present in every name server in DNS. The root hints file contains the IP address of one or more of the 13 root servers. The root server will contain information about the name servers for its child zones (i.e., TLDs). A TLD (e.g, .com) will contain name server information about its child zones (e.g., example.com). The name server information about its child zones that is carried in a zone is called delegation information. The delegation information is the one that is used by a zone to route name resolution requests for a resource lower than it in the domain name hierarchy. Since the name resolution request in this example pertains to a resource in the third-level domain, the root server must route the request to a lower-level name server. The response to the resolving name server that involves sending this delegation information is called the referral. The referral provides the name and IP address for the name servers for the TLD zone that is relevant to the request (i.e., the .com zone) (since the query is for a resource in marketing.example.com). Using this referral, the resolving name server then formulates and sends a query to the .com zone name server. This server will provide the referral for example.com’s name server. If the marketing.example.com domain is included in example.com’s zone, querying the name server for example.com will provide the IP address for the resource www.marketing.example.com. A diagram of the name resolution process (without cache search operations) is given in Figure 2-2.

Figure 2-2. Name Resolution Process (without cache search)

As the description of the name resolution process makes clear, a name server performs the following functions:

+ It provides a referral to a child zone.

+ It provides a mapping from domain name to IP address, called domain name resolution, or IP address to domain name, sometimes called an inverse resolution, but is actually a standard query for a different type of data.

+ It provides an error message if the query is for a DNS entry that does not exist.

The name server performs these three functions with the same DNS database, which is called a zone file. A class of information called delegation information contains the name server information for child zones in a parent zone and is used in performing the referral function. The mapping function is performed by a class of information in a zone file called authoritative information and is provided by a set of records that list the resources in that zone, along with its domain name and its corresponding IP address. Because the resources belong to that zone, the information provided is deemed authoritative. Thus, a zone file contains two categories of information: authoritative information (information about all resources for all domains in the zone) and delegation information (information about name servers for child zones). The locations in the zone file where delegation information appears are called delegation points. The level of a zone file is the level of the topmost domain for which it contains authoritative information. In the previous example, the zone file in the name server of example.com is the enterprise-level zone file, and the corresponding name server is called the enterprise-level name server.

2.3 DNS Components and Security Objectives

Before security objectives can be determined, the building blocks of the DNS need to be specified. DNS includes the following entities:

+ The platform (hardware and operating system) on which the name server and resolvers reside

+ The name server and resolver software

+ DNS transactions

+ DNS database (zone files)

+ Configuration files in the name server and resolver.

The media access-level network technology (i.e., Ethernet network connecting a stub resolver and the local resolving name server) is not included in the definition of DNS.

Confidentiality, integrity, availability, and source authentication are security goals that are common to any electronic system. However, the DNS is expected to provide name resolution information for any publicly available Internet resource. Hence except for DNS data pertaining to internal resources (e.g., servers inside a firewall etc), that is provided by internal DNS name servers through secure channels, the DNS data provided by public DNS name servers is not deemed confidential. Hence confidentiality is not one of the security goals of DNS. Ensuring the authenticity of information and maintaining the integrity of information in transit is critical for efficient functioning of the Internet, for which the DNS provides the name resolution service. Hence, integrity and source authentication are the primary DNS security goals.

Because of the sheer diversity of name server platforms and the underlying networks in which DNS components (such as name server software and resolver software) reside, preventing all types of denial-of-service attacks is not feasible. Some baseline guidelines must be observed, however, to prevent denial-of-service attacks that exploit vulnerabilities in the name server platform, zone file data content, and access control configuration for certain DNS transactions.

2.4 Focus of the Document

There are three main levels of name servers: root name servers, TLD name servers, and enterprise-level name servers. This document provides deployment guidelines for securing name servers for the .gov domain (zone) at the TLD level and for all enterprise-level name servers below the .gov TLD. Thus, the guidelines cover secure configuration and operation of all name servers in all civilian agencies of the U.S. Federal Government. The target audience consists of zone administrators who are responsible for the configuration and operation of these name servers. The guidelines are equally applicable, however, to any enterprise-level zone (e.g., mit.edu).

The security mechanisms to which the guidelines in this document apply conform to IETF’s DNSSEC and TSIG specifications. The guidelines in this document cover policies, configuration options, and checklists for the following DNS components/associated operations):

+ DNS hosting environment

– Host platform (O/S, file system, communication stack)

– DNS software (name server, resolver)

– DNS data (zone file, configuration file)

+ DNS transactions

– DNS query/response

– Zone transfers

– Dynamic updates

– DNS NOTIFY

+ Security administration

– Choice of algorithms and key sizes (TSIG and DNSSEC)

– Key management (generation, storage, and usage)

– Public key publishing and setting up trust anchors

– Key rollovers (scheduled and emergency).

This page has been left blank intentionally.

3. DNS Data and DNS Software

The two primary software components of DNS are the name server and the resolver. The primary functions of the name server are to host the database (called the zone file) containing domain information and to provide responses to name resolution queries through authoritative responses or referrals. The primary function of the resolver software is to formulate a name resolution query or series of queries. The primary DNS data is the zone file (the configuration file is another type of DNS data). Section 3.1 discusses the composition of the zone file, and Sections 3.2 and 3.3 address the functions of various types of name servers and resolvers, respectively. The discussion of name servers and resolvers is in the enterprise-level context and may not apply to corresponding entities in the root and TLD levels.

3.1 Zone File

The zone file contains information about various resources in that zone. The information about each resource is represented in a record called a Resource Record (RR). Because a zone may contain several domains and several types of resources within each domain, the format of each RR contains fields for making this identification. Specifically, the RR consists of the following major fields:

+ Owner name: the domain name or a resource name

+ TTL: time to live in seconds

+ Class: at present only one class, IN (denoting Internet), is used

+ RRType: type of resource

+ RData: information about the resource (depends upon RRType)

Some of the common RRTypes are:

+ A: Address RRType. An RR of this type provides the IP address for a host name (identified using a FQDN).

+ MX: Mail Exchanger RRType. An RR of this type provides the mail server host name for a domain.

+ NS: Name Server RRType. An RR of this type provides a name server host name for a domain.

IETF RFC 1035 provides the complete format of valid RRTypes in DNS.[4] Because there could be multiple resources of a given RRType (e.g., several hosts acting as name servers) under the same owner name and since there is only one class (CLASS) (i.e., IN), the information of interest (e.g., all mail servers (RRType = MX) in a domain) in a zone file is on a combination of RRs that contain the same owner name, TTL, class, and RRType. The set of RRs with the same owner name, class, and RRType is called an RRSet. Hence, logically a zone file is made up of several RRSets.

3.2 Name Servers

There are two main types of name servers: authoritative name servers and caching name servers. The term authoritative is with respect to a zone. If a name server is an authoritative source for RRs for a particular zone (or zones), it is called an authoritative name server for that zone (or zones). An authoritative name server for a zone provides responses to name resolution queries for resources for that zone, using the RRs in its own zone file. A caching name server (also called a resolving/recursive name server), by contrast, provides responses either through a series of queries to authoritative name servers in the hierarchy of domains found in the name resolution query or from a cache of responses built by using previous queries.

3.2.1 Authoritative Name Servers

There are two types of authoritative name servers: master (or primary) name server and slave (or secondary) name server. To improve fault tolerance, there could be several slave name servers in an enterprise. A master name server contains zone files that are created and edited manually by the zone administrator. Sometimes a master name server allows the zone file to be dynamically updated by authorized DNS clients. A master name server that is configured with this feature usually is called the primary master name server. A slave (secondary) name server also contains authoritative information for a zone, but its zone file is a replication of the one in the associated master name server. The replication is enabled through a transaction called zone transfer that transfers all RRs from the zone file of a master name server to the slave name server. Because a name resolution query is for a specific RR, a zone transfer actually is treated as a category of name resolution query with type code AXFR, which means “all RRs for the zone that is being queried.” Whenever the contents of a zone file are changed in the master name servers, the slave name servers are notified of the change through a transaction called DNS NOTIFY. When a slave name server receives this request, it initiates a zone transfer request to the master name server.

3.2.2 Caching Name Servers

A caching name server generally is the local name server in the enterprise that performs the name resolution function on behalf of the various enterprise clients. A caching name server also is called a resolving/recursive name server. The name resolution function is performed by a caching name server in response to queries from a stub resolver. The search process involved in name resolution may involve searching its own cache, recursively querying various authoritative name servers through a set of iterative queries, or a combination of these methods.

A specific name server can be configured to be both an authoritative and a recursive name server. In this configuration, the same name server provides authoritative information for queries pertaining to authoritative zones while it performs the resolving functions for queries pertaining to other zones. To perform the resolving function, it has to support recursive queries. Any server that supports recursive queries is more vulnerable to attack than a server that does not support such queries (see following sections). As a result, authoritative information might be compromised. Hence, it is not a good security practice to configure a single name server to perform both authoritative and recursive functions.

3.3 Resolvers

Software such as Web browsers and e-mail clients that require access to Internet resources make use of the DNS client, called the client resolver or stub resolver. The stub resolver formulates a name resolution query for the resource sought by the Internet-accessing software and sends it to a caching (resolving) name server in the enterprise. Stub resolvers generally are configured with a list of two or more resolving name servers to provide some fault tolerance for their operation. A stub resolver often is referred to as simply a resolver. A caching (resolving) name server that receives a query from a stub resolver also formulates queries for sending them to authoritative name servers (if it is not able to respond to the query from its cache) and hence also sometimes is referred to as a resolver because it has a resolving component and a caching (name server) component.

4. DNS Transactions

The most common types of DNS transactions are the following:

+ DNS query/response

+ Zone transfer

+ Dynamic updates

+ DNS NOTIFY.

This section describes each of these transaction types.

4.1 DNS Query/Response

This is the most common transaction in DNS. A DNS query originates from a resolver; the destination is an authoritative or caching name server. The most common query is a lookup for an RR, based on its owner name or RRType. The response may consist of a single RR, an RRSet, or an appropriate error message.

As discussed previously, there are two types of queries: iterative and recursive. DNS resolvers that send iterative queries tend to be more robust with regard to the types of responses they provide because they may have to follow multiple referrals to obtain the final answer to a given query. If they also have a DNS cache, they can build up a global view of name servers in the DNS and the responses from previous queries. This can be used to shorten the turnaround time for future queries. Recursive queries usually are sent from stub resolvers that do not have the capability to handle complex DNS operations. Instead, they rely on an upstream DNS entity (usually a name server with a cache that sends iterative queries on behalf of a collection of stub resolvers) to perform the query and return the ultimate answer.

DNS queries are sent in a single UDP packet. The response usually is a single UDP packet as well, but data size may result in truncation—in which case the normal procedure is to reissue the query using TCP. UDP is preferred because of its lower overhead in consuming resources, and DNS administrators should make sure the zone data in responses do not result in a large percentage of truncated DNS responses.

DNS queries are sent in the clear, and it is assumed that the response received is correct and from an authentic source. As a result, it is possible for an active attacker to intercept (and alter) or forge responses back to a querying client. Section 6.1 provides a more detailed examination of threats to the DNS query/response transaction. Sections 8.1.1 and 9 provide security solutions proposed to address these threats.

4.2 Zone Transfer

A zone transfer refers to the way a (secondary)slave server refreshes the entire contents of its zone file from the (primary) master servers. This process enables a secondary name server to keep its zone file in synch with its primary name server. A zone transfer transaction starts as a query from a secondary name server to a primary name server. A zone transfer query—in contrast to a DNS Query—requests all RRs from a zone instead of requesting RRs of a given owner name or RRType. A zone transfer query originates from a secondary name server either in response to a DNS NOTIFY message (see Section 4.4) or on the basis of the value of the Refresh data item in the RData field of the zone’s Start of Authority (SOA) RR.

A zone transfer process has different security implications because it reveals a lot more information than a normal DNS Query and because of the increased resource usage of the message. The threats to a zone transfer transaction are discussed in Section 6.2. The protection mechanisms are discussed in sections 8.1.2 and 8.2.5.

4.3 Dynamic Updates

As enterprises add, delete, and move around IP-network-based resources (i.e., database servers, Web servers, mail servers, and even name servers), corresponding changes may need to be made to the zone file that carries information about the domains where the resources are located. In the early days of the DNS, DNS zone administrators made such changes manually. When such changes became larger in volume and more frequent, however, the manual update process was found to be inadequate, and the concept of dynamic updates was introduced. Apart from volume and frequency, there are some applications that require instant automatic updates to the DNS zone file through application programs. Examples of these applications include Certificate Authority (CA) servers, Dynamic Host Configuration Protocol (DHCP) servers, and Internet multicast address servers.

In a few instances, the DNS server is used as a repository for public key certificates. In these instances, a CA server receives a public key from a user, signs it with its private key to generate a certificate, and stores this certificate as a CERT-type RR (CERT RR) in a DNS server. A DHCP server dynamically assigns an IP address to a requesting host, and then adds this information (host and newly assigned IP address) as an A-type RR. The DHCP server also deletes this A-type RR after the IP address is returned by the host. An Internet multicast server selects a new multicast IP address from the Internet multicast IP address space and assigns it to the newly generated multicast group. Then the server adds this information (domain name of multicast group, newly selected multicast address) as an A-type RR in the DNS database so that users can join the multicast group using a domain name rather than an IP address.

RFC 2136 [7] outlines the roadmap for the dynamic update mechanism, which subsequently was implemented in BIND 8 version and has continued in all versions since.[5]

The dynamic update facility provides operations for addition and deletion of RRs in the zone file. Because updates to the contents of an existing RR can be accomplished through deletion of the old record and addition of the new record with the changed contents, no separate update operation is provided.

The suite of operations included in the dynamic update facility consists of the following:

+ Add or delete individual RRs for an existing domain

+ Delete specific RRsets (a set of resource records with the same owner name, class, and RRType [e.g., a set of RRs with RRType NS for the domain/owner name example.com with the common class IN of course]) for an existing domain

+ Delete an existing domain (all resource records for a given domain name [e.g., all RRs for the domain example.com])

+ Add a new domain (one or more RRs for a new domain [e.g., adding an A-type RR for a new domain NYBranch.example.com]).

DNS zones that allow dynamic update open themselves to a host of malicious attacks. The full list of potential attacks is detailed in Section 6.3. The proposed solution to limit or prevent these attacks is given in sections 8.1.3, 8.2.6, 8.2.7 and 8.2.8.

4.4 DNS NOTIFY

Whenever changes occur in the zone file of the primary (master) DNS server, the secondary (slave) DNS servers that are supposed to carry identical data as the primary DNS server must be notified of the changes. This notification is accomplished through the DNS NOTIFY message, which signals a secondary DNS server to initiate a zone transfer (see Section 4.2). The DNS NOTIFY message is a much more efficient and faster way of keeping secondary servers in sync with the primary server than the alternative approach of secondary servers polling the primary server for changes via the SOA Refresh value timeout.

Sending the DNS NOTIFY message, called a notify operation, is a default operation in BIND 9.x. The next question that arises is: How does the DNS name server software know to which servers the DNS NOTIFY message must be sent? The default in BIND 9.x is to notify servers that are defined in the NS RRs for the zone. If there are any additional servers to which the zone administrator wants the DNS NOTIFY message to be sent (e.g., stealth slave server), the DNS administrator can add the IP addresses of the other entities in the BIND configuration file. The administrator also can stop the server from sending notify messages for either a single zone or all the zones served by this name server through configuration options.

Once a secondary server receives a DNS NOTIFY message, it resets the relevant zone’s refresh value to zero, prompting a zone transfer attempt. As in any zone refresh, if the zone serial number in the SOA RR has not increased (see Section 10.1), the zone transfer does not take place. This procedure allows changes to the zone to propagate to all name servers more quickly.

Since a DNS NOTIFY message triggers zone transfer, spurious DNS NOTIFY messages could result in unnecessary zone transfers and hence potential denial of service. The proposed solution for minimizing these spurious notifications is given in Section 8.1.4.

This page has been left blank intentionally.

5. DNS Hosting Environment—Threats, Security Objectives, and Protection Approaches

The DNS hosting environment consists of the following elements:

+ Host platform (operating system [OS], file system, communication stack)

+ DNS software (name server, resolver)

+ DNS data (zone file, configuration file)

This section describes threats and recommended protection approaches for these portions of the hosting environment.

5.1 Host Platform Threats

Threats to the platform that hosts DNS software are no different from threats that any host in the Internet faces. These generic threats and their impact—viewed specifically from the point of view of DNS hosts—are as follows:

+ Threat T1: The OS, any system software, or any other application software on the DNS host could be vulnerable to attacks such as buffer overflows, resulting in denial of name resolution service.

+ Threat T2: The TCP/IP stack in DNS hosts (stub resolver, caching/resolving/recursive name server, authoritative name server, etc.) could be subjected to packet flooding attacks (such as SYNC and smurf), resulting in disruption of communication. An application layer counterpart of this attack is to send a large number of forged DNS queries to overwhelm an authoritative or resolving name server.

+ Threat T3: A malicious insider who has access to local area network (LAN) segments where DNS hosts reside could launch an Address Resolution Protocol (ARP) spoofing attack that disrupts DNS message flows.[6]

+ Threat T4: The platform-level configuration file that enables communication (e.g., resolv.conf and host.conf in Unix platforms) can be corrupted by viruses and worms or subject to unauthorized modifications due to inadequate file-level protections, resulting in breakdown of communication among DNS hosts (e.g., between a stub resolver and a resolving name server, between a resolving name server and an authoritative name server).

+ Threat T5: The DNS-specific configuration files (named.conf, root.hints, etc.), data files (zone file), and files containing cryptographic keys could be corrupted by viruses and worms or subjected to unauthorized modifications due to inadequate file-level protections, resulting in improper functioning of name resolution service.

+ Threat T6: A malicious host on the same LAN as a DNS client may be able to intercept and/or alter DNS responses. This would allow an attacker to redirect a client to a different site. This could be the first action in an attack on a client host.

5.2 DNS Software Threats

Threats to the DNS software itself can have serious security impacts. The most common software problems and the impact of threats against them are as follows:

+ Threat T6: DNS software (name server or resolver) could have vulnerabilities such as buffer overflows that result in denial of service.

+ Threat T7: DNS software does not provide adequate access control capabilities for its configuration files (e.g., named.conf), its data files (e.g., zone file) and files containing signing keys (e.g., TSIG, DNSKEY) to prevent unauthorized read/update of these files. These capabilities are provided on top of O/S-file level protection referred to in threats T4 and T5 and may depend upon the latter.

5.3 Threats Due to DNS Data Contents

DNS data is made up of two types: zone files and configuration files. The content of both these types of DNS data has security ramifications. The content of configuration files is an integral component of security deployment options for which this document provides the guidelines. In this document, “threats due to DNS data contents” is only with respect to zone file data and pertains to the following aspects of that data:

+ Parameter values for certain key fields in RRs of various RRTypes

+ Presence of certain RRs in the zone file.

The various types of undesirable contents in the zone file results in different security exposures and consequent potential threats as follows:

+ Threat T8—Lame Delegation: This error occurs when FQDN and/or IP addresses of name servers have been changed in the child zone but the parent zone has not updated the delegation information (NS RRs and glue records). In this situation, the child zone becomes unreachable (denial of service).

+ Threat T9—Zone Drift and Zone Thrash: If the Refresh, and Retry, fields in the SOA RR of the primary name server are set too high and the zone file is changed frequently, there may be a mismatch of data between the primary and secondary name servers. This error is called zone drift; it results in incorrect zone data at the secondary name servers. If the Refresh and Retry fields in the SOA RR are set too low, the secondary server will initiate zone transfers frequently. This error is called zone thrash; it results in more workload on both the primary and secondary name servers. Such incorrect data or increased workload may result in denial of service.

+ Threat T10—Information for Targeted Attacks: RRs such as HINFO and TXT provide information about software name and versions (e.g., for resources such as Web servers and mail servers) that will enable the well-equipped attacker to exploit the known vulnerabilities in those software versions and launch attacks against those resources.

5.4 Security Objectives

Common objectives with respect to protection of the DNS host platform, DNS software, and DNS data are integrity and availability.

5.5 Host Platform Protection Approach

The protection/threat mitigation approaches for the DNS host platform consist of the following:

+ Running a secure OS

+ Secure configuration/deployment of OS.

These approaches are discussed in Section 7.1.

5.6 DNS Software Protection Approach

Best practice protection approaches for DNS software are as follows:

+ Running the latest version of name server software, or an earlier version with appropriate patches

+ Running name server software with restricted privileges

+ Isolating name server software

+ Setting up a dedicated name server instance for each function

+ Removing name server software from nondesignated hosts

+ Creating a topological and geographic dispersion of authoritative name servers for fault tolerance

+ Limiting IT resource information exposure through two different zone files in the same physical name server (termed as split DNS) or through separate name servers for different client classes.

These approaches are described in Sections 7.2.1 through 7.2.8.

5.7 DNS Data Content Control – Protection Approach

Control of undesirable content in the zone file is accomplished by analyzing the contents for security implications, formulating integrity constraints that will check for the presence of such contents and verifying the zone file data for satisfaction of those constraints. Therefore, the only protection approach is to develop the zone file integrity checker software that contains the necessary constraints and can be run against the zone file to flag those contents that violate the constraints. To aid in formulation of constraints, desirable field values (ranges or lists) in the various RRs of zone file are required. These constraints need to be developed not only for RRs in an unsigned zone but also for additional RRs in a signed zone (zones that have implemented the DNSSEC specification). Hence, the recommendations for control of content of zone files are deferred to Section 10 after discussion of deployment guidelines for DNSSEC in Section 9 so that they cover those additional RRs as well.

The services provided by DNS also face threats resulting from vulnerabilities in network infrastructure components such as routers. Network configuration issues are outside the scope of this guidance document, however.

This page has been left blank intentionally.

6. DNS Transactions—Threats, Security Objectives, and Protection Approaches

The threats to a DNS transaction depend on the type of transaction. Name resolution queries and responses (DNS query/response) between DNS clients (stub resolver or resolving name server) and DNS servers (caching/resolving name server or authoritative name server) could involve any nodes in the Internet; hence, the threats against them are much greater in number and severity compared to those for zone transfer, dynamic update, and DNS NOTIFY transactions. In general, the nodes involved in zone transfer, dynamic update, and DNS NOTIFY transactions are all within the administrative domain of a single organization. The only exceptions are instances in which the primary or secondary name servers of an organization are run on its behalf by its ISPs or other organizations. There usually is a preexisting trust relationship in these cases, however, so it is not difficult to set up a mutual authentication system for DNS zone transfers.

6.1 DNS Query/Response Threats and Protection Approaches

DNS name resolution queries and responses (DNS Query/response) generally involve single, unsigned, and unencrypted UDP packets. The known threats to DNS Query/response transactions have been documented in IETF RFC 3833 and can be classified as follows:

+ Threat T11: Forged or bogus response

+ Threat T12: Removal of some RRs from the response

+ Threat T13: Incorrect expansion rules applied to wildcard RRs in a zone file.

6.1.1 Forged or Bogus Response

A forged or bogus response is a response that is different from the one that is expected from a legitimate authoritative name server. A bogus response can originate from:

+ A compromised authoritative name server (for queries originating from a resolving name server)

+ A poisoned cache of a resolving name server (for queries originating from a stub resolver).

An authoritative name server could be compromised by a platform-level attack on its OS or communication stack (see Section 5.1).

The cache of a resolving (caching) name server could be poisoned by the following attacks:

+ Packet Interception. In this type of attack, the attacker eavesdrops on a request and is able to generate and send a response by spoofing an authoritative name server before the real response from the legitimate authoritative name server reaches the resolving name server.

+ ID Guessing and Query Prediction. In this type of attack, the attacker guesses the ID field in the header of the DNS request message (because this field is only 16 bits long, brute force guessing is possible) and possibly the QNAME and QTYPE (owner name and RRType, respectively). The attacker then injects bogus data into the network as a response by spoofing a name server.

+ Responses Accumulated from a Compromised Authoritative Name Server. A compromised authoritative name server is directed by a controlling adversary to send out bogus responses to queries from resolving name servers.

The impacts on a system serviced by a resolving name server that has a poisoned cache are as follows:

+ Denial of Service. If some crucial RRs such as address records (A RRs) are forged, the system that requires this information can never establish connectivity with the intended node.

+ Client Redirection through Cache Poisoning. Client redirection is performed by selective poisoning of DNS RRs whose RDATA element contains a name. Examples of such RRs are CNAME, NS, and MX. The name resolution (i.e., IP address) information for these names is found in a set of additional information (or glue records when discussing a delegation response). Normally the resolving name server obtains these necessary A/AAAA RRs through follow-up queries (also called triggered queries). The responses flowing into the network from these follow-up queries present yet another opportunity for the attacker to insert bogus records. First the attacker can introduce arbitrary names of the attacker’s choosing in the RDATA portion of selected RRs; then the attacker can insert the IP addresses of servers (chosen by the attacker) in associated glue records that are transmitted as an answer to follow-up queries. This type of attack on two sets of related responses is called a name chaining attack. The overall effect of poisoning the cache of a resolving name server this way is to misdirect several clients who are making use of the services of that resolving name server. Redirecting the users to nodes of the attacker’s choosing may enable the attacker to capture sensitive information such as passwords.

6.1.2 Removal of Some RRs

Apart from injecting bogus or forged data in a response, an attacker also could remove RRs from a response. This action might result in a name resolution query failure and consequent denial of service.

6.1.3 Incorrect Expansion Rules Applied to Wildcard RRs

Many zones use wildcard RRs to economize on the volume of data in the zone file. The wildcard patterns are used for synthesizing RRs on the fly in generating responses for name resolution queries. (The synthesis rules are outlined in section 4.3.2 of IETF RFC 1034 [4].)[7] If synthesis rules are applied incorrectly in a name server, the RRs associated with resources existing in an organization may not be generated and made available in a DNS response. This fault also results in denial of service.

6.1.4 Protection Approach for DNS Query/Response Threats—DNSSEC

The underlying feature in the major threat associated with DNS query/response (i.e., forged response or response failure) is the integrity of DNS data returned in the response. Hence, the security objective is to verify the integrity of each response received. An integral part of integrity verification is to ensure that valid data has originated from the right source. Establishing trust in the source is called data origin authentication. Hence, the security objectives—and consequently the security services—that are required for securing the DNS query/response transaction are data origin authentication and data integrity verification.

These services could be provided by establishing trust in the source and verifying the signature of the data sent by that source. The specification for a digital signature mechanism in the context of the DNS infrastructure is in IETF’s DNSSEC standard. The objectives, additional RRs, and DNS message contents involved in the DNSSEC are specified through RFCs 4033, 4034, and 4035. In DNSSEC, trust in the public key (for signature verification) of the source is established not by going to a third party or a chain of third parties (as in public key infrastructure [PKI] chaining), but by starting from a trusted name server (such as the root name server) and establishing the chain of trust down to the current source of response through successive verifications of signature of the public key of a child by its parent. The public key of the trusted name servers is called the trust anchor.

After authenticating the source, the next process DNSSEC calls for is to authenticate the response. This requires that responses consist of not only the requested RRs but also an authenticator associated with them. In DNSSEC, this authenticator is the digital signature of an RRSet. The digital signature of an RRSet is encapsulated through a special RRType called RRSIG. The DNS client using the trusted public key of the source (whose trust has just been established) then verifies the digital signature to detect if the response is valid or bogus.

To ensure that RRs associated with a query are really missing in the zone file and have not been removed in transit, the DNSSEC mechanism provides a means for authenticating the nonexistence of an RR. It generates a special RR called an NSEC RR that lists the RRTypes associated with an owner name as well as the next name in the zone file. It sends this special RR, along with its signature, to the resolving name server. By verifying this signature, a DNSSEC-aware resolving name server can determine which authoritative owner name exists in a zone and which authoritative RRTypes exist at those owner names.

To protect against the threat of incorrect application of expansion rules for wildcard RRs, the DNSSEC mechanism provides a means of comparing the validated wildcard RR against an NSEC RR and thereby verifying that the name server applied the wildcard expansion rules correctly in generating an answer.

DNSSEC can guarantee the integrity of name resolution responses to DNS clients acting on behalf of Internet-based resources, provided the clients perform the DNSSEC signature verification. In many cases, however, these DNS clients are stub resolvers that are not DNSSEC-aware. If signature verification is performed by the resolving name server providing name resolution service for the clients, the end-to-end integrity of the response data can be guaranteed only by protecting the communication channel between the resolving name server and the stub resolver.

IETF’s design criteria consider DNS data to be public; hence, confidentiality is not one of the security goals of DNSSEC. DNSSEC is not designed to directly protect against denial-of-service threats, although it does so indirectly by providing message integrity and source authentication. DNSSEC also does not provide communication channel security because name resolution queries and responses travel over millions of nodes of the public Internet. DNSSEC also can lead to a new type of weakness that did not exist in DNS before. An artifact of how DNSSEC peforms negative responses allows a client to map all the names in a zone. This could be a pretext to an attack, as an attacker can get a “map” of a target zone with all domain names and IP addresses in the zone. Therefore, it is advisable that a zone only contains zone data that the administrator wants to be made public. For internal DNS, something like split-DNS (see Section 7.2.7) could be deployed.

6.2 Zone Transfer Threats and Protection Approaches

Zone transfers are performed to replicate zone files in multiple servers to provide a degree of fault tolerance in the DNS service provided by an organization. Threats from zone transfers have not been documented formally through any IETF RFCs. A few threats could be expected, however: the first threat, denial of service, is common for any network transaction. The second threat is based on exploitation of knowledge gained from the information provided by zone transfers. The third threat is common to any network packet.

+ Threat T14—Denial of Service: Because zone transfers involve the transfer of entire zones, they place substantial demands on network resources relative to normal DNS queries. Errant or malicious frequent zone transfer requests on the name servers of the enterprise can overload the master zone server and result in denial of service to legitimate users.

+ Threat T15—The zone transfer response message could be tampered.

The denial-of-service can be minimized if servers allowed to make zone transfer requests are restricted to a set of known entities. To configure this restriction into the primary name server, there should be a means of identifying those entities. Name server software such as BIND initially provided a configuration feature to restrict zone transfer requests to a set of designated IP addresses. Because IP addresses can be spoofed, however, this mode of configuration does not provide an adequate means of restricting zone transfer access.

The IETF developed an alternate mechanism called a transaction signature (TSIG), whereby mutual identification of servers is based on a shared secret key. Because the number of servers involved in zone transfer is limited (generally restricted to name servers in the same administrative domain of an organization), a bilateral trust model that is based on a shared secret key may be adequate for most enterprise (except for very large ones). TSIG specifies that the shared secret key be used not only for mutual authentication but also for signing zone transfer requests and responses. Hence, it provides protection against tampering of zone transfer response messages (threat T15). Protection of DNS data alone (the payload) in a zone transfer message also can be ensured through verification of signature records accompanying RRs from a DNSSEC-signed zone. These signatures, however, do not cover all the information in a zone file (e.g., delegation information). Furthermore, they enable verification of only the individual RRsets and not the entire zone transfer response message.

There is also another method to authenticate DNS transactions by using asymmetric cryptography (i.e. public key cryptography). The format of the SIG(0) RR is similar to the resource record signature (RRSIG) RR (see Section 9.1.1), and can be validated using a public key stored in the DNS (instead of a shared secret key). SIG(0) can be more computational expensive to use, but offer an advantage in that a previous trust relationship may not be necessary to use SIG(0) signed messages. However, since most zone transfers occur between parties that have a previously established relationship, it is considered easier to implement TSIG for authenticating zone transfer transactions.

6.3 Dynamic Updates Threats and Protection Approaches

Dynamic updates involve DNS clients making changes to zone data in an authoritative name server in real time. Clients typically performing dynamic updates are CA servers, DHCP servers, or Internet Multicast Address servers. As with zone transfer transaction, the threats associated with dynamic update transaction have not been officially documented by the IETF through an RFC. The following are some common threats that could be expected, based on the fact that dynamic updates involve a data update request transiting a network.

+ Threat T16—Unauthorized Updates: Unauthorized updates could have several harmful consequences for the content of zone data. Some harmful data operations include: (a) adding illegitimate resources (new FQDN and new RRs to a valid zone file), (b) deleting legitimate resources (entire FQDN or specific RRs), and (c) altering delegation information (NS RRs pointing to child zones).

+ Threat T17: The data in a dynamic update request could be tampered.

+ Threat T18—Replay Attacks: Update request messages could be captured and resubmitted later, thus causing inappropriate updates.

Threats T16 and T17 could be countered by authenticating the entities involved and providing a means to detect tampering of the messages. Because these security objectives in the case of zone transfer are met by the TSIG/SIG(0) mechanism, the same TSIG/SIG(0) mechanism is specified for protecting dynamic updates. Although the dynamic update message contains some replay attack (Threat T18) protection in the prerequisite field of the message, TSIG/SIG(0) provides an additional mechanism to protect against replay attacks by including a timestamp field in the dynamic update request. This signed timestamp enables a server to determine whether the timing of the dynamic update request is within the acceptable time limits specified in the configuration.

It sometimes makes more sense to use SIG(0) protection mechanisms for dynamic update than for zone transfer. Dynamic update transactions may happen between parties that do not always have a prior security relationship or may be part of a bootstrapping operation. Therefore it may be impractical to use TSIG with a shared secret, but SIG(0) authentication using keys stored in the DNS may be a possibility.

6.4 DNS NOTIFY Threats and Protection Approaches

DNS NOTIFY is a message sent by primary (master) name servers to secondary (slave) name servers, causing the secondary servers to start a refresh operation (i.e. query for SOA RR to check the serial number, etc.) and perform a zone transfer if an update to the zone has occurred. Because the NOTIFY message is only a signal, there are only minor security risks in dealing with the message. The primary security risk to consider is the following:

+ Threat T19—Spurious NOTIFY Messages: Secondary name servers would receive spurious DNS NOTIFY messages from sources other than the primary name server.

The only impact of receiving spurious DNS NOTIFY message is the increase in workload in secondary name servers since a zone transfer will only occur when an updated zone is on the primary server. Because this threat is low impact, the only protection approach required is to configure the secondary name servers to receive DNS NOTIFY message only from the enterprise’s primary name server. However, if TSIG is set up for use for all communication between a set of hosts, TSIG will be used with NOTIFY messages as well.

6.5 Threats Summary

Table 6-1 summarizes the DNS transactions and their associated threats, security objectives, and IETF security mechanism specifications to meet those goals.

Table 6‑1. DNS Transaction Threats and Security Objectives

DNS Transaction	Threats	Security Objectives	IETF Security Specifications
DNS Query/Response	(a) Forged or bogus response (b) Removal of records (RRs) in responses (c) Incorrect application of wildcard expansion rules	(a) Data origin authentication (b) Data integrity verification	DNSSEC
Zone Transfer	(a) Denial of service (b) Tampering of messages	(a) Mutual authentication (b) Data integrity verification	TSIG
Dynamic Update	(a) Unauthorized Updates (b) Tampering of messages (c) Replay attack	(a) Mutual authentication (b) Data integrity verification (c) Signed timestamps	TSIG or SIG(0)
DNS NOTIFY	(a) Spurious notifications	(a) To prevent denial of service through increase in workload	Specify hosts from which this message can be received TSIG or SIG(0)

This page has been left blank intentionally.

7. Guidelines for Securing DNS Hosting Environment

The guidelines for secure configuration of the DNS hosting environment are classified under the following headings:

+ Securing DNS host platform

+ Securing DNS software

+ Content control of zone file.

This section makes recommendations for each class.

7.1 Securing DNS Host Platform

The platform on which the name server software runs should be hosted on a secure OS. Most of the DNS installations run either on a flavor of Unix or Windows. Given this scenario, it is necessary to ensure the following:

+ The latest OS patches are installed.

+ Recommended OS configuration practices as issued by CERT^®/CC [17] based on identified vulnerabilities [18] that pertain to the application profile into which the name server software fits are followed. In particular, hosts that run the name server software should not provide any other services and therefore should be configured to respond to DNS traffic only. In other words, the only allowed incoming and outgoing messages to these hosts should be 53/udp and 53/tcp.

7.2 Securing DNS Software

Protection approaches for DNS software include choice of version, installation of patches, running it with restricted privileges, restricting other applications in the execution environment, dedicating instances for each function, controlling the set of hosts where software is installed, placement 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.

7.2.1 Running the Latest Version of Name Server Software

Each newer version of the name server software, especially the BIND software, generally is devoid of vulnerabilities found in earlier versions because it has design changes incorporated to take care of those vulnerabilities. Of course, these vulnerabilities have been exploited (i.e., some form of attack was launched), and sufficient information has been generated with respect to the nature of those exploits. Thus, it is a good practice to run the latest version of the BIND software because theoretically it is the safest version. Even if the software is the latest version, it is not safe to run it in default mode. The security administrator should become familiar with the new security settings for the latest version.

In some installations, it may not be possible to switch over to the latest version of the BIND software immediately. In these situations, the administrator should keep pace with vulnerabilities identified in the operational version and associated security patches [19].

Checklist item 1: When installing the upgraded version of name server software, the administrator should make necessary changes to configuration parameters to take advantage of new security features.

Checklist item 2: Whether running the latest version or an earlier version, the administrator should be aware of the vulnerabilities, exploits, security fixes, and patches for the version that is in operation in the enterprise. The following actions are recommended:

– Subscribe to ISC’s mailing list called “bind-announce”

– Periodically refer to the BIND vulnerabilities page at http://www.isc.org/products/BIND/bind-security.html

– Refer to CERT^®/CC’s Vulnerability Notes Database at http://www.kb.cert.org/vuls/ and the NIST NVD metabase at http://nvd.nist.gov/.

7.2.2 Turning off the BIND Version Query

There is a feature in BIND that returns the version number of the server daemon running if a special query is sent to the server. This query is for the string “version.bind” with query type TXT and query class Chaos (CH). This information may be of use to attackers who are looking for a specific version of BIND with a discovered weakness. BIND can be configured to refuse this type of query by having the following command in the BIND configuration file (/etc/named.conf).

options {

version none;

};

Checklist item 3: To prevent information about which version of BIND is running on a system, name servers should be configured to refuse queries for “version.bind”.

7.2.3 Running Name Server Software with Restricted Privileges

If the name server software is run as a privileged user (e.g., root in Unix systems), any break-in into the software can have disastrous consequences in terms of resources resident in the name server platform. Specifically, a hacker who breaks into the software acquires unrestricted access and therefore can potentially execute any commands or modify or delete any files. Hence, it is necessary to run the name server software as a nonprivileged user with access restricted to specified directories to contain damages resulting from break-in.

The user name under which the name server software needs to run can be specified by using the chroot command in BIND. This is why this approach is known as running the DNS server in a chroot jail. An example command (entered on the command line) is the following:

chroot -u named –g other –t /var/named

where the options specify the following:

–u specifies the userID to which the name server software will change after starting. This user account should be created prior to issuing the chroot command.

–g is the groupID to which the userID should be assigned. If –g is unspecified, the name server will run under the userID’s primary group.

–t specifies the directory in which the name server software owner will have privileges.

7.2.4 Isolating the Name Server Software

Even if the DNS software (e.g., BIND) is run on a secure OS, the vulnerabilities of other software programs on that platform can breach the security of DNS software. Hence, it is necessary to ensure that the platform on which the DNS software runs contains no programs other than those needed for OS and network support.

7.2.5 Dedicated Name Server Instance for Each Function

An authoritative name server serves RRs from its own zone file; this function is called an authoritative function. Serving RRs either from its cache (directly or by building up its cache dynamically through iterative queries) is called a resolving function; this is how a resolving name server provides responses. A name server instance can be configured as an authoritative name server, a resolving name server, or both. Because of attacks such as cache poisoning (see Section 6.1), however, a resolving name server has to be run under security policy that is different from that of an authoritative name server. Hence, a name server instance should always be configured as either an authoritative name server or a resolving name server.

An authoritative name server is only intended to provide name resolution for the zones for which it has authoritative information. Hence, the security policy should have recursion turned off for this type of name server. Disabling recursion prevents an authoritative name server from sending queries on behalf of other name servers and building up a cache using responses. Disabling this function eliminates the cache poisoning threat. In BIND, recursion is disabled by using the options statement in the BIND configuration file as follows:

options {
recursion no;
};

A resolving name server is only intended to provide resolving services (processing resolving queries on behalf of clients) for internal clients. Thus, protection of resolving name servers can be ensured by restricting their types of interactions (also called transactions) to designated hosts through various configuration options in the configuration file of the name server software.

7.2.6 Removing Name Server Software from Nondesignated Hosts

DNS software should not be running or present in hosts that are not designated as name servers. The possibility arises in the case of DNS BIND software because of the fact that many versions of Unix (including Solaris and Linux versions) come installed with BIND as default. Hence, while taking an inventory of software in workstations and servers of the enterprise as part of the security audit, it is necessary to look for BIND installations and remove them from hosts that are not functioning as name servers.

7.2.7 Network and Geographic Dispersion of Authoritative Name Servers

Most enterprises have an authoritative primary server and a host of authoritative secondary name servers. It is essential that these authoritative name servers for an enterprise be located on different network segments. This dispersion ensures the availability of an authoritative name server not only in situations in which a particular router or switch fails but also during events involving an attack on an entire network segment. In addition to network-based dispersion, authoritative name servers should be dispersed geographically as well. In other words, in addition to being located on different network segments, the authoritative name servers should not all be located within the same building. One approach that some organizations follow is to locate some authoritative name servers in their own premises and others in their ISPs’ data centers or in partnering organizations.

Checklist item 4: The authoritative name servers for an enterprise should be both network and geographically dispersed. Network-based dispersion consists of ensuring that all name servers are not behind a single router or switch, in a single subnet, or using a single leased line. Geographic dispersion consists of ensuring that not all name servers are in the same physical location, and hosting at least a single secondary server off-site.

7.2.8 Limiting Information Exposure through Partitioning of Zone files

Authoritative name servers for an enterprise receive requests from both external and internal clients. In many instances, external clients need to receive RRs that pertain only to public services (public Web server, mail server, etc.) Internal clients need to receive RRs pertaining to public services as well as internal hosts. Hence, the zone information that serves these RRs can be split into different physical files for these two types of clients: one for external clients and one for internal clients. This type of implementation of the zone file is called split DNS.

Split DNS does have some drawbacks. First, remote hosts (travelers using laptops to connect back to an organization, for example), may not be using an intenal resolving DNS server, and therefore may not be able to see internal hosts. Second, internal host information may leak to outside the firewall (by accident or attack), defeating the purpose of having a split DNS, or causing confusion of an internal and external host have the same FQDN, but different IP addresses. Split DNS should not be seen as a replacement for proper access control techniques.

Checklist item 5: For split DNS implementation, there should be a minimum of two physical files or views. One should exclusively provide name resolution for hosts located inside the firewall. It also can contain RRsets for hosts outside the firewall. The other file or view should provide name resolution only for hosts located outside the firewall or in the DMZ, and not for any hosts inside the firewall.

To set up split DNS using BIND, the view statement is used in the BIND configuration file. For example, to set up an authoritative view of the zone “sales.mycom.com” for internal clients:

view “insider” {
     match-clients { internal_hosts; };
     recursion no;
     zone sales.mycom.com {
           type master;
           file “sales_internal.db”;
     };
};

In this statement, the file “sales_internal.db” contains the authoritative information for zone “sales.mycom.com” and restricts that information to queries coming from the address list named “internal_hosts”. See Section 8.1.1 provides details on how to set up this list. To set up a view of the same zone, but with only external hosts for queries coming from outside the network, the following view statement is used in the same configuration file:

view “outsider” {
     match-clients { any; };
     match-destinations { public_hosts; };
     recursion no;
     zone sales.mycom.com {
           type master;
           file “sales_external.db”;
     };
};

This statement is very similar to the previous statement, except that the file with the zone view is “sales.external.db” and the client list is given as “any”, meaning that queries coming from both outside and inside the network can see the same external view of “sales.mycom.com.” Together, these statements allow internal clients to view both the internal and external hosts in “sales.mycom.com,” whereas external hosts (not on the same network) can see only DNS information contained in the external view of the zone where the destination matches the address list “public_hosts.”

7.2.9 Limiting Information Exposure Through Separate Name Servers for Different Clients

Instead of having the same set of authoritative name servers serve different types of clients, an enterprise could have two different sets of authoritative name servers. One set, called external name servers, can be located within a DMZ; these would be the only name servers that are accessible to external clients and would serve RRs pertaining to hosts with public services (Web servers that serve external Web pages or provide B2C services, mail servers, etc.) The other set, called internal name servers, is to be located within the firewall and should be configured so they are not reachable from outside and hence provide naming services exclusively to internal clients. The purpose of both architecture options (i.e., two different sets of name servers and split DNS) is to prevent the outside world from knowing the IP addresses of internal hosts. This configuration may be the only available option for enterprises that use DNS server software that does not have the view feature found in BIND.

7.3 Content Control of Zone File

As stated in Section 5.7, the only protection approach for content control of DNS zone file is the use of a zone file integrity checker. The effectiveness of integrity checking using a zone file integrity checker depends upon the database of constraints built into the checker. Hence, the deployment process consists of developing these constraints with the right logic and the only determinant of the truth value of these logical predicates are the parameter values for certain key fields in the format of various RRTypes. The choice of these parameter values forms the deployment guidelines and is discussed in Section 10.

7.4 Recommendations Summary

The following items provide a summary of the major recommendations from this section:

+ Checklist item 1: When installing the upgraded version of name server software, the administrator should make necessary changes to configuration parameters to take advantage of new security features.

+ Checklist item 2: Whether running the latest version or an earlier version, the administrator should be aware of the vulnerabilities, exploits, security fixes, and patches for the version that is in operation in the enterprise. The following actions are recommended:

– Subscribe to ISC’s mailing list called “bind-announce”

– Periodically refer to the BIND vulnerabilities page at http://www.isc.org/products/BIND/bind-security.html

– Refer to CERT^®/CC’s Vulnerability Notes Database at http://www.kb.cert.org/vuls/ and the NIST NVD metabase at http://nvd.nist.gov/.

+ Checklist item 3: To prevent information about which version of BIND is running on a system, name servers should be configured to refuse queries for “version.bind”.

+ Checklist item 4: The authoritative name servers for an enterprise should be both network and geographically dispersed. Network-based dispersion consists of ensuring that all name servers are not behind a single router or switch, in a single subnet, or using a single leased line. Geographic dispersion consists of ensuring that not all name servers are in the same physical location, and hosting at least a single secondary server off-site.

+ Checklist item 5: For split DNS implementation, there should be a minimum of two physical files or views. One should exclusively provide name resolution for hosts located inside the firewall. It also can contain RRsets for hosts outside the firewall. The other file or view should provide name resolution only for hosts located outside the firewall or in the DMZ, and not for any hosts inside the firewall.

8. Guidelines for Securing DNS Transactions

Section 6 outlines threats, security objectives, and protection approaches for various DNS transactions. This section provides the steps involved in implementing those approaches, as well as operational best practices that go with those implementations. The protection approaches in Table 6-1 are aggregated, indexed by type of approach, and elaborated here as follows:

+ Restricting Transaction Entities Based on IP Address. In this type of implementation, the DNS name servers and clients participating in a DNS transaction are restricted to a trusted set of hosts by specifying their IP addresses in appropriate access control statements provided by the name server software. The protection provided by these IP-based access control statements can be circumvented by attacks such as IP spoofing. Hence, this solution is not recommended for DNS query/response, zone transfer, and dynamic update transactions that have high threat impact. However, for the DNS NOTIFY transaction, where the only threat is spurious notification (which may not even trigger a zone transfer), an access control based on IP address will suffice. Although this solution is not recommended generally, a description of the mechanics of access control using IP addresses is provided in Section 8.1 because the same statements are used to identify hosts based on named keys while implementing transaction protection using hash-based message authentication codes. This approach has been implemented for all DNS transactions.

+ Transaction Protection through Hash-Based Message Authentication Codes (TSIG Specification). In this approach, transaction protection is enabled through generation and verification of hash-based message authentication codes (HMAC). Because these codes are embedded within a special RR of RRType TSIG, the specifications that outline protection of DNS transactions using HMAC are called TSIG in the DNS community. TSIG specifications are described in RFC 2845 and 3007. Application of TSIG specifications for protection of zone transfer and dynamic update transactions is described in Section 8.2.

+ Transaction Protection through Asymmetric Digital Signatures (DNSSEC Specification). This approach, which goes by the name DNS security extensions (DNSSEC), is described through a family of RFCs (RFC 4043, 4044, and 4045). The core services provided by DNSSEC are data origin authentication and integrity protection. DNSSEC is used mainly for securing DNS information obtained from DNS query/response transactions. The deployment issues in DNSSEC are described in Section 9.

8.1 Restricting Transaction Entities Based on IP Address

Some DNS name server implementations, such as BIND 9.x, provide access control statements through which it is possible to specify hosts that can participate in a given DNS transaction. The hosts can be identified by their IP address or IP subnet reference (called IP prefix) in these statements.

The list containing these IP addresses and/or IP prefixes is called an address match list. (An address match list can be made up of other things besides IP addresses and IP prefixes, as described in Section 8.1.1). The address match list is used as an argument in various access control statements that are available for use in BIND configuration files. There are separate access control statements for each type of DNS transaction. The syntax of the various access control statements and the DNS transaction for which each is used are given in Table 8.1.

Table 8‑1. Access Control Statement Syntax for DNS Transactions

Access Control Statement Syntax	DNS Transaction
allow-query { address_match_list }	DNS Query/Response
allow-recursion { address_match_list }	Recursive Query
allow-transfer { address_match_list }	Zone Transfer
allow-update { address_match_list }	Dynamic Update
allow-update-forwarding { address_match_list }	Dynamic Update
allow-notify { address_match_list }	DNS NOTIFY
blackhole { address_match_list }	Blacklisted Hosts

The purpose of each of these access control statements is as follows:

+ allow-query: specifies the list of hosts allowed to query the name server as a whole or a particular zone within the name server

+ allow-recursion: specifies the list of hosts allowed to submit recursive queries to the name server as a whole or to a particular zone served by the name server

+ allow-transfer: specifies the list of hosts allowed to initiate zone transfer requests to the name server as a whole or to a particular zone within the name server. This statement is predominantly required for configuration of master name servers.

+ allow-update: specifies the list of hosts allowed to initiate dynamic update requests

+ allow-update-forwarding: specifies the list of hosts allowed to forward dynamic update requests (regardless of the originator of the requests)

+ allow-notify: specifies the list of hosts from which to accept DNS NOTIFY messages indicating changes in the zone file. This list is relevant only for configuration of secondary slave name servers.

+ blackhole: specifies the list of hosts that are blacklisted (barred) from initiating any transaction with this name server. Used only in an “options” server wide ACL statement.

The foregoing access control statements are, in fact, substatements that can be used in the context of options and zone statements in the BIND 9.x configuration file (with the exception of blackhole). When they are used within the zone statement, they specify access control restrictions for the corresponding DNS transaction for that specific zone. When they are used as part of the options statement, they specify access control restrictions for the corresponding DNS transaction for the name server as a whole (because a name server could host multiple zones).

8.1.1 Restricting DNS Query/Response Transaction Entities

An example of the usage of the allow-query substatement (to specify restrictions for the DNS query/response transaction stating the IP addresses/subnets from which DNS queries are accepted) both at the server level and at the zone level (for the zone example.com) is given below :

options {
allow-query { 254.10.20.10; 239.10.30.29/25; };
};

zone “example.com.” {
     type master;
     file “zonedb.example.com”;
     allow-query { 192.249.249.1; 192.249.249.4; };
};

Specifying the list of IP addresses and IP prefixes within the options and zone statements could clutter the configuration file. Furthermore, the list of IP addresses and IP prefixes could be the same for many of the access control statements within a name server, and errors could be introduced if any additions or subtractions are made for that list. To avoid these problems, BIND provides a means to create named address match lists, which are called access control lists (ACL). These ACLs can be used in place of the list of IP addresses/IP prefixes (in the address match list argument) in the access control statements.

The ACLs are created by using the acl statement in BIND 9.x. The general syntax of the acl statement is as follows:

acl acl-list-name {
address_match_list
};

The acl-list-name is a user-defined string (e.g., internal_hosts). The address_match_list can be a list of IP addresses, IP address prefixes (denoting subnets), or cryptographic keys. An example of an acl statement that uses an IP address and a subnet reference in address_match_list is given below. In the example, 254.10.20.10 denotes the IP address of a host, and the IP prefix 239.10.30.0/24 denotes a class C subnet.

acl “internal_hosts” {
254.10.20.10;
239.10.30.0/24;
};

The use of ACL – “internal_hosts” in place of the list of IP addresses/IP prefix in the options and zone statement given above is as follows:

options {
allow-query { internal_hosts; };
};

zone “example.com.” {
     type master;
     file “zonedb.example.com”;
     allow-query { internal_hosts; };
};

The address match list parameter in an access control statement can contain any of the following values:

+ An IP address or list of IP addresses

+ An IP prefix or list of IP prefixes

+ ACLs

+ A combination of the above three.

The definition of ACLs forms a critical element in the configuration of DNS transaction restrictions. Hence, it is a good operational practice for the DNS administrator to define and create ACLs pertaining to different DNS transactions.

Checklist item 6: It is recommended that the administrator create a named list of trusted hosts (or blacklisted hosts) for each of the different types of DNS transactions. In general, the role of the following categories of hosts should be considered for inclusion in the appropriate ACL:

– DMZ hosts defined in any of the zones in the enterprise

– All secondary name servers allowed to initiate zone transfers

– Internal hosts allowed to perform recursive queries.