Domain Name System (DNS) is the system for the mapping between easily memorizable host names and their IP addresses. Due to its criticality, the Internet Engineering Task Force (IETF) has defined a DNS Security Extension (DNSSEC) to provide data-origin authentication. In this paper, we point out two drawbacks of the DNSSEC standard in its handling of DNS dynamic updates: 1) the on-line storage of a zone security key, creating a single point of attack for both inside and outside attackers, and 2) the violation of the role separation principle, which in the context of DNSSEC requires the separation of the roles of zone security managers from DNS name server administrators. To address these issues, we propose an alternative secure DNS architecture based on threshold cryptography. Unlike DNSSEC, this architecture adheres to the role separation principle without presenting any single point of attack. To show the feasibility of the proposed architecture, we developed a threshold cryptography toolkit based on the Java Cryptography Architecture (JCA) and built a proof-of-concept prototype with the toolkit. Our running results of the prototype on a representative platform show that the performance of our proposed architecture ranges from one to four times of DNSSEC’s performance. Thus, through small performance overhead, our proposed architecture could achieve very high level of security.
TopIntroduction
The Domain Name System (DNS) is a distributed database used in the Internet to map easily memorizable host names to their respective IP addresses (Mockapetris, 1987a, 1987b; Mockapetris & Dunlap, 1986, 1988, 1995).The DNS name space is organized into a hierarchy. Top-level domains include .com, .edu, .org, .biz, .info, .mil, .gov, .net, two-letter country codes like .ae and .jo (Postel, 1994). Second-level domain names typically designate individual institutions. For instance, Google Inc. is assigned a second-level domain name “google” under the top-level domain .com. In the domain name hierarchy, the subspace that is under a single administrative control is called a “zone.” In each zone, several predefined resources can be associated with a given domain name. Two example domain name resources are IP address and mail exchange server. The association of a domain name with a resource is called a resource record (RR). The most important RR of a domain name is the “type A” RR, which contains the host IP address of the domain name. All the RRs within a zone are stored in a master file to be published by the primary name server of that zone. Each zone also supports zero or more secondary name servers, which obtain RRs from the primary server. Secondary servers act as backup of the primary name server and can also reduce the workload of the primary server; they send appropriate RRs to clients in response to queries but are not involved in the maintenance of the master file.
Unfortunately, the DNS, a critical infrastructure component of the Internet, was designed without security considerations. In particular, the original DNS architecture provides no way for a client to authenticate a received RR. This loophole enables many security attacks (Bellovin, 1995; Schuba, 1993; Vixie, 1995). For example, an attacker in the middle can modify a DNS response to include a fake RR. By providing an incorrect IP address for the requested domain name (for instance, www.ebay.com), a malicious third party could cause the loss of business to the domain name owner (eBay Inc. in the example).
In response to the above concerns, the DNS Security Extension (DNSSEC) was developed by the Internet Engineering Task Force (IETF) (Arends, Austein, Larson, Massey, & Rose, 2005a, 2005b, 2005c). Throughout this article we use the terms IETF DNSSEC and DNSSEC interchangeably. The DNSSEC provides RR authentication by the use of digital signatures (Diffie & Hellman, 1976; Rivest, Shamir, & Adleman, 1978). With DNSSEC, each zone is equipped with a public/private key pair. Resource records of a zone with the same name are organized into RR sets (RRset) and the zone private key is used to digitally sign all the RRsets in that zone. For each RRset, its digital signature is stored in a newly defined resource record called “RRSIG RR.” The response to a DNS query comprises the requested RRsets and the corresponding RRSIG RR. The zone public key is disseminated through DNSKEY RR, a new RR defined by DNSSEC, and DNS clients use this key to verify RRSIG RRs. (Obviously, a zone’s DNSKEY RR should be also authenticated and this is accomplished by a corresponding RRSIG RR by its parent zone.)