| SK-DNSSEC Project
|
|
Performance
|
|
| A comparative analysis was
performed to determine the performance tradeoff induced by the security
overhead in SK-DNSSEC and PK-DNSSEC, as compared to the plain DNS. The
analysis consisted of a series of performance tests, grouped in three
categories: query throughput, network traffic and query
latency. |
|
We have used the DNS tree depicted in Figure 1, with each of the domains
hosted on a different machine.
|
|
Figure 1: The test
DNS Tree
|
Experiments were performed with two homogeneous configurations of machines in the
DNS tree:
- Configuration 1: single Athlon XP 2.2 Ghz processor, 1 GB SDRAM memory,
running Red Hat Linux 8.0 (kernel 2.4.20)and BIND 9.2.1 compiled with
OpenSSL 0.9.7d, in a single Gigabit Ethernet LAN segment, connected by a Trendnet
TEG-S240TX Gigabit switch.
- Configuration 2: single Pentium III 800 Mhz processor, 128 MB SDRAM
memory, running Red Hat Linux 7.0 (kernel 2.2.18) and BIND 9.2.1 compiled
with OpenSSL 0.9.7c, in a single 100Mbit/sec Ethernet LAN segment, connected
by a Netgear DS108 hub.
|
Following are the results for experiments done in Configuration 2:
|
|
1) Query throughput performance
|
|
Each of the zones 1, 2 and 3 contains one SOA RR, one NS RR and
10,000 A RRs. A batch of 10,000 queries for A RRs was sent using
queryperf from a machine outside the DNS tree.
|
|
|
|
1a) performance of a recursive (caching) DNS server
|
|
The query batch was constructed by randomly choosing 10,000 hosts from the
zones 1, 2 and 3, and then directed to the name server authoritative for
zone1 (.cs.univ.edu), which had recursion turned on and played the role of a caching resolver.
Results are shown in Figure 2.
|
|
Figure 2: Caching
name server query throughput
|
|
|
|
1b) performance of an authoritative DNS server
|
|
The query batch was constructed by randomly choosing 10,000 hosts from
zone1, and then directed to the name server authoritative for
zone1 (.cs.univ.edu), which played the role of an authoritative name
server. Results are shown in Figure 3.
|
|
Figure 3:
Authoritative name server query throughput
|
|
|
|
1c) performance of a referral DNS server
|
|
The query batch was constructed by randomly choosing 10,000 hosts from
zone1, and then directed to the name server authoritative for
zone2 (.univ.edu), which had recursion turned off and played the role of a
referral name server. Results are shown in Figure 4.
|
|
Figure 4:
Referral name server query throughput
|
|
|
|
1d) performance of a root DNS server
|
|
For SK-DNSSEC, the root name server was able to handle approximately 110 root
certificate requests per second.
|
2) Network Traffic performance
|
|
Each of the zones 1, 2 and 3 contains one SOA RR, two NS RR,
10,000 A RRs and two MX RRs for 1000 of the hosts in the zone. A batch of 10,000 queries was sent using
queryperf from a machine outside the DNS tree. This query batch had
the query type distribution and the query outcome in accordance to the DNS
traffic monitored at the main DNS server of our institution for 8
consecutive days, 8 hours daily.
|
|
|
|
2a) network traffic performance test 1
|
|
The query batch was constructed by randomly choosing 10,000 hosts from the
zones 1, 2 and 3, and then directed to the name server autoritative for
zone1 (.cs.univ.edu). Results are shown in Figure 5, for various TTL
values of the zones in the DNS tree.
|
|
Figure 5(a): TTL=1s
|
|
Figure 5(b): TTL=10s
|
|
Figure 5(c): TTL=25s
|
|
Figure 5(d): TTL=60s
|
Figure 5: Network
traffic evolution over time
|
|
|
|
2b) network traffic performance test 2
|
The query batch was constructed like in the previous network traffic
experiment, but the tests were run with batches of n queries, with
n &isin
{100,200,300,...,9900,10000}. Results are shown in Figure 6, for the zones
in the DNS tree having a TTL of 1 second and 10 seconds.
|
|
Figure 6(a): TTL=1s
|
|
Figure 6(b): TTL=10s
|
Figure 6: Network
traffic evolution with query volume
|