DNS AND DHCP BEST PRACTICES: ARCHITECTURE THAT WORKS

Whitepaper

ii | BlueCat Networks
Use of this document Copyright This document and all information (in text, Graphical User Interface (GUI), video and audio forms), images, icons, software, design, applications, calculators, models, projections and other elements available on or through this document are the property of BlueCat Networks or its suppliers, and are protected by Canadian and international copyright, trademark, and other laws. Your use of this document does not transfer to you any ownership or other rights or its content. You acknowledge and understand that BlueCat Networks retains all rights not expressly granted. Persons who receive this document agree that all information contained herein is exclusively the intellectual property of BlueCat Networks and will not reproduce, recreate, or other use material herein, unless you have received expressed written consent from BlueCat Networks. Copyright 2011, BlueCat Networks Inc. All rights reserved worldwide. Publisher Information Published in Canada No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any human or computer language in any form or by any means without the express written permission of: BlueCat Networks Inc. 4101 Yonge Street, Suite 502 Toronto, Ontario Canada M2P 1N6 Attention: Product Manager Telephone: 416-646-8400 Fax: 416-225-4728 E-mail: info@bluecatnetworks.com Website: www.bluecatnetworks.com This publication is provided as is without warranty of any kind, express or implied, including, but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. All terms mentioned in this publication that are known to be trademarks or service marks are appropriately capitalized. BlueCat Networks cannot attest to the accuracy of this information. Use of a term in this publication should not be regarded as affecting the validity of any trademark or service mark. The trademarks, service marks and logos (the Trademarks) displayed are registered and unregistered Trademarks of BlueCat Networks, Inc. and others. Users are not permitted to use these Trademarks for any purpose without the prior written consent of BlueCat Networks or the third party owning the Trademark. No Professional Advice This document is for convenience and informational purposes only. This document is not intended to be a comprehensive or detailed statement concerning the matters addressed; advice or recommendations, whether scientific or engineering in nature or otherwise; or an offer to sell or buy any product or service. BlueCat Networks does not warrant or make any representations regarding the use, validity, accuracy, or reliability of, or the results of the use of, this website or any materials on this document or any website referenced herein. This document is intended solely for the use of the recipient. It does not institute a complete offering and is not to be reproduced or distributed to any other person.

DNS and DHCP Best Practices - Architectures that Work | iii

Executive Summary
Security, performance and availability are fundamental design objectives for virtually every IP network. There are a number of recommended best practices that help network architects achieve these goals. This paper examines best practices related to DNS and DHCP, key services that enable modern IP networks. For external DNS:

caching services. Forwarding builds a centralized cache, which improves performance. For DHCP:

Configure the external primary DNS server as a hidden master. This configuration protects the primary server, provides maximum performance, and increases tolerance to failure. Where possible, deploy primary servers in highavailability clusters. Deploy secondary servers in geographically-dispersed data centers to avoid a single point of failure scenario. Placing secondary servers within the corporate demilitarized zone (DMZ) minimizes the types of data traffic. to which they are exposed, affording greater security. Secure zone transfers using access control lists (ACLs) and transaction signatures (TSIGs). These security measures deter potential attackers. Disable recursion on external servers to eliminate the risk of cache positioning. Run DNS in a chroot jail to sandbox potential attacks and minimize damage. Hide information that indicates the version of DNS server software deployed. This information benefits attackers who can exploit known vulnerabilities.

The number of DHCP servers you deploy depends greatly on the requirements of your organization. Carefully plan your DHCP deployment to ensure maximum reliability and scalability. To ensure service availability and eliminate single points of failure, deploy DHCP servers in redundant, failover configurations using DHCP Failover.

Adopting these best practices will help reduce service outages and enhance network security considerably.

For internal DNS:

Locate internal DNS servers on the internal network, behind a firewall. Use virtual private networks (VPNs) to connect remote users to internal resources. To enhance performance and reliability, consider using a hidden master for the internal primary DNS server. Where possible, deploy secondary servers at local sites locally to preserve network bandwidth. An analysis of bandwidth requirements the frequency DNS queries on the local WAN link can help determine whether small sites warrant secondary servers. As alternatives to secondary servers, consider stealth secondary servers or caching-only servers for small sites. These require less network bandwidth. The size and complexity of the internal DNS affects your design decisions. Consider deploying internal root servers for large, distributed networks, or those with complex namespaces. Internal root servers can enhance scalability, efficiency and control.

For caching servers:

Use forwarders to separate authoritative services from

iv | BlueCat Networks

Contents
Executive Summary iii DNS 1 External DNS 1 i. Primary Server - Hidden Master Configuration 1 ii. Multiple Secondary Servers 2 iii. DMZs 2 iv. Restricted Zone Transfers 2 v. Recursive Queries 3 vi. Further Considerations 3 Internal DNS 3 Primary Server 3 Secondary Servers 3 DDNS 4 Internal Root Servers 4 Caching Servers 5 Separation of Services 5 Forwarding 5 Conditional Forwarding 5 DHCP 6 DHCP Deployment 6 DHCP Failover 6 Conclusion 7 About BlueCat Networks 8 BlueCat Networks White Papers 9

DNS and DHCP Best Practices - Architectures that Work | 1

Introduction
DNS and DHCP network architectures can range from simple to extremely complex. Regardless of complexity, a good network design eliminates single points of failure, steels the network from attacks, and meets the performance requirements of a wide variety of business applications and services. While budget constraints certainly affect design decisions, there are numerous best practice principles that should always be considered. This paper examines some of the design options available to network architects. It includes a number of recommended best practices that help ensure DNS and DHCP environments are robust, secure, and manageable.

i. Primary Server - Hidden Master Configuration

Because all changes go through the primary zone, it must be protected from both attack and failure. BlueCat Networks recommends running the primary DNS server as a hidden master. A hidden master configuration allows you to remove the server from the exposed network and place it behind the internal firewall on the trusted side of the network. Internet users connect to publicized secondary servers which provide DNS resolution for the organization. This secures the primary DNS server from attack, while allowing the server to update the secondary DNS servers that are serving DNS records. A hidden master gets its name from the fact that its name server (NS) resource record the record that identifies it as a DNS server is not listed in the zone (or as a delegation record on the zones parent servers). This renders it essentially invisible to the public. Because you cannot hit what you cannot see, hidden masters are better protected.

DNS
DNS is a critical service for every organization. Without it, necessary business applications, such as email and web, cannot function. However, many organizations have not taken the time and care to properly deploy DNS within their network. An improper DNS deployment can leave an organization susceptible to DNS outages, failures and security risks. Organizations need to seriously examine their current DNS deployments and take the necessary steps to ensure that their systems are fault tolerant, reliable and secure. At its most basic, a DNS deployment requires a minimum of two name servers one server hosts the primary (also known as master) copies of the zones, and the other hosts the secondary (or slave) copies. The primary zones are writeable and all DNS updates are made to them. Secondary zones are read-only and exist to provide redundancy and to also relieve some of the load from the primary. Secondary zones are updated by the primary through a mechanism known as the zone transfers. DNS is required on the internal side of the network to provide users and systems with access to resources by name. Services such as Active Directory rely on DNS and cannot function without it. On the external side of the network, DNS is perhaps the most frequently used network service on the Internet. Every time users connect to web sites or send email messages they are using external DNS.

Internal

XHA

Hidden Master Cluster Internal Firewall

DMZ

Placed at each major datacenter Secondary DNS External Firewall Secondary DNS Secondary DNS

Client Requests

Internet

External DNS
An organizations external DNS server provides the rest of the world with access to the corporate web site, email services, and any number of external-facing applications. Since external DNS servers face the Internet, they have the highest exposure to attacks. An external DNS architecture usually consists of a small number of servers, typically a master and slave. These servers must be well protected and hardened to reduce the attack surface and to ensure service availability. The following sections describe some of the best practices for primary and secondary, external DNS servers.

Aside from the obvious security benefits, a hidden master configuration pays dividends in performance as well. Free from the need to respond to external queries, the primary server can focus on zone maintenance, such as notifying secondary servers of changes and responding to zone transfer requests. The hidden master also increases tolerance to failure. As crucial as the primary server is, if it were to fail, there would be no immediate service disruption. Resolvers on the Internet, unaware of the primary server as a source of name resolution, would continue to query the secondary servers.

2 | BlueCat Networks

Tip While secondary zones can continue to function in the event of a primary zone failure, it is important to ensure that if the primary server fails, it is back online before the zones Start of Authority (SOA) expire time elapses. Setting this value to the recommended duration of 2 to 4 weeks should allow adequate time to correct the problem.

iv. Restricted Zone Transfers

Restricting zone transfers is one of the easiest and most effective ways to secure external DNS. As discussed earlier, zone transfers are used to update secondary servers with changes to zone data. Because zone transfers contain the names and IP addresses of network devices, you should ensure that only secondary servers are allowed to request and receive them. Allowing zone transfers to any host increases DNS vulnerability significantly:

The presence of secondary servers notwithstanding, BlueCat Networks recommends placing hidden masters in redundant configurations, such as high-availability clusters, to eliminate single point of failure scenarios. Redundancy ensures service availability in the event of a hardware and service failure within the hidden master server.

Zone transfers provide potential attackers with a map of the external network. (This weakness worsens considerably if the internal system is accidentally advertised in external zones.) Attackers can use a script to repeatedly request zone transfers from a targeted server. Such denial of service (DoS) attacks tie up both server resources and network bandwidth, rendering servers unavailable.

ii. Multiple Secondary Servers

The DNS specification and domain name registration rules require a minimum of two servers for every external authoritative domain. Although a minimal DNS architecture is comprised of a primary and single secondary server, a hidden master configuration requires at least two secondary servers. To ensure external DNS is as reliable as possible, consider using three secondary servers. With an additional backup, if one secondary server goes down for any reason, the external DNS is still redundant, and not a single failure away from unavailability. BlueCat Networks recommends four or five secondary servers where an extremely high level of traffic is anticipated and greater reliability is required. Placing five secondary servers in one location will not help if a network, hardware outage, or a natural disaster brings the subnet or data center down and stops DNS; locate servers in geographically dispersed data centers, with reliable, redundant networks. Consider placing at least one secondary server in a co-location facility, where it can take advantage of redundant connections to the Internet. Where it is necessary to place multiple servers in the same data center, place each server on an individual subnet, behind different switches and routers.

Restricting zone transfers to explicitly authorized hosts minimizes these risks. Use access controls to restrict zone transfers to only secondary servers. A transfer request by any other host that does not have its IP address stipulated in the access list is refused. In addition, make sure the firewall rules in the DMZ are set to block any attempt to spoof internal IP addresses. While restricting zone transfers to IP addresses is good, using transaction signatures (TSIGs) is deemed better. TSIGs bring the power of cryptography to zone transfers. Each server (both primary and secondary) shares a copy of a symmetric, cryptographic TSIG key (shared secret). Every transaction (notification and zone transfer) is run through a hashing algorithm, which produces an output called a digest. The digest is then signed with the TSIG key. TSIG provides mutual authentication in that each server in the transaction must identify itself to the other. Only holders of the TSIG shared secret are allowed to request zone transfers, making it nearly impossible for an attacker to spoof the identity of a secondary server. TSIGs also ensure the integrity of transactions. Hash digests provide a means for either server to determine if transaction data has been modified en route. Though many DNS administrators agree that transaction signatures greatly enhance zone security, they are not always implemented due to their complexity and the challenges associated with getting the key transferred securely between the authorized servers. If the shared key is compromised, security is lost. Ensuring that TSIG keys are securely transferred can be made easier through the deployment of an appliance-based DNS solution, which simplifies the configuration and transfer of the TSIG key to servers.

iii. DMZs
Wherever possible, avoid placing external DNS servers directly on the Internet without the protection of a firewall. Placing secondary servers behind firewalls, in a DMZ, minimizes the types of data traffic to which they are exposed, affording greater protection from attack. Traffic to and from DNS name servers should be filtered to allow only DNS traffic (UDP and TCP port 53) from external servers. This limits the exposure of the server to only the DNS service.

DNS and DHCP Best Practices - Architectures that Work | 3

v. Recursive Queries
A DNS server that accepts recursive queries looks to other DNS servers, often starting at the Internet Root servers, if it cannot answer the query itself. Recursive queries are an essential part of DNS and must be allowed on some internal DNS servers, so that internal users can resolve names on the Internet and on different parts of the organizations internal network. Recursion is not required on an external DNS server and should be disabled. An external server that responds to recursive queries is vulnerable to cache poisoning attacks, such as the vulnerability discovered by Dan Kaminsky in mid-2008. Cache poisoning occurs when an attacker feeds a DNS server with false data records before the authentic answer is returned. The false records often direct unsuspecting DNS clients to a site of the attackers choosing. Recent versions of DNS software include measures to combat cache poisoning. Responding to recursive queries is also performance intensive, much more so than answering queries directly from a local zone. A recursive query generally requires that the DNS server contact multiple servers, one at a time. Too many recursive queries leads to significant performance degradation. It follows that an external DNS server responding to recursive queries is vulnerable to denial of service attacks. An attacker who is able to submit a large enough number of recursive queries can bring the server to its knees. BlueCat Networks strongly recommends that administrators disable recursion on external servers. If this is not possible, recursive queries should be restricted to trusted, internal clients.

exploit known vulnerabilities.

Internal DNS
Internal DNS gives clients access to both internal resources and those on the Internet by name. Many of the strategies used to secure and manage external DNS are applicable to internal DNS. However, internal DNS servers should always be located on the internal network, behind a firewall. It is essential that internal resources cannot be accessed from the outside without additional safeguards. Use virtual private networks (VPNs) to provide trusted users outside the network with access to internal resources.

Primary Server
Consider using a hidden master on the internal network as well. Performance and fault tolerance are the drivers here. A hidden master does not resolve internal queries, and can be left to manage zone transfers and accept dynamic DNS updates. Should the hidden master fail for any reason, queries continue to be resolved without disruption as internal clients are configured to use the secondary servers. Where possible, the primary server should be part of a high availability cluster to protect against hardware and service failures.

Secondary Servers
Determining the number and placement of secondary servers is a critical design consideration. One of the more important decisions is whether each site should have a local secondary server (or servers). Factors to consider include the number of users located at each site and the speed and quality of network services to the site. Users located at a site without a local authoritative DNS server must contact a remote location to resolve internal names. When a site has a large number of users, remote resolution can strain local WAN links. A forecast of query frequency (i.e. the number of queries) monitored over time can help determine whether traffic at a small site is increasing and requires a local name server. As a general rule, all sites should have one or more local secondary servers with small branch offices being the possible exception. When a site requires a local secondary server, and the network connection is slow, consider implementing a stealth slave. Like a hidden master, the stealth slave does not have its name server records published in the zone. Although zone transfers are still required to keep the stealth secondary server up-to-date, the server is not queried which helps with bandwidth concerns. A hidden master can also be used as a potential backup for the

vi. Further Considerations

One of the most fundamental security principles is defense in depth the more layers of protection you add, the more secure your infrastructure will be. Consider the following additional recommendations when designing DNS networks:

Ensure that you are running the latest version of DNS software. Earlier versions of DNS software have inherent security vulnerabilities that attackers can exploit. Running the latest version of DNS software helps safeguard DNS against known attacks and destructive exploits. Run the DNS software in a jailed environment. This strategy includes running the DNS service as a limited user rather than as root. In the event that an attacker is somehow able to compromise DNS, the attacker is sandboxed within a restricted directory structure and is prevented from accessing the rest of the server. This restricts or jails the attackers and ensures that they do not have access to a shell prompt or the rest of the system Hide the DNS software version. If attackers can determine the version of DNS software in operation, they have additional information with which to plan attacks and

4 | BlueCat Networks
hidden master. Another option is to deploy caching-only servers instead of secondary servers at small and remote offices. A caching-only server does not host any zones. Used effectively, a caching-only server accepts queries for both Internet and other internal resources. Queries for internal names are forwarded to internal authoritative name servers, the results of which are cached. Caching servers do not request zone transfers, and conserve bandwidth. Caching is described in further detail in section 3.3.

Confidentiality of Internal Information. Internal lookups remain in the internal namespace and do not escape to the Internet even if the request exists on another server in a geographically distant location. No requests for internal names will ever leave the organization. Efficient Lookups. Forwarding queries in a very large, distributed DNS network can be complicated. Root servers simplify the design you know where the destination of every query will go.

DDNS
Dynamic DNS (DDNS) is used on internal networks to allow DNS clients and DHCP servers to dynamically update DNS with forward and reverse address mappings. A DDNS-capable client dynamically updates its hostname and IP address in DNS. You can either configure the client to register its host records directly with a DNS server, or configure a DHCP server to forward records to the DNS server on behalf of the client. In either case, the DNS server that needs to be updated is determined using Start of Authority (SOA) records. Because secondary servers are read-only, only primary DNS servers can accept dynamic updates. As a result, care must be taken when configuring a hidden master, to ensure that the address of the primary server is listed as the server to be updated in the Start of Authority record. In order to control DDNS updates, BlueCat Networks recommends using a DHCP server to register DNS records on behalf of clients. This removes the need for client systems to update DNS directly and helps to secure DNS by limiting the number of systems that can update the DNS server. Dynamic DNS greatly eases administration because it eliminates the need to manually enter large numbers of records. Given the rise in DHCP-enabled devices, such as Voice over IP (VoIP) phones, wireless devices, Radio Frequency Identification (RFID) and other devices, DDNS is almost always a necessity for networks to operate properly.

It is worth noting that root servers need not be dedicated. Any authoritative DNS server can host root zones. Of course, you should set at least two such DNS servers as root servers to eliminate a single point of failure. When using Internet root servers, you must consider how internal clients will be able to access the Internet (assuming this is desirable). You can enable Internet access in a number of ways:

Configure internal root servers to forward queries to external servers for resolution. Any query for which the internal root servers are not authoritative can be forwarded (although this option can present problems if the internal root server is authoritative for top-level domains that also exist on the Internet). Configure internal clients so that they can query different DNS servers, depending on whether the request is internal or external. To use this option, clients must be proxycapable and either support software proxies or proxy local address tables (LATs).

Caching Servers
Caching servers accept recursive queries from DNS clients (either stub resolvers or other name servers) and resolve those queries by contacting authoritative name servers. When designing DNS, you must consider Internet access. Although any DNS server can be configured to accept recursive queries, deciding which servers are allowed to access Internet root servers requires some planning. Because most DNS exploits and vulnerabilities are a result of enabling recursion, enabling recursive lookups on a server can increase that servers risk of being susceptible to a DNS exploit.

Internal Root Servers

Organizations with very large, distributed networks and those with complex namespaces can benefit from deploying internal root servers. Internal root servers perform the same function for the internal network that the Internet root servers perform for the Internet. Internal DNS servers are configured with the IP addresses of the internal root servers and any queries that local DNS servers cannot answer are forwarded to the root servers. These queries are then delegated to the appropriate name server within the organization. Setting up internal root servers offers several advantages:

Separation of Services
BlueCat Networks recommends separating internal authoritative DNS services from caching services. A server that hosts internal authoritative zones should never access the Internet, and a caching server that requests name services from Internet root servers should not contain zone information. This secures authoritative zones against many DNS exploits, such as cache poisoning attacks, which rely on recursive lookups being enabled to exploit the DNS server.

Scalability. If the entire Internet can be supported with only 13 root servers, internal root servers can easily meet the architecture scalability requirements of any organization.

DNS and DHCP Best Practices - Architectures that Work | 5

and suggest deploying multiple forwarders, (in high availability pairs where possible) to reduce the occurrences of all forwarders going offline.

Forwarding
One method for separating authoritative and caching services is a concept known as DNS forwarding. In a typical forwarding environment, clients are configured with the IP address of internal authoritative DNS servers so they can query them directly. Requests for internal resources are answered directly from zone data. Any queries the name server cannot answer authoritatively are sent to another name server known as a forwarder. When the forwarder receives a recursive query it sends an iterative query on behalf of its client to the Internet root servers. If the forwarder receives an answer, it responds to the name server, which in turn responds to the client. This answer is then cached by the forwarder. Where there are a number of authoritative name servers, it is common practice to configure them to forward queries to a smaller number of forwarders. Such practice takes advantage of centralized caches which improves performance significantly. When using forwarding, it is a good idea to configure the name server with the IP addresses of multiple forwarders. In this way, if the first forwarder fails to respond, the name server attempts to contact the second forwarder in the list, then the third, and so on. It is also important to vary the order in which forwarders are assigned to different name servers. Varying the order of assignment distributes the load, so that one caching server is not always the first to receive every query. You can configure forwarding in one of two ways, forward first and forward only. With a forward first configuration, if none of the forwarders on its list respond, the queries are then sent directly to the root servers. A server configured for forward-only does not attempt to access the Internet root servers, even if all its forwarders fail to respond. We recommend forward only as the more secure configuration

Conditional Forwarding
A variation on forwarding is the concept of conditional forwarding. Conditional forwarding allows you to configure a server to forward queries for a certain zone to specific name servers. Conditional forwarding is often used within an internal network to send queries to internal departmental or partner names. This configuration can be effective if a partners DNS server is not available on the Internet, and must be accessed using a private link such as a VPN. Conditional forwarding offers an additional benefit because it removes some of the load from the main forwarders they are relieved of answering queries intended for specific DNS servers. Where internal root servers are neither feasible nor required, forwarding provides a simpler alternative.

DHCP
DHCP Deployment
DHCP server deployments can be more complicated than DNS. While an organization can maintain a handful of servers to run DNS for their network, the same rules do not apply to DHCP. For many organizations, the number of DHCP servers far outweighs the number of DNS required. It is not uncommon for an organization to decentralize DHCP server deployment, while centralizing DNS servers. Depending on a number of factors, you have the option of going with either a centralized or a decentralized DHCP server deployment. Some organizations prefer to place DHCP servers at a head of a regional

Adonis 250 Adonis 1000 External

Adonis 250

Adonis 1000 Clients

DNS Caching Only Servers

Forwarding of Recursive Queries

Internal DNS Server

6 | BlueCat Networks
branch office allowing devices at remote offices to obtain their addresses remotely. A decentralized approach places DHCP servers in remote offices and locations allowing clients to obtain dynamic IP addresses locally. Deciding which approach to take depends on a number of factors including: In a DHCP Failover relationship, each server is aware of any leases assigned by its peer server. This cooperating relationship keeps the address database on each server synchronized. As a result, Failover is able to provide service continuity in the event of hardware, software or network failure without the need to manually reconfigure address pools.

Size of office or branch does the size of the branch or office warrant its own DHCP server? If the number of devices at a location is quite small, you may be able to get away with manual allocation. This can change quickly however, as the number of devices can grow quickly, especially with the advent of IP phones and wireless devices. Available bandwidth if the available bandwidth is an issue, consider deploying DHCP locally. Even though DHCP traffic is considered to be light, an already overtaxed WAN connection may not be able to sustain the level of traffic needed to provide adequate DHCP service. Address availability if a device cannot get an address, it falls off the network. If your remote location does not have redundancy built into its DHCP solution, whether through their WAN connection or other devices on their network, losing connectivity with the remote server can result in a loss of addresses. Having a backup solution in the event of connectivity loss is an important part of a disaster-recovery plan.

Conclusion
This paper outlines some of the choices available to network designers implementing DNS and DHCP solutions. It offers recommendations to help secure IP networks, reduce service outages, and enhance network performance. While there are always trade-offs to be made in any network design particularly when budgetary constraints are factored in designs that take best practices into account allow you to minimize the negative impact of design trade-offs as much as possible. As IP networks continue to grow in size and complexity, and as the threats to network security evolve, we can expect best practice recommendations to keep pace, addressing the new challenges of modern, dynamic network infrastructures. When considering the best practices mentioned above, BlueCat Networks is well situated to provide a DNS and DHCP appliance solution designed to meet the requirements and needs of any organization. The Adonis DNS/DHCP Appliance is a purposebuilt secure appliance that leverages the years of experience and expertise that BlueCat Networks has acquired to deliver a solution that addresses DNS and DHCP best practices. Current status as an industry leader in DNS and DHCP solutions means BlueCat Networks is well-positioned to meet the needs of any organization.

Primary DHCP
Replication

Secondary DHCP

DHCP Failover
As with DNS, eliminating single points of failure is more of a necessity than a best practice. Single server deployments are always more susceptible to outages than solutions that take redundancy into account. If a DHCP server goes down for an extended period of time, dynamically-configured IP devices (which are most of the current devices) eventually lose network connectivity. Redundancy in DHCP design is critical. For maximum reliability, BlueCat Networks recommends running DHCP Failover between two DHCP servers. While you have the option of placing both servers at the same location, for many of the same reasons discussed in the DNS section, we recommend separating the servers geographically with one server located at the local site and the second located at the main or regional headquarters. This way, should the local server fail, DHCP services are still provided by the remote server.

About BlueCat Networks

Founded in 2001, BlueCat Networks the IPAM Intelligence Company is a leader in providing enterprise-class IP Address Management (IPAM) platforms and secure DNS/DHCP network appliances. BlueCat Networks services an account base of over 1000 accounts with thousands of units sold worldwide. Our award-winning ProteusTM IPAM platforms and AdonisTM family of DNS/DHCP appliances has successfully garnered end-user acceptance by meeting the rising IP management demands of healthcare, government, financial services, education, retail, and manufacturing organizations. BlueCat Networks, a worldwide market leader in IPAM innovation and thought leadership, is benchmarking IPAM excellence in the networking industry. BlueCat Networks experiences overwhelming marketplace acceptance of its networking solutions, resulting in high double digit growth, year over year, since the companys inception. BlueCat Networks is headquartered in Toronto, Ontario, Canada with offices in the United States, Europe and the Asia Pacific region. It sells networking appliances and services worldwide through direct and indirect sales channels in over 50 countries.

To Learn More
For more information on BlueCat Networks, and our award winning Proteus IPAM solutions, please visit our website at www.bluecatnetworks.com or call us at 1-866-895-6931.

North American Corporate/R&D Headquarters: 502-4101 Yonge Street Toronto, ON M2P 1N6 Phone: +1.416.646.8400 Fax: +1.416.225.4728 Toll Free: +1.866.895.6931 US Offices: Reston, VA 1818 Library Street Suite 500 Reston, VA 20190 Phone: +1.703.956.3551

European Head Office: BlueCat Networks BV Herengracht 466-2 1017CA Amsterdam The Netherlands T: +31 20 754 64 85

United Kingdom BlueCat Networks Europe Merlin House Brunel Road Theale Berkshire RG7 4AB Phone: +44.118.902.6680 Fax: +44.118.902.6401

Germany BlueCat Networks (Zentraleuropa) Altrottstrasse 31 D-69190 Walldorf, Germany Telephone: +49.6227.38489.10 Fax: +49.6227.38489.18

Asia Pacific Head Office 1 Fullerton Road #02-01 Singapore 049213 Phone: +65 6832 5124 Fax: +65 6408 3801

Shanghai, China 12/F, Shui On Plaza, No. 333 Huai Hai Zhong Rd Luwan District Shanghai, China

Hong Kong S.A.R. Suite 1308, 655 Nathan Rd Kowloon, Hong Kong Phone: +852.2309.6874 Fax: +852.2216.6656

Atlanta, GA 1165 Sanctuary Parkway Suite 260 Alpharetta, GA 30009 Phone: +1.770.777.2461 Fax: +1.770.777.2464

Chicago, IL 300 East 5th Avenue Suite 440 Naperville, IL 60563 Phone: +1.630.946.6297

Philadelphia, PA 1500 Market Street 12th Floor / East Tower Philadelphia, PA 19102 Phone: +1.215.246.3400

Los Angeles,CA 4640 Campus Drive Suite 103 Newport Beach, CA 92660 Phone: +1.949.260.8444

Beijing, China D202/2502 Topbox, No. 69 West Beichen Road Chaoyang District, Beijing China, 100029 Phone:+ 86.10.8202.4226 Fax: +86.10.8202.6488

2011. BlueCat Networks, the BlueCat Networks logo, the Proteus logo, IPAM Appliance, the Adonis logo, Adonis are trademarks of BlueCat Networks, Inc. Microsoft, Windows, and Active Directory are registered trademarks of Microsoft Corporation. Any product photos shown are for reference only and are subject to change without notice. All other product and company names are trademarks or registered trademarks of their respective holders. Printed in Canada.

bluecatnetworks.com