Name Resolution Performance of a Recursive Windows DNS Server 2012 R2

In a previous article we talked about the name resolution performance of a Windows DNS server when deployed as an authoritative DNS server. This article details the name resolution performance of the windows DNS Server 2012 R2, when deployed as a recursive resolver.

Test Setup and Methodology

The test setup constitutes of a DNS client machine running the Dnsperf tool, a recursive resolver, and an authoritative server  (both running Windows DNS server 2012R2). We are testing the performance of the recursive resolver but in a closed lab environment (using DNS forwarders) as resolving internet names brings many unknowns into the equation and it is difficult to isolate and benchmark the DNS resolver's performance with accuracy. On the recursive resolver, the recursion was enabled (recursion is enabled by default on the  Windows DNS server) but the root hints were removed as this is not being used to perform any internet name resolution. 

A DNS forwarder pointing to the authoritative DNS server was configured.

On the authoritative server two zones, with a million records each were hosted. The records in the first zone were configured with high TTL and those in the second zone were configured with 0 TTL. The records with 0 TTL are not cached by the resolver and it helps control the cache hotness for test purposes. 

The queries were sent from the DNS client to the DNS resolver, which forwarded the queries to the authoritative server in case of the cache miss. The cache hotness on the resolver was controlled by distributing the queries between the zone with high TTL and the zone with 0 TTL.

Machine Configuration

Resolver Server Configuration:

Processor(s):

Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz

Maximum speed:        2.50 GHz

Sockets:        2

Cores:        20

Logical processors:        40

Virtualization:        Enabled

L1 cache:        1.3 MB

L2 cache:        5.0 MB

L3 cache:        50.0 MB

Total Physical Memory: 128 GB

Network Card(s):

Broadcom BCM57810 NetXtreme II 10 GigE (NDIS VBD Client): Resolver to Client connectivity

Broadcom NetXtreme Gigabit Ethernet: Resolver to Auth connectivity

Authoritative Server Configuration:

Processor(s):

Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz

Maximum speed:        2.30 GHz

Sockets:        2

Cores:        12

Logical processors:        24

Virtualization:        Enabled

L1 cache:        768 KB

L2 cache:        3.0 MB

L3 cache:        30.0 MB

Total Physical Memory: 128 GB

Network Card(s): Broadcom NetXtreme Gigabit Ethernet

Scenarios

The tests were done by varying the cache hotness on the recursive resolver under two different scenarios:

  1. Positive responses : Here the DNS server received queries with all queries resulting in positive responses. The cache hotness was varied from 0 to 100.
  2. 40% Error : Here the DNS server receives queries such that 40% queries result in NX_DOMAIN or SERV_FAIL. In this scenario, the following QTYPE and RCODE distribution was used

QTYPE distribution

A: 60%

CNAME: 20%

SRV: 10% 

MX (4%), TXT (3%), NS (3%): the rest

RCODE distribution

Positive responses: 60%

NXDOMAIN: 5%

SERV_FAIL: 35%

As 35% of the queries result in SERV_FAIL in this scenario, which are never cached on the resolver, the maximum cache hotness in this scenario can be 65%

Queries were run for 10 mins in both the scenarios. 

Performance Results

  • The fully hot cache performance is around 210K QPS. The performance of the server consistently increases with the cache hotness.
  • The cold cache (no entries in the cache) performance of the windows DNS server is about 50K QPS
  • Beyond this rate of QPS, the DNS server continues to respond at higher rates, but there is a drop in the percentage of queries that are responded to by the server.
  • The memory consumed by the cache is about 2GB for 2M records.
  • The results are similar in both the scenarios. As mentioned, in the second scenario, the maximum cache hotness goes only up to 65%.

 

 

 

Performance Optimizations:

The performance optimizations were done on both resolver and the authoritative server. The optimizations are same as that in this blog