intro

home : internet : dns : interland : overview

methods

Interland DNS Testing Procedures

Introduction

The purpose of this testing is to determine which OS and dns server we want to use for HostPro’s DNS infrastructure. We will be testing a couple OS platforms and several dns servers to determine which combination will best suit the needs of HostPro today and into the future. The results of the testing will be turned over to the Enterprise DNS team who will use these results to assist us in our determination of which choices best suite the needs of all our interested parties.

Revision Date - Number - Purpose

• 05/22/2001 - 0.1 - Rough Draft
• 05/23/2001 - 0.2 - Suggested revisions by Enterprise DNS team members, spelling corrections, QA procedure updates.
• 06/04/2001 - 0.3 - Input test results.
• 06/14/2001 - 0.5 - input additional test results.

Source Documents:

• Testing research. http://matt.simerson.net/computing/dns/testing.shtml
• BIND Users mailing list Bind-users@isc.org
• Djbdns Users mailing list dns@cy.yp.to

Product Architecture Overview

The Enterprise DNS group has outlined the requirements we have for the new DNS servers.

• Reliability - no single point of failures.
• Security - no recursive lookups for non-HostPro owned IPs
• application level (e.g., BIND, djbdns, etc..)
• host level
• network level (firewall, ipfw, ipfirewall)
• Scalability - Manage 20 million resource records/1 million zones
• Flexibility - Pieces of the solution must be replaceable as needed.
• Performance
• Propagation delay
• Housekeeping - A mechanism must be in place to delete domains that no longer use our name servers.
• Single Login - Authentication should be tied into existing systems.

The group decided that FreeBSD and Solaris were both excellent choices (performance, reliability, security, scalability, available talent) and that we should do some head-to-head performance testing on both FreeBSD and Solaris platforms.

We discussed at length the choice of database engines, mainly discussing the merits of using MySQL versus Oracle. It was decided that we'll go ahead and use MySQL but architect the system in such a fashion that a future conversion to Oracle is possible.

We discussed the need for a secure reliable way for customers to manage their zone data. HostPro does not currently have mechanisms available for customers to manage their zone data. Matt again suggested contracting the guys at NicTool to custom tailor their DNS management interface to our needs. NicTool will come in and spend 4 weeks tailoring their package to meet our specific needs for a one time cost of $14,000. We get a perpetual license, we get the source (so we can make changes), and any future releases at no cost.

It was decided that the team would forge ahead with NicTool. Matt volunteered Seattle's test lab and testing staff to conduct performance testing on the systems. After some lab testing all servers will be moved to the Tukwila NOC where we can conduct some real world testing and do a security evaluation. Trevor has some cracker contacts that we can turn loose on the systems.

On May 15th we'll begin testing of all the systems per the following Matrix:

OS | Solaris | FreeBSD

----|-------------------|-------------------

DB | MySQL | MySQL

----|-------------------|-------------------

DNS | bind 8,9 & djbdns | bind 8,9, & djbdns

----|-------------------|-------------------

www | NicTool | NicTool

Seattle will take care of building the FreeBSD based system and Boise will build the Solaris based one. Building encompasses installing OS, DNS server(s), securing (disabling services/firewalling/access rules), and delivery to the test lab.

The reference hardware will be the HP systems w/1GB RAM, which is likely the same hardware the project will roll into production with. Sparc systems will be comparable.

Features/Items To Be Tested

1 Caching Performance Publicly available DNS servers will NOT be caching servers. Caching servers will be available ONLY to dns requests from HostPro IP space.

2 Query performance How many queries can each server reliably serve in a given unit of time?

3 Propagation time How long it takes from the initial entry of a DNS change before that change is available on the public internet

4 Uptime How reliable is the server? Are there any known DoS attacks?

5 Security A comprehensive security audit will be performed on each system. Host and application security will be tested thoroughly.

6 Master/slave recover time MySQL does not have master-to-master replication. Master to slave recovery time is the length of time it takes from when the master fails to when a slave is promoted to master and services are restored.

7 System manageability How easy is it for a system administrator to make changes? How much time is necessary for administration tasks on a routine basis?

8 Scalability Use load balancers to determine how load scales across multiple servers.

Last modified on 4/25/05.