An Integrity Verification Scheme for DNS Zone file based on Security Impact Analysis Ramaswamy Chandramouli Scott Rose NIST, Gaithersburg, MD 20899 NIST, Gaithersburg, MD 20899 ([email protected]) [email protected] Abstract a query every time it receives a request from an application that requires Internet service (e.g., a The Domain Name System (DNS) is the world’s browser). The other type is called a caching (also largest distributed computing system that performs the called recursive/resolving) name server that caches the key function of translating user-friendly domain names name resolution responses it has obtained from to IP addresses through a process called name authoritative name servers and thus able to serve resolution. After looking at the protection measures multiple stub resolvers. for securing the DNS transactions, we discover that The zone file hosted on an authoritative name the trust in the name resolution process ultimately server consists of various types of records called depends upon the integrity of the data repository that Resource Records (RRs). Associated with each DNS authoritative name servers of DNS use. This data resource record is a type (RRtype). The code for these repository is called a zone file. Hence we analyze in RRtypes is assigned by an international organization detail the data content relationships in a zone file that called Internet Assigned Names Authority (IANA). An have security impacts. We then develop a taxonomy RR of a given RRtype in a zone file provides a and associated population of constraints. We also specific type of information. Some of the common have developed a platform-independent framework RRtype codes are: NS, MX and A. An NS RR in a using XML, XML Schema and XSLT for encoding zone file gives the fully qualified domain name those constraints and verifying them against the XML (FQDN) of the host that is considered the name server encoded zone file data to detect integrity violations. for that zone. For example, an NS RR in the zone file of the zone example.com gives the information that the host ns1.projects.example.com is a name server for 1. Introduction the domain projects.example.com. Similarly an MX RR gives the host name for a mail server for the zone. The domain name system (DNS) is the world’s An A RR gives the IP address for a host in a domain largest distributed computing system that enables within the zone. A zone file generally consists of access to any resource in the Internet by translating multiple RRs of a given RRtype with some exceptions user-friendly domain names to IP Addresses. The (e.g., there can be only SOA RR in a zone file). It can process of translating domain names to IP Addresses also have multiple RRs for the same domain name and is called Name Resolution. A DNS name resolution is same (or different) RRtype (e.g., multiple name the first step in the majority of Internet transactions. servers or mail servers for a domain say The DNS is in fact a client server system that provides services.example.com). this name resolution service through a family of The DNS infrastructure consists of many different servers called Domain Name Servers. The hierarchical types of DNS servers, DNS clients and transactions domain space is divided into administrative units among/between these entities. The most important called zones. A zone usually consists of a domain (say transaction in DNS is the one that provides the core example.com) and possibly one or more sub domains service of DNS (i.e., name resolution service) and is (projects.example.com, services.example.com). The called the DNS Query/Response. A DNS authoritative data needed for performing the name Query/Response transaction is made up of a query resolution service is contained in a file called the zone originating from a DNS client (generically called a file and the DNS servers hosting this file are called the DNS resolver) and response from a DNS name server. authoritative name servers for that zone. The DNS The response consists of one or more RRs. These RRs clients that make use of the services provided by may be served from its own zone file (for an authoritative name servers could be of two types. One authoritative name server) or from a cache of RRs type is called a stub resolver that formulates and sends obtained from other name servers (for a caching/resolving/recursive name servers). In this order for DNSSEC to be effective and the data to be way, the DNS basically serves as a global, distributed usable by clients, the original DNS data must be database. Name servers (serving zone files) each correct. contain a small portion of the global domain space, This original data is the one found in zone files of and clients issue queries using a domain name and a authoritative name servers. The overall trust in DNS desired RRtype. depends upon the integrity of the zone file data. The The DNS Query/Response transaction, just like integrity of zone file data, in the context of this paper, any other Internet-based transaction, is subject to pertains to the content satisfying certain relationship several types of attacks such as spoofing and man-in- constraints. It has nothing to do with the traditional the-middle attacks. DNS is especially vulnerable to concept of file integrity which is verified by matching these types of attacks because the basic an archived hash with the hash of the file generated on Query/Response transaction uses UDP as the the fly. Therefore, to discover the exact consequences transport. This makes it easier for an attacker to of the zone file integrity on the trust of DNS name intercept DNS message packets and alter any of the resolution service, it is necessary to perform a detailed information contained therein. An attacker could analysis of the zone file content relationships. Hence redirect Internet traffic from a host (or collection of the first of two major contributions of this paper is to hosts) in this manner. To provide protection from perform this analysis and develop a taxonomy and these attacks, it is necessary to verify that a DNS associated population of zone file integrity constraints. response has originated from an authentic source (the The second major contribution of this paper is to responding name server is indeed the one that is develop a framework for verifying a zone file for supposed to respond), the response is complete and satisfaction of these constraints and has not been tampered with on transit (integrity of the detecting/identifying violations of these integrity response is maintained). The protection requirements constraints. Towards this objective, we developed a of origin authentication and integrity verification are schema of the zone file using XML Schema [12]. We needed not only for responses originating from call this schema – “Zone File Schema”. The associated authoritative name servers but also from the cache of XML encoded Zone file is called “XML encoded resolving/recursive name servers. Zone File Data”. The integrity checks (procedural To provide these security services of data origin statement of constraints) needed for any zone file are authentication and integrity verification to DNS encoded as XSLT [13] constraints. The XSLT responses, IETF has proposed a set of security constraints are based on the Zone File Schema and can extensions to DNS collectively called DNSSEC be applied to verify the integrity of any XML encoded through a series of RFCs [8,9,10]. These DNSSEC zone file whose structure is based on Zone File specifications call for generating a digital signature Schema. A useful by product of this framework is the (stored in a new RRtype called RRSIG) for every ability to programmatically generate zone files using RRset in a zone ( a set of RRs of a given RRtype is XSLT transforms on the integrity-checked XML called an RRset) using a private key associated with encoded zone file data. the zone and then publishing the corresponding public The overall organization of this paper is as key (stored in a DNSKEY RR). This will then enable a follows. A brief description of the common data recipient of the DNS response (i.e., the DNS resolver structure of any RR and information and functionality on the client side) to verify the integrity of the RRs in provided by the original DNS RRs and DNSSEC RRs a response using the public key and the signature of are given in section 2. Section 3 builds up the case for RRsets (contained in a RRSIG RR) sent along with it integrity verification of DNS based on analysis of data in the DNS response. For discussion purposes, we will content relationships that have security impacts. call the RRs of these additional types as DNSSEC RRs Section 4 presents the taxonomy and a set of and the original RRs as simply DNS RRs. associated integrity constraints. Sections 5 and 6 However, these new types only provide the ability describe the framework for automated integrity for clients to authenticate the origin of the DNS data verification of DNS zone file. Specifically, in section (i.e. the authoritative source for the zone data) and the 5, we deal with the development of an XML Schema integrity of the data in transit. This is to counter an for the zone file and an XML encoding of an example attacker redirecting Internet traffic by altering the data zone file that corresponds to this schema. Based on the in a DNS response in transit, or in the cache of a XML Schema, XSLT constraints that encode the caching, recursive name server.