Wei-li Tang, August 28 th 2008. Department of Computer Science and Information Engineering, National...

Wei-li Tang, August 28th 2008. Department of Computer Science and Information Engineering, National Chi Nan University.

On the Performance and Analysis of DNS Security Extensions

• Wei-li Tang• August 28th, 2008.

By R. Curtmola, A. Del Sorbo, and G. Ateniese.

Proceedings of The Fourth International Conference on Cryptology and Network Security (CANS 2005), Xiamen, China.


Outline• Introduction• Background and Related Work• Implementation• Performance

– Setup– Experiments– Query Throughput– Network Traffic– Query Latency

• Conclusion• Reference


Introduction• Vulnerabilities in DNS system noticed in 1990.• Known threats to the DNS system.

– Packet interception– Packet ID guessing– Query prediction– Cache poisoning

• Two minimum security requirements.– Data origin authentication– Data integrity


Introduction• Solutions: PK-DNSSEC and SK-DNSSEC• PK-DNSSEC (RFC2535)

– Based on public-key cryptography– Better for authoritative and referral name servers– Generates considerably more network traffic and

has higher query latency

• SK-DNSSEC– Based on symmetric-key algorithms– Better for recursive name servers– Simpler key management, less intrusive for zone files,

and less memory for caching.


Background and Related Work• Zone: A part of the domain name space.• Resource Record(RR): Basic data unit in a zone.• Resolvers: Clients that query name servers.• Resolution: The process by which resolvers

retrieve data on a domain name.


Background and Related Work• Authoritative Name Server

– Name server that manages a zone is called authoritative for that zone.

• Recursive (Caching) Name Server– Resolves query, cache it and return answer upon

receiving query.

• Referral Name Server– Doesn't return a final answer but redirects the query to

next authoritative name server.


Background and Related Work• The Public Key DNS Security Extension

(PK-DNSSEC, RFC2535)– 3 new RRs:

• KEY: To encode the public key associated with a zone.• SIG: To encode digital signs over an RR set.• NXT: To indicate what does not exist in a zone.

– DNS servers sign RR sets for which they are authoritative, and DNS resolvers verify signed answers by validating SIG RRs that cover each RR set.


Background and Related Work• The SK-DNSSEC protocol

– The notion of DNS symmetric certificate which binds the owner's identity to a key.

– DNS resolver establishes a chain of authentication from trusted DNS server to authoritative name server in order to obtain secure answers.

– Each node in DNS hierarchy shares a symmetric key called master key to generate symmetric certificates.

• To transfer secret keys from parent to child in secure.

– Resolvers needs to acquire a certificate from root server only once, and a DNS symmetric certificate for each DNS server encountered while building the chain of trust.

Fig.: Example of an SK-DNSSEC-enabled queryImage Ref.: R. Curtmola, A. Del Sorbo, and G. Ateniese "On the Performance and Analysis of DNS Security Extensions", CANS 2005.


Implementation• Software

– Modified BIND version 9 with SK-DNSSEC support.

• SK-DNSSEC– MAC function: HMAC with MD5.– Public-key cipher: RSA with PKCS1 padding.– Symmetric cipher: AES in CBC mode.


Performance: Setup• Each of the domains corresponds to the nodes in

the tree.• All domains are hosted on separate machines,

are part of single Ethernet LAN segment, and reside on the same subnet, with no intermediate router in between.

Fig. 1: The test DNS tree


Performance: Experiments• Performance test in 3 categories

– Query Throughput– Network Traffic– Query Latency

• Realistic DNS traffic pattern simulation– Querying for different types of RRs has less impact on

query processing rates of a name server than on the size of DNS response.

– Applied to network traffic test.– Didn't apply to query throughput in order to minimize

the influence of network overhead caused by larger DNS response.


Performance: Query Throughput• Each of zone 1, 2, 3.

– Contains 10,000 hosts.– Consists of 1 SOA RR, 1 NS RR, and 10,000 A RRs.

• Tool: Modified `queryperf ` with SK-DNSSEC.– Maximum 20 outstanding queries (default.)– Executed on a separate machine.– 3 Configurations

• Plain-DNS• SK-DNSSEC• PK-DNSSEC


Performance: Query Throughput• Recursive (Caching) DNS Server

– Tests with 10,000 queries matching all A RRs in zone3(.ee.univ.edu) were directed to name servers authoritative in zone1(.cs.univ.edu).

– Tests with {20,30,40,50,90,100} thousand queries on different zone TTL. (Fig. 2)

Fig. 1. The test DNS tree

Table 1. Caching server performance for entirely uncached and entirely cached answers

Fig. 2. Query throughput performance for a caching server, for various zone TTLs, averaged over ten measurements (note that each graph has a different scale)


Performance: Query Throughput

Fig. 1. The test DNS treeTable 2. Authoritative and referral server performance (in queries per second)

• Authoritative and Referral DNS Server– Tests with queries matching hosts in

zone1(.cs.univ.edu) were directed to name servers authoritative in zone1(.cs.univ.edu).

– Tests with queries matching hosts in zone1(.cs.univ.edu) were directed to name servers authoritative in zone2(.univ.edu).

– Results are independent from zone TTL.


Performance: Query Throughput• Root DNS Server

– In SK-DNSSEC case, root name server was able to handle approx. 305 root certificate requests per second.

– A root server may receive millions of DNS queries but only a small number of root certificates request.


Performance: Network Traffic• Testbed Setup

– Obtained a realistic query type and outcome distribution for query batch, recorded for consecutive 8 days, 8 hours daily, between 8AM-4PM.

Table 3. Observed query type distribution

Table 4. Observed query outcome distribution


Performance: Network Traffic• Network Traffic Performance Test

– 10,000 queries directed to zone1 name server– Queried domain chosen from zone3 and query type

distribution followed Table 3.

Fig. 1. The test DNS tree Table 5. Network traffic statistics

Table 3. Observed query type distribution

Fig. 3. Network traffic evolution over time (note that each graph has a different scale)


Performance: Query Latency• The query latency of a caching DNS Server

– The time it takes to answer any single DNS query.

• Configuration– As shown in Fig. 1.– The name server authoritative for zone1 was

physically located in Italy, other zones were located in USA and in a part of different network.

– Tests with averaged over a set of 100 queries for hosts in zone3 were directed to the name server authoritative for zone1.

• Results (Answers not previously cached)– Plain-DNS: 505.76ms, SK-DNSSEC: 509.70ms,

PK-DNSSEC: 1360.82ms.

Fig. 1. The test DNS tree


Conclusion• Hybrid approach

– PK-DNSSEC deployed for top-level domains andSK-DNSSEC for low-level DNS tree can leverage the benefits of both security extensions.

• SK-DNSSEC (Author's opinion)– Appears to be a valid alternative to PK-DNSSEC– Key management simplification– Less intrusive than PK-DNSSEC

• Zone files don't have to be changed, no NXT RRs needed.

– Response packets are smaller• Less memory for caching is required.


References1.Reza Curtmola, Aniello Del Sorbo and Giuseppe Ateniese "On the Performance and Analysis of DNS Security Extensions", The Fourth International Conference on Cryptology and Network Security (CANS 2005), Xiamen China, December 2005.

2.Giuseppe Ateniese, Stefan Mangard "A New Approach to DNS Security (DNSSEC)", The Eighth ACM Conference on Computer and Communications Security (ACM CCS '01), Philadelphia (USA), November 2001.

3.D. Eastlake "Domain Name System Security Extensions", RFC2535, IBM, March 1999.

4."SK-DNSSEC Project", http://skdnssec.isi.jhu.edu/


Queryperf Mini-HOWTO

• Wei-li Tang• August 28th, 2008.


Queryperf: Outline• Introduction• Build steps• Usage• Example 1• Example 2


Queryperf: Introduction• A DNS server query performance testing tool.• Primarily intended for measuring the

performance of authoritative DNS servers, but it has also been used for measuring caching server performance.


Queryperf: Build steps1. Download BIND source code from ISC Website.2. Queryperf source code is located in

bind-<version>/contrib/queryperf/

3. ./configure

4. make5. Done!


Queryperf: Usage• ./queryperf -d <input_file>

– For more info about arguments, enter ./queryperf -h

• Input file format– Lines with leading semicolon (;): Comments.– Lines with leading number sign (#): Arguments.

• #server : DNS server to be queried directly.• #port : The port of DNS server to be queried directly.• #maxwait: Timeout for query completion in seconds.

– Query entry: <query-name> <query-type>


Queryperf: Example 1• Command: ./queryperf -d sample.0• Input File: sample.0

; This is a comment

#server taurus.ncnu.edu.tw

#port 53

#maxwait 5

www.ncnu.edu.tw A

ncnu.edu.tw MX

1.21.22.163.in-addr.arpa PTR


Queryperf: Example 1• Output result

Parse input file: once Ended due to: reaching end of file

Queries sent: 3 queries Queries completed: 3 queries Queries lost: 0 queries Queries delayed(?): 0 queries

RTT max: 0.000819 sec RTT min: 0.000562 sec RTT average: 0.000697 sec RTT std deviation: 0.000126 sec RTT out of range: 0 queries

Percentage completed: 100.00% Percentage lost: 0.00%

Started at: Thu Aug 26 00:52:27 2008 Finished at: Thu Aug 26 00:52:27 2008 Ran for: 0.000875 seconds

Queries per second: 3428.571429 qps


Queryperf: Example 2• Scenario

– Query 200 distinct A RRs in perf.ncnu.net zone.– Directs queries to 3 DNS servers as follows

• hntp1.hinet.net (168.95.192.1)• taurus.ncnu.edu.tw (163.22.2.2)• feena.csie.ncnu.edu.tw (163.22.21.9)

– It's the authoriative name server of perf.ncnu.net.

• Command: ./queryperf -d sample.1• Input file: sample.1 #server hntp1.hinet.net

#port 53

#maxwait 5

As_Far_As_Possible.perf.ncnu.net A

Away_from_keyboard.perf.ncnu.net A

... etc.


Queryperf: Example 2• Result

– Querying from the same LAN of feena.csie.


Q&A

Thanks!

Wei-li [email protected]

August 28th, 2008.

Wei-li Tang, August 28 th 2008. Department of Computer Science and Information Engineering, National...

Documents

Transcript of Wei-li Tang, August 28 th 2008. Department of Computer Science and Information Engineering, National...