Internet Engineering Task Force J. Zhang Internet-Draft L. Ren Intended status: Informational L. Li Expires: September 2, 2012 China Mobile Mar 2012 DNS-Test-Result draft-zhang-dnsext-test-result-00 Abstract This document introduces performance test results of DNS, and makes some analysis about the test results. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 2, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Zhang, et al. Expires September 2, 2012 [Page 1] Internet-Draft TEST-RESULT Mar 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Description of the test environment . . . . . . . . . . . . . . 3 2.1. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Hardware and Hardware . . . . . . . . . . . . . . . . . . . 4 2.3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Analysis of test results . . . . . . . . . . . . . . . . . . . 4 4. Suggestion . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Zhang, et al. Expires September 2, 2012 [Page 2] Internet-Draft TEST-RESULT Mar 2012 1. Introduction This document discusses some tests and the test results on the performance of recursive DNS. Firstly, tests on plain recursive DNS is done. Secondly, tests on recursive DNS with sortlist enabled is done. Finally, tests on recursive DNS with DNSSec enabled is done. Section 2 describes the test environment. Section 3 lists the test result with some analysis. Section 4 gives some suggestions. 2. Description of the test environment +----------------+ . +----+ |Recursive Server| // |Root| +-------.--------+ // +----+ || // || // +-----------------+ +---.----------. +----+ |Request generator|----------.| Switch |-------.|.com| | |.--------- | |.------ | | +-----------------+ +------.-------+ +----+ || || +----------.-------------+ |xxx.com(1.com~60000.com)| +------------------------+ Figure 1: topology of the test 2.1. Topology The test simulated a complete recursive request-response procedure in a closed network, there are four servers needed at least: one recursive server and three Authoritative servers. As Figure 1 describes, there are four servers in the topology, implementing the recursive server role, the root server role, the .com top level domain server role and the xxx.com domain server role. The xxx.com domain server is responsible for resolving the DNS requests from 1.com to 60000.com. Besides the four servers, there are also a switch and a request generator in the topology. The requests generator simulated many clients with different ip addresses. It can also generate requests as configured and send them to the switch which acts as a gateway to transfer requests and responses between the recursive server and the clients. Zhang, et al. Expires September 2, 2012 [Page 3] Internet-Draft TEST-RESULT Mar 2012 2.2. Hardware and Hardware All the servers concluded in the test are assembled with 2 CPUs with 8 core in each other and 8GB RAM. All the network interfaces between the server and the switch are 100/1000Base-T so that time between each request and response will be less than 4ms. All the servers in the test are installed with BIND as DNS software and configured as the correct roles as mentioned, the version of which is BIND 9.8.1-p1. As Figure 1 describes, there are 60000 zones (1.com~60000.com), each of which is made of a SOA record, a A record and a NS record, configured in the xxx.com domain name server. All the zones are divided into two parts: the cache and recursive. The Time-to-live value of each record of the cache part will be 86400 so that the record will be alive all the time in the cache of the recursive server until the test is over, while the value of the recursive part will be just 1 so that the record will be moved out from the cache in a second. At last, the cache size of the recursive server is configured to 10MB, which can accomodate all the cache part. 2.3. Data Model The statistics and research works on DNS in the network of China Mobile suggests that there should be about 75%~80% DNS requests received by the recursive server will hit the cache per second. Therefore, there are two data models in the test based on the bottom line and the upper line above. As described above, TTL is used to simulate two data model. Each model consists of two parts: the cache part and the recursive part. As Figure 1 shows, the cache part was made of the requests that will hit the cache of the recursive DNS, while the recursive part was made of the requests that will lead to a three time recursive query between the recursive server and all the other three authoritative servers. 3. Analysis of test results The test results are listed in table 1 and table 2. According to the test results, when shooting average in the cache of recursive DNS reaches 80%, the performance of plain recursive DNS can reach 19800 QPS. The performance of recursive DNS with sortlist enabled can reach 19300 QPS, which is similar with plain recursive DNS. However, performance of recursive DNS with DNSSec enabled can only reach 9800 QPS. Similarly, when shooting average in the cache of recursive DNS reaches 75%, the performance of the plain recursive DNS can reach Zhang, et al. Expires September 2, 2012 [Page 4] Internet-Draft TEST-RESULT Mar 2012 18000 QPS. The performance of recursive DNS with sortlist enabled can reach 17400 QPS, which is similar with plain recursive DNS. However, performance of recursive DNS with DNSSec enabled can only reach 8200 QPS. According to the test results, it is very clear that no matter special strategy is enabled or not, the performance of recursive DNS almost gets no influence. However, if DNSSec is enabled, the performance of recursive DNS will be greatly influenced, which can be cut in half or more. The reason of that is mainly because of the three time validation between the recursive server and all the other three authoritative servers. TABLE 1. Test Results Of Recursive DNS's Performance with shooting average of 80% QPS 12000QPS 10000QPS 8000QPS 6000QPS QPS under Numerical 30%CPU Utilization -------------------------------------------------------------------- DNS 21.6% 17.6% 14.1% 10.6% 19800 Sortlist 24.7% 19.5% 16.8% 12.3% 19300 (200) DNSSEC 36.2% 30.6% 24.3% 18.1% 9800 TABLE 2. Test Results Of Recursive DNS's Performance with shooting average of 75% QPS 12000QPS 10000QPS 8000QPS 6000QPS QPS under Numerical 30%CPU Utilization -------------------------------------------------------------------- DNS 20.3% 17.2% 13.9% 10.5% 18000 Sortlist 23.2% 19.1% 15.8% 11.7% 17400 (200) DNSSEC 46.9% 37.6% 29.5% 22.2% 8200 4. Suggestion More attention should be paid on the performance of recursive DNS when DNSSec is enabled. More test on this subject will be done subsequently. Zhang, et al. Expires September 2, 2012 [Page 5] Internet-Draft TEST-RESULT Mar 2012 5. Security Considerations It needs to be further identified. 6. IANA Considerations TBD 7. Acknowledgement Thanks for the contributions from Nan Cheng, Zhongguo Chen, Shujun Hu, Minglong Zhang. 8. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [RFC4431] Andrews, M. and S. Weiler, "The DNSSEC Lookaside Validation (DLV) DNS Resource Record", RFC 4431, February 2006. [RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074, November 2007. Zhang, et al. Expires September 2, 2012 [Page 6] Internet-Draft TEST-RESULT Mar 2012 Authors' Addresses Juan Zhang China Mobile 53A, Xibianmennei Ave. Xunwu District, Beijing 01719 China Email: zhangjuan@chinamobile.com Lanfang Ren China Mobile 53A, Xibianmennei Ave. Xunwu District, Beijing 01719 China Email: renlanfang@chinamobile.com Lianyuan Li China Mobile 53A, Xibianmennei Ave. Xunwu District, Beijing 01719 China Email: lilianyuan@chinamobile.com Zhang, et al. Expires September 2, 2012 [Page 7]