Internet DRAFT - draft-zhang-dnsext-test-result
draft-zhang-dnsext-test-result
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]
