idnits 2.17.1 draft-zhang-dnsext-test-result-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Mar 2012) is 4424 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1034' is defined on line 212, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 215, but no explicit reference was found in the text == Unused Reference: 'RFC4033' is defined on line 218, but no explicit reference was found in the text == Unused Reference: 'RFC4034' is defined on line 222, but no explicit reference was found in the text == Unused Reference: 'RFC4035' is defined on line 226, but no explicit reference was found in the text == Unused Reference: 'RFC4431' is defined on line 230, but no explicit reference was found in the text == Unused Reference: 'RFC5074' is defined on line 234, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Zhang 3 Internet-Draft L. Ren 4 Intended status: Informational L. Li 5 Expires: September 2, 2012 China Mobile 6 Mar 2012 8 DNS-Test-Result 9 draft-zhang-dnsext-test-result-00 11 Abstract 13 This document introduces performance test results of DNS, and makes 14 some analysis about the test results. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 2, 2012. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Description of the test environment . . . . . . . . . . . . . . 3 52 2.1. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.2. Hardware and Hardware . . . . . . . . . . . . . . . . . . . 4 54 2.3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Analysis of test results . . . . . . . . . . . . . . . . . . . 4 56 4. Suggestion . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 59 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 6 60 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 63 1. Introduction 65 This document discusses some tests and the test results on the 66 performance of recursive DNS. Firstly, tests on plain recursive DNS 67 is done. Secondly, tests on recursive DNS with sortlist enabled is 68 done. Finally, tests on recursive DNS with DNSSec enabled is done. 70 Section 2 describes the test environment. Section 3 lists the test 71 result with some analysis. Section 4 gives some suggestions. 73 2. Description of the test environment 75 +----------------+ . +----+ 76 |Recursive Server| // |Root| 77 +-------.--------+ // +----+ 78 || // 79 || // 80 +-----------------+ +---.----------. +----+ 81 |Request generator|----------.| Switch |-------.|.com| 82 | |.--------- | |.------ | | 83 +-----------------+ +------.-------+ +----+ 84 || 85 || 86 +----------.-------------+ 87 |xxx.com(1.com~60000.com)| 88 +------------------------+ 90 Figure 1: topology of the test 92 2.1. Topology 94 The test simulated a complete recursive request-response procedure in 95 a closed network, there are four servers needed at least: one 96 recursive server and three Authoritative servers. As Figure 1 97 describes, there are four servers in the topology, implementing the 98 recursive server role, the root server role, the .com top level 99 domain server role and the xxx.com domain server role. The xxx.com 100 domain server is responsible for resolving the DNS requests from 101 1.com to 60000.com. Besides the four servers, there are also a 102 switch and a request generator in the topology. The requests 103 generator simulated many clients with different ip addresses. It can 104 also generate requests as configured and send them to the switch 105 which acts as a gateway to transfer requests and responses between 106 the recursive server and the clients. 108 2.2. Hardware and Hardware 110 All the servers concluded in the test are assembled with 2 CPUs with 111 8 core in each other and 8GB RAM. All the network interfaces between 112 the server and the switch are 100/1000Base-T so that time between 113 each request and response will be less than 4ms. 115 All the servers in the test are installed with BIND as DNS software 116 and configured as the correct roles as mentioned, the version of 117 which is BIND 9.8.1-p1. As Figure 1 describes, there are 60000 zones 118 (1.com~60000.com), each of which is made of a SOA record, a A record 119 and a NS record, configured in the xxx.com domain name server. All 120 the zones are divided into two parts: the cache and recursive. The 121 Time-to-live value of each record of the cache part will be 86400 so 122 that the record will be alive all the time in the cache of the 123 recursive server until the test is over, while the value of the 124 recursive part will be just 1 so that the record will be moved out 125 from the cache in a second. At last, the cache size of the recursive 126 server is configured to 10MB, which can accomodate all the cache 127 part. 129 2.3. Data Model 131 The statistics and research works on DNS in the network of China 132 Mobile suggests that there should be about 75%~80% DNS requests 133 received by the recursive server will hit the cache per second. 134 Therefore, there are two data models in the test based on the bottom 135 line and the upper line above. As described above, TTL is used to 136 simulate two data model. Each model consists of two parts: the cache 137 part and the recursive part. As Figure 1 shows, the cache part was 138 made of the requests that will hit the cache of the recursive DNS, 139 while the recursive part was made of the requests that will lead to a 140 three time recursive query between the recursive server and all the 141 other three authoritative servers. 143 3. Analysis of test results 145 The test results are listed in table 1 and table 2. According to the 146 test results, when shooting average in the cache of recursive DNS 147 reaches 80%, the performance of plain recursive DNS can reach 19800 148 QPS. The performance of recursive DNS with sortlist enabled can 149 reach 19300 QPS, which is similar with plain recursive DNS. However, 150 performance of recursive DNS with DNSSec enabled can only reach 9800 151 QPS. 153 Similarly, when shooting average in the cache of recursive DNS 154 reaches 75%, the performance of the plain recursive DNS can reach 155 18000 QPS. The performance of recursive DNS with sortlist enabled 156 can reach 17400 QPS, which is similar with plain recursive DNS. 157 However, performance of recursive DNS with DNSSec enabled can only 158 reach 8200 QPS. 160 According to the test results, it is very clear that no matter 161 special strategy is enabled or not, the performance of recursive DNS 162 almost gets no influence. However, if DNSSec is enabled, the 163 performance of recursive DNS will be greatly influenced, which can be 164 cut in half or more. The reason of that is mainly because of the 165 three time validation between the recursive server and all the other 166 three authoritative servers. 168 TABLE 1. Test Results Of Recursive DNS's Performance 169 with shooting average of 80% 171 QPS 12000QPS 10000QPS 8000QPS 6000QPS QPS under 172 Numerical 30%CPU Utilization 173 -------------------------------------------------------------------- 174 DNS 21.6% 17.6% 14.1% 10.6% 19800 175 Sortlist 24.7% 19.5% 16.8% 12.3% 19300 176 (200) 177 DNSSEC 36.2% 30.6% 24.3% 18.1% 9800 179 TABLE 2. Test Results Of Recursive DNS's Performance 180 with shooting average of 75% 182 QPS 12000QPS 10000QPS 8000QPS 6000QPS QPS under 183 Numerical 30%CPU Utilization 184 -------------------------------------------------------------------- 185 DNS 20.3% 17.2% 13.9% 10.5% 18000 186 Sortlist 23.2% 19.1% 15.8% 11.7% 17400 187 (200) 188 DNSSEC 46.9% 37.6% 29.5% 22.2% 8200 190 4. Suggestion 192 More attention should be paid on the performance of recursive DNS 193 when DNSSec is enabled. 195 More test on this subject will be done subsequently. 197 5. Security Considerations 199 It needs to be further identified. 201 6. IANA Considerations 203 TBD 205 7. Acknowledgement 207 Thanks for the contributions from Nan Cheng, Zhongguo Chen, Shujun 208 Hu, Minglong Zhang. 210 8. Normative References 212 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 213 STD 13, RFC 1034, November 1987. 215 [RFC1035] Mockapetris, P., "Domain names - implementation and 216 specification", STD 13, RFC 1035, November 1987. 218 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 219 Rose, "DNS Security Introduction and Requirements", 220 RFC 4033, March 2005. 222 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 223 Rose, "Resource Records for the DNS Security Extensions", 224 RFC 4034, March 2005. 226 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 227 Rose, "Protocol Modifications for the DNS Security 228 Extensions", RFC 4035, March 2005. 230 [RFC4431] Andrews, M. and S. Weiler, "The DNSSEC Lookaside 231 Validation (DLV) DNS Resource Record", RFC 4431, 232 February 2006. 234 [RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074, 235 November 2007. 237 Authors' Addresses 239 Juan Zhang 240 China Mobile 241 53A, Xibianmennei Ave. 242 Xunwu District, Beijing 01719 243 China 245 Email: zhangjuan@chinamobile.com 247 Lanfang Ren 248 China Mobile 249 53A, Xibianmennei Ave. 250 Xunwu District, Beijing 01719 251 China 253 Email: renlanfang@chinamobile.com 255 Lianyuan Li 256 China Mobile 257 53A, Xibianmennei Ave. 258 Xunwu District, Beijing 01719 259 China 261 Email: lilianyuan@chinamobile.com