DNSSEC - SECURE DNS FOR GOVERNMENT. Whitepaper

Transcription

1 DNSSEC - SECURE DNS FOR GOVERNMENT Whitepaper

2 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 2010, 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 Yonge Street, Suite 502 Toronto, Ontario Canada M2P 1N6 Attention: Product Manager Telephone: Fax: info@bluecatnetworks.com Website: 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.

3 DNSSEC - Secure DNS for Government iii Executive Summary DNS is a pivotal component of every network. Without it, critical business services such as and web access cannot function. Given the Internet s dependence on DNS, it is essential to ensure the security of DNS services. A vulnerable DNS server is often an entry point for attackers that could leave an organization without DNS services. Even worse, a DNS attack could redirect DNS requests to the attacker s sites, where information could be stolen. With recent DNS exploits, such as the one discovered by Dan Kaminsky, which was covered by almost every major news publication, organizations need to be more concerned with the security of their DNS systems. The National Institute of Standards and Technology [NIST] has documented a set of recommendations that outline the risks associated with DNS and steps necessary to secure your environment against such risks. The guidelines to secure DNS as outlined by NIST consist of a set of generic and DNS-specific recommendations for: Securing the DNS hosting environment Protecting DNS transactions DNS security administration This document examines the standards and guidelines as outlined by NIST, and demonstrates the ways in which BlueCat Network s DNS solution address these guidelines.

4 iv BlueCat Networks Contents Executive Summary... iii BlueCat Networks Products...1 Scheduled Key Rollovers...12 Emergency Key Rollovers...14 Re-signing a Zone...14 Securing the DNS Hosting Environment...2 Securing the Host platform...2 Securing the DNS software...2 Conclusion...15 References...15 Securing the DNS Data...5 Protecting DNS Transactions...5 Restricting Transactions based on IP address...5 DNS Queries and Responses...6 Restricting Zone Transfers...6 Restrict Dynamic Updates...6 Sending DNS NOTIFY Messages...6 Restricting Transactions using Transaction Signatures (TSIGs)...7 Securing Dynamic Updates Using TSIG...8 Securing DNS Queries and Responses...8 DNSSEC...8 Protecting Transactions...8 Public Key Publishing and Trust Anchors...10 Zone Signing...10 Trust Chains and Signature Verification...10 Securing the DNS Data...11 Appropriate SOA Values...11 Information Leakage...11 Using RRSIG Validity Periods to Minimize Key Compromise..12 Hashed Authenticated Denial of Existence...12

5 DNSSEC - Secure DNS for Government 1 BlueCat Networks Products BlueCat Networks is a leading provider of DNS server and management appliances. The Adonis DNS/DHCP appliance provides a robust secure DNS appliance for hosting DNS services, as well as providing DHCP services for an organization. With the option to be configured in high availability pairs, Adonis is resistant to a single system failure providing continuous DNS services for an organization. All configuration changes are performed through the Proteus user interface, providing an organization with the ability to enforce strict controls to restrict access to sensitive or critical data. After configuration changes have been accepted, they can easily be deployed to the Adonis servers, where DNS services are hosted. The Adonis appliance and its DNS and DHCP services are managed using the Proteus IPAM appliance, which also provides the ability to track and manage an organization s entire IP infrastructure. With support for a heterogeneous environment, Proteus can manage any number of Adonis DNS/DHCP appliances, as well as manage Windows DNS and DHCP in distributed environments. Proteus provides a single centralized management platform that can be used to manage multiple DNS servers, regardless of the server location. Branch Office Branch Office Proteus Management Agent Windows Windows Proteus 5000 Head Office Branch Office

6 2 BlueCat Networks Securing the DNS Hosting Environment As outlined by NIST, the DNS hosting environment consists of three (3) elements associated with installing and running DNS in an organization s environment: Host platform (operating system, file system and communication stack) DNS software (name server, resolver) DNS data (zone file, configuration file) Each of the three elements is examined, outlining the associated threats with each, and how BlueCat addresses them. Securing the Host platform NIST describes six (6) threats to the DNS host platform: The operating system or any other application software on the DNS host could be vulnerable to attack The TCP/IP stack could be subjected to packet flooding Malicious users with access to the DNS host could launch an ARP spoofing attack The platform could be corrupted by viruses, worms, or any other unauthorized modifications DNS configuration files could be corrupted by viruses, worms or any other unauthorized modifications A malicious host could intercept and redirect DNS responses to a different site. In order to protect against the above threats, NIST recommends the following: Install the latest operating system and ensure that patches are up-to-date Hosts that run name server software should never provide any other services and are configured to respond to DNS traffic only BlueCat s Adonis DNS appliances are able to meet the recommendations set forth by NIST: Latest operating system and patches In order to ensure that the system is up-to-date with the latest security patches, organizations need to patch and maintain the operating system on which the name server software resides. This can be a cumbersome task. The benefit of an appliance solution is that the vendor maintains the hardware, operating system and server application on behalf of the customer. Updates and patches to the operating system are maintained by the appliance vendor, relieving the organization of the need to monitor and patch the systems themselves. As part of BlueCat s appliance approach, Adonis DNS and Proteus IPAM systems are kept up-to-date with the latest version of the underlying customized secure operating system: BCNOS. BlueCat Networks is a participant in the CERT advisory notifications, which provides BlueCat with advanced notification of any potential security risks to the applications running on the system. Such advanced notification of any impending security risk gives BlueCat Networks enough time to address or mitigate the security risk. Streamlined applications and programs In order to prevent the compromise of the DNS service through another application, all unnecessary applications and programs should be removed from the system. This purposed approach to the underlying operating system, coupled with BlueCat s vigilant monitoring of DNS security advisories minimizes the security risk. BlueCat s dedicated DNS appliances run only the applications and programs needed to properly host DNS. All unnecessary programs, including common applications used to traverse the network, have been removed from the system. Securing the DNS software The threats to DNS software, as outlined by NIST, are: Vulnerabilities in the DNS software that could result in attacks Access control limitations allowing unauthorized access to DNS configuration and data information In order to protect against these threats, NIST recommends the following recommendations: Always run the latest version of name server software, or an earlier version with appropriate patches Disable name server version querying Name server software should be run with restricted privileges Name server software should be isolated Name servers should have separate instances for each DNS function Name server software should be removed from nondesignated hosts Distribute name servers geographically Separate public and private DNS information Separate servers for external and internal DNS hosting BlueCat s Adonis DNS/DHCP appliance, managed by the Proteus IPAM appliance addresses all of the recommendations for securing the DNS software as outlined by NIST.

7 DNSSEC - Secure DNS for Government 3 Run the latest version of software BlueCat Networks implements ISC s BIND and maintains the underlying DNS software on behalf of the customer, ensuring that the latest stable version of DNS is always provided. As a Patron member of ISC, BlueCat Networks receives advanced notification of all software updates and security patches. Customers benefit from this relationship, as BlueCat Networks is able to update software and address security vulnerabilities before they are announced to the public. NIST recommends two specific actions, designated as checklist items, for organizations: Checklist item 1: When installing the upgraded version of name server software, the administrator should make the necessary changes to the configuration parameters to take advantage of new security features. Checklist item 2: Whether running the latest version or an earlier version, the administrator should be aware of the vulnerabilities, exploits, security fixes, and patches for the version that is in operation in the enterprise. The following actions are recommended: Subscribe to ISC s mailing list called bind-announce Periodically refer to the BIND vulnerabilities page at html Refer to CERT*/CC s Vulnerability Notes Database at and the NIST NVD metabase at BlueCat addresses both of the above checklist items on behalf of the administrator. BlueCat Networks runs ISC s BIND and maintains the underlying DNS software on behalf of the customer, ensuring that the latest stable version of DNS is always provided. As part of its product maintenance, BlueCat provides customers with software updates that upgrade the name server software as needed. Each software update is carefully scrutinized to determine any new options and settings that could enhance the performance or security of the name server. Where applicable, security features are enabled with best practice defaults. Simply upgrading to the new software update enables the security feature. Although it is good practice for administrators to subscribe to the above mentioned mailing list and review the vulnerability websites, BlueCat does this on behalf of the customer. BlueCat is a Patron member of the ISC and is also on the CERT advisory list, both of which give BlueCat advanced notification to vulnerabilities and exploits as well as early access to patches and fixes. When a security risk is officially announced, BlueCat notify its customer base and provide instructions how to mitigate the issue and/or directions as to where to download the security fix. Disable name server version querying Displaying the software version of the name server gives malicious users added information that can potentially be used as part of an attack. An attacker could be looking for a particular version of the name server software that has a known exploit. Displaying the version number can indicate that your server is running the vulnerable release. NIST provides the following checklist item for organizations to implement: Checklist item 3: To prevent the release of information about which version of BIND is running on a system name servers should be configured to refuse queries for version.bind. BlueCat achieves this checklist item by setting the Version Information option for each managed name server to none. This masks the version information, making it difficult for an attacker to determine the version number and use version-specific exploits and attacks. Run Name Server with Restricted Privileges If the name server software is run as a privileged user account with unrestricted access, an attacker could use a DNS exploit to gain full access to the system. To prevent this from happening, it is strongly suggested as good security practices that you: 1. Configure the name service to run as a nonprivileged user 2. Restrict the account s access to specified directories. These practices are accomplished by running DNS in a chroot jail which serves to isolate a DNS exploit to the DNS service, removing a malicious user s ability to access other programs on the DNS server. By default, all Adonis DNS appliances run using a chroot jail environment. To further protect customers, BlueCat implements a separation of services model, separating the management layer on Proteus from the services layers on the Adonis DNS servers. In this way configuration data is kept on the management server. Should an attack occur and compromise the DNS service, an administrator can easily restore services by deploying the configuration from the management server. Isolating the Name Server Software Securing the DNS software is only one step in providing

8 4 BlueCat Networks a secure infrastructure. A DNS server running additional applications or services could be compromised by vulnerabilities in those applications. An exploit in another program could introduce a system breach resulting in the DNS service being compromised through a back door. Care must be taken ensure that the server does not run any unnecessary applications. BlueCat s BCNOS is stripped of all unnecessary programs and services, leaving only the DNS service and related applications on the system. Name servers should have separate instances for each DNS function While you can configure a DNS server to offer both authoritative and recursive services, this is not a recommended practice. Many DNS exploits, cache poisoning being perhaps the best example, are as a result of issues related to recursive DNS. Simply disabling recursion on an authoritative server eliminates the threat of cache poisoning attacks. It is a recommended best practice to run recursive and authoritative DNS services on separate servers. BlueCat provides support for separating authoritative and recursive services by disabling recursion on all DNS servers by default. In this way, DNS servers hosting zones are not vulnerable to recursion-related attacks. At the same time, BlueCat makes it very easy to enable recursion on servers that are designated to be recursive-only, caching functions. By providing solutions to physically separate authoritative and recursive DNS, BlueCat Networks can help organizations design a secure DNS architecture. By providing solutions to physically separate authoritative and recursive DNS, BlueCat Networks can help organizations design a secure DNS architecture. Limit Name Server Software to Designated Name Servers It is strongly suggested that an organization ensures that DNS software is not installed on any hosts that are not designated as name servers and that DNS software is restricted to dedicated systems. BlueCat s provides dedicated DNS appliances to remove the need for organizations to run DNS software on any non-designated servers; however, this recommendation must be enforced by the administrator. BlueCat has no control or authority over other devices that may be running DNS applications. Distribute name servers geographically Most organizations run at least two authoritative DNS servers for authoritative hosting a primary and at least one secondary. Running two servers provides a level of built-in redundancy for DNS, removing a single point of DNS failure. It is a good practice to locate the secondary server on different network from the primary. If running more than one secondary server, it is best to separate each one on a different network. Separating the servers in geographically disparate locations further reduces any single point of failure from a single device, such as a router. Geographic and network dispersion also serves to protect against natural disasters that can affect multiple servers residing in the same location, even if they are on different network segments. NIST provides checklist recommendation for geographically dispersing name services: Checklist item 4: The authoritative name servers for an enterprise should be both network and geographically dispersed. Network based dispersion consists of ensuring that all name servers are not behind a single router or switch, in a single subnet, or using a single leased line. Geographic dispersion consists of ensuring that not all name servers are in the same physical location, and hosting at least a single secondary server off site. BlueCat supports geographically distributed name servers by providing the ability to manage DNS services located in geographically disparate sites from a centralized webbased interface: Proteus. Proteus gives administrators a single point of management for all DNS services, regardless of where they are located. Additionally, BlueCat provides further support for this best practice though our support of Anycast, to provide additional load balancing and fault tolerance above and beyond the traditional primary-secondary DNS server model. Anycast redirects DNS queries to the site closest to the client to provide faster DNS response times and bringing load balancing to a new level. Should a DNS server in an Anycast network become unavailable, the Anycast routing tables are updated accordingly so that the disabled server is not included in a response. Checklist item 5: If a hidden master is used, the hidden authoritative master server should only accept zone transfer requests from the set of secondary zone name servers and refuse all other DNS queries. The IP address of the hidden master should not appear in the name server set in the zone database. The hidden master architecture brings security and performance benefits by allowing you to remove the primary (master) server from the exposed network and place it behind the internal firewall on the trusted side of

9 DNSSEC - Secure DNS for Government 5 the network. Additionally when using a hidden master, the primary server s glue (server s own host record) and authority (name server record) are not added to the DNS zone. In this way, anyone querying the zone is not made aware of the hidden master. BlueCat supports the stated hidden master requirements in two ways. Firstly, by default, the hidden master only accepts zone transfer requests from the secondary name servers; secondly, the IP address (glue record) of the hidden master does not appear in the name server set in the zone database. Separate public and private DNS information Organizations generally maintain DNS for both internal and external users. External DNS is public facing and is consumed by users external to the organization. Internal DNS is private facing and consumed by users within the organization. Internal DNS often contains sensitive information, such as the location of database and mail servers, and should never be exposed to users outside of the organization. Separation of internal and external DNS can be accomplished through the use of split DNS. Split DNS allows DNS information to be split into separate configurations one for public consumption and one for private. Separate servers for external and internal DNS hosting NIST provides the following checklist item recommending that DNS be split to separate internal and external information: Checklist item 6: For split DNS implementation there should be a minimum of two physical files or views. One should exclusively provide name resolution for hosts located inside the firewall. It also can contain RRsets for hosts outside the firewall. The other file or view should provide name resolution only for hosts located outside the firewall or in the DMX and not for any hosts inside the firewall. BlueCat provides support for split DNS to allow customers to easily separate internal and external DNS information. This can easily be accomplished through the Proteus interface, which allows administrators to set up a distinct view for each DNS segment. Proteus provides further support by allowing administrators to create separate administrative access for each view. This allows organizations to restrict certain DNS administrators to the internal DNS view and a separate set of DNS administrators to only the external DNS view. If desired, neither set of administrators can access information in the others area unless explicitly given access. Instead of using views to separate internal and external DNS information, organizations can physically separate this information by deploying a distinct set of name servers for internal DNS data and separate set of name servers for external DNS data. This architecture ensures that public users are not able to access private information as internal host data resides on a separate set of name servers that are inaccessible to public clients. BlueCat provides support for this infrastructure by allowing organizations to manage both internal and external name servers from the same Proteus interface. From Proteus, administrators can manage internal and external DNS data from the same interface, and then deploy different sets of data to the separate internal and external DNS servers respectively. Securing the DNS Data The third element in securing the DNS hosting environment is to protect the data in the DNS zone and configuration files. BlueCat provides a number of ways to ensure that DNS data are free of errors. From Proteus, you can configure two integrity checkers to be run: one for the zone files and a second one for the DNS configuration files. Additionally, Proteus includes other tools such as an error checking system which validates data as you enter it and a data checking tool which enforces best practices. Combined with a number of additional tools, Proteus takes a layered defense in depth approach to validation to ensure clean data Protecting DNS Transactions The approach taken to securing against threats to DNS transactions depends on the type of transaction. NIST organizes the approaches into three distinct groups: Restricting Transactions based on IP Address Transaction Protection through Hash-Based Message Authentication Codes (TSIG) Transaction Protection through Asymmetric Digital Signatures (DNSSEC) Each type of approaches is discussed in its own section. Restricting Transactions based on IP address NIST identifies four areas of concern with respect to restricting DNS transactions based on IP address. Each of the four DNS transaction

10 6 BlueCat Networks elements is examined below, outlining the associated threats, and how BlueCat addresses them: DNS query/response Zone transfers Dynamic updates DNS NOTIFY transactions DNS Queries and Responses NIST provides the following checklist recommendations when restricting DNS queries and responses: Checklist item 7: It is recommended that the administrator create a named list of trusted hosts (or blacklisted hosts) for each of the different types of DNS transactions. In general, the role of the following categories of hosts should be considered for inclusion in the appropriate ACL: DMZ hosts defined in any of the zones in the enterprise All secondary servers allowed to initiate zone transfers Internal hosts allowed to perform recursive queries Administrators can define access control lists (ACLs) of allowed IP addresses in Proteus, and then apply them to different types of DNS transactions. For example, you can create a list of the IP addresses of hosts that are allowed to query your DNS server or perform dynamic updates in a zone. After you deploy the changes to the DNS servers, only the hosts defined in the lists are allowed to access the server. In addition to defining IP addresses or IP prefixes you can add any of the following special values in access control statements: None: matches no hosts Any: matches all hosts Localhost: matches all IP addresses of the server on which the name server is running Localnets: matches all IP addresses and subnet masks of the server on which the same server is running. Restricting Zone Transfers You can restrict DNS zones to indicate which systems can request and receive zone transfers. You should always restrict zone transfer requests to the secondary servers hosting the zone. This prevents unknown and malicious systems from using the zone transfer mechanism to attack servers using denial of service based attacks against the primary DNS server. It is also a good practice to disable zone transfers on secondary name servers where possible. Proteus automatically restricts zone transfers by default for Adonis servers under its control. When master and slave servers are added to a zone, Proteus automatically limits the master zone to only accept zone transfer requests from the IP addresses of the slave servers. No other IP addresses are allowed to request a zone transfer by default. In addition, because secondary name servers do not generally transfer zones to other servers, by default secondary servers are configured to not accept any zone transfer requests. If under certain circumstances, you need to allow zone transfers from a secondary server, you can easily add IP addresses to the secondary server. Configuring these values on behalf of the administrator eases a great deal of administrative burden as well as greatly lessening the potential for human error. For non-adonis slave servers that are communicating with a master Adonis server, you can configure the Allow Zone Transfer option from the Proteus UI, at the zone, view and server level. Populating this option updates the Adonis master with the addresses of the slave servers that are allowed to request zone transfers. Restrict Dynamic Updates The copy of the zone that resides on the primary server can be updated dynamically by hosts capable of issuing dynamic updates. As with zone transfers, dynamic DNS updates should be restricted to the IP addresses or ranges of specific DHCP servers and known clients. BlueCat provides the ability to restrict dynamic DNS updates to a set of IP addresses by adding an ACL to the Allow Dynamic Updates option at either the view or zone level. One of the advantages of the Proteus product is its inheritance model when assigning options. Option settings assigned at a higher level are inherited at lower levels which can save a significant amount of administrative overhead. Sending DNS NOTIFY Messages When a change is made in the zone file on the primary name server, by default, a DNS NOTIFY message is sent to all secondary name servers informing them of the change. Upon receiving the NOTIFY message, the secondary servers send a message to the primary server requesting a zone transfer. The main threat to DNS NOTIFY messages, as outlined by NIST are false NOTIFY messages received by secondary name servers from sources other than the primary name server. In order to protect systems against these NOTIFY messages, organizations are encouraged to restrict DNS NOTIFY messages on both the primary and slave systems. The primary is configured to send NOTIFY messages only to the configured secondary servers and the secondary servers are configured to only receive NOTIFY messages from their associated primaries.

11 DNSSEC - Secure DNS for Government 7 When configuring a master-slave relationship on Proteus, DNS notifications are configured automatically. The primary DNS server is configured to send notifications only to the addresses of the secondary servers listed in Proteus. On the secondary servers, notifications are only accepted by the primary server. Restricting Transactions using Transaction Signatures (TSIGs) TSIG is a set of DNS specifications used to authenticate the source of a DNS message and verify its integrity using hash-based message authentication codes (HMAC). An HMAC function consists of two elements: the message and a secret key. The two parties involved in a message exchange, the sender and the receiver, share a secret key. The sender applies the key to the message, and produces an output called a hash. Upon receiving the hash, the receiver compares the received hashed message to a computed message. If they match, the receiver can verify that the message was not altered (integrity) and that it came from a trusted source (authentication). Shared secret solutions are not very scalable due to the inherent challenge of transferring the key from one party to the other in a secure fashion. As a result, TSIG is generally used only for zone transfers and dynamic updates. NIST makes the following checklist recommendations when generating TSIG keys: Checklist item 8: The TSIG key should be a minimum of 112 bits in length if the generator utility has been proven to generate sufficiently random strings [800-57P1]. The generated TSIG key may have to be longer to ensure at least 112 bits of security. Checklist item 9: A unique TSIG key should be generated for each pair of communicating hosts (i.e., a separate key for each secondary name server to authenticate transactions with the primary name servers, etc.) Checklist item 10: After the key string is copied to the key file in the name server, the two files generated by the dnssec-keygen program should either be made accessible only to the server administrator account (e.g., root in Unix) or, better still, deleted. The paper copy of these files also should be destroyed. Checklist item 11: The key file should e securely transmitted across the network to name servers that will be communicating with the name server that generated the key. Checklist item 12: The statement in the configuration file (Usually found at etc/named.conf for BIND running on Unix) that describes a TSIG key (key name [ID], signing algorithm, and key string) should not directly contain the key string. When the key string is found in the configuration file, the risk of key compromise is increased in some environments where there is a need to make the configuration file readable by people other than the zone administrator. Instead, the key string should be defined in a separate key file and referenced through an include directive in the key statement of the configuration file. Every TSIG key should have a separate key file. Checklist item 13: The key file should be owned by the account under which the name server software is run. The permission bits should be set so that the key file can be read or modified only by the account that runs the name server software. Checklist item 14: The TSIG key used to sign messages between a pair of servers should be specified in the server statement of both transacting servers to point to each other. This is necessary to ensure that both the request message and the transaction message of a particular transaction are signed and hence secured. Unique TSIG keys are created automatically during a deployment from Proteus to the Adonis master and slave DNS servers. Proteus uses a unique object identifier to create a random seed that is sent to each Adonis server through an SSL encrypted connection. The random seed is then used on each Adonis system to generate the TSIG. Finally, the TSIG information is automatically added to the configuration files on behalf of the administrator removing all manual user interaction. The following set of points presents further details about the key creation process: TSIG key size by default, all TSIG keys automatically generated by Adonis are 128 bits in length. TSIG uniqueness Proteus automatically generates a unique set of TSIG keys for each master-slave relationship. This is done automatically on behalf of the administrator. TSIG file generation because Proteus automatically creates TSIG keys on the fly, there are no residual files. Proteus automatically generates the keys, and then adds they keys to each name server with the proper settings. There are no paper copies or other residual files as a result, eliminating the need for user intervention. TSIG key transmission all communication between Adonis and Proteus is SSL encrypted to ensure that data in transmission is not compromised.

12 8 BlueCat Networks TSIG key file storage key information is stored in the DNS configuration file. Administrators are not given access to the configuration files, and hence cannot view the keys. Given the security of BlueCat s dedicated appliances and the fact that the configuration file is kept in a jailed environment, there is little risk of exposure. TSIG key file permissions because TSIG keys are generated on the fly and never seen by administrators, there is no need to separate them from the DNS configuration file. TSIG key for transactions when creating a TSIG key, Adonis not only generates the key, but it adds it to the appropriate configuration file on each server. The master and slave servers are configured to restrict zone transfers to only servers with the corresponding TSIG key. Organizations benefit from BlueCat s automated approach to TSIG generation in that they get the security that TSIGs provide without the additional overhead needed to configure them. Keys are automatically generated, transmitted, and maintained on behalf of the administrator reducing the effort of setting up TSIGs to a simple master server and slave server definition. NIST recommends that the system clocks of all participating DNS servers must be synchronized to ensure a successful and secure implementation of TSIGs. All BlueCat DNS appliances include an embedded NTP client to synchronize their system clocks with the Proteus management appliance. This ensures that the times on all Adonis systems are kept in sync. Securing Dynamic Updates Using TSIG Dynamic updates can also be protected using TSIG keys. Using the same recommendations as outlined for protecting zone transfers, organizations are able to authenticate the source of the updating client and verifying the integrity of the data. Proteus provides administrators with the ability to configure TSIGs for dynamic updates through its user-defined DNS options function Raw Options. An administrator wanting to protect dynamic updates using TSIG keys can simply add the TSIG key they want to use as a user-defined option and then add an additional user-defined option to restrict updates. Securing DNS Queries and Responses There are several threats to the DNS query and response mechanism as outlined in IETF RFC 3833 and reiterated by NIST. These include: Forged or bogus responses originating from a compromised authoritative name server or the poisoned cache of a resolving name server Removal of some resource records from the response of a compromised or poisoned server Incorrect expansion rules applied to wildcard resource records In order to safeguard systems against these threats, NIST makes the following two recommendations: Restrict which hosts are allowed to submit queries by IP address Protect transactions through DNS security extensions (DNSSEC) BlueCat s Adonis DNS appliance addresses these recommendations by providing organizations with the means to restrict and protect DNS queries and responses. DNSSEC Protecting Transactions DNSSEC protects DNS query/response transactions in three ways: Data origin authentication Data integrity verification Authenticated denial of existence capabilities. NIST recommends that organizations enable DNSSEC to protect DNS transactions: Checklist item 15: Name servers that deploy DNSSEC signed ones or query signed zones should be configured to perform DNSSEC processing. BlueCat provides full DNSSEC support. To enable DNSSEC on an Adonis DNS server, an administrator need only enable the DNSSEC option for the server from the Proteus user interface. For DNSSEC, there are several name server operations that occur and must be taken into consideration for a secure DNSSEC implementation to occur: Generation Of Public Key-Private Key Pair When choosing the components of a key, you must consider three parameters: Digital Signature Algorithm Size of the Keys Duration for which the key will be used

13 DNSSEC - Secure DNS for Government 9 The following table summarizes the NIST recommendations for DNSSEC keys: Key Type Digital Signature Algorithm Suite Key Size Crypto Period (Rollover Period) Key Signing Key (KSK) RSA-SHA bits months (1-2 years) Zone Signing Key (ZSK) RSA-SHA bits 1-3 months (30-90 days) Key Signing Key Because the KSK is used to sign the key sets, performance is less of an issue than that of the ZSK. However, compromise of the KSK has a significant impact as the KSK is the entry point for a zone. To protect against a compromise, a large key size should be implemented. NIST recommends a crypto period of 1-2 years before rolling over the Key Signing Keys. Administrators can easily generate the KSK and ZSK using the Proteus user interface. Proteus uses DNSSEC zone signing policies to configure the necessary parameters in a single place. After configuring the settings, the administrator assigns them to the zones. BlueCat offers the following choice of parameters when configuring the KSK: Digital Signature Algorithm: RSA-SHA1, DSA-SHA1 and RSA-MD5, RSASHA1NSEC3SHA1, DSANSEC3SHA1 (default RSA-SHA1 Key Length (in bits) (default 2048 bits) Validity Period - User defined (default 360 days) Zone Signing Key Because the ZSK is used to sign all the resource records in the zone, performance is a factor. Key compromise is less likely for the ZSK compared to the KSK because the KSK is changed more regularly. Hence a smaller key than the KSK can be used. However, because the smaller key size increases the KSK s exposure, a shorter crypto period is suggested. NIST recommends that ZSKs be rolled over every days. BlueCat offers the following choice of parameters when configuring the ZSK: Digital Signature Algorithm: RSA-SHA1, DSA-SHA1 and RSA-MD5, RSASHA1NSEC3SHA1, DSANSEC3SHA1 (default RSA-SHA1) Key Length (in bits) (default 1024 bits) Validity Period - User defined (default 30 days) Administrators can use the Proteus interface to meet the DNSSEC recommendations set forward by NIST. Key Storage To prevent the compromise of the KSK and ZSK key pairs, NIST makes the following checklist recommendation about storing DNSSEC keys: Checklist item 16: The private keys corresponding to both the ZSK and KSK should not be kept on the DNSSECaware primary authoritative name server when the name server does not support dynamic updates. If dynamic update is supported, the private key corresponding to the ZSK alone should be kept on the name server, with appropriate directory/file level access control list-based or cryptography-based protections. If supporting dynamic updates, the above recommendations are not feasible due to the fact that the private keys must be available on the DNS server in order to sign the dynamically generated records. In order to support dynamic updates, the ZSK and KSK private keys are kept on the Adonis server. To reduce the exposure of the keys, BlueCat has implemented a number of security measures, as outlined earlier in the document, to increase the overall security of the system and reduce exposure. The recommended actions along with BlueCat s measures are listed in the following : Restrict command level access to the DNS server - Remote access is disabled by default. Command level access is restricted to both the Proteus and Adonis servers. This helps to limit exposure to the operating system. Restrict the directory where the keys are store - All keys on the Adonis server are stored in a restricted area within the jailed DNS environment. Provide a sufficient level of fault tolerance for the device to backup to existing device - Adonis provides several fault tolerance options to ensure that all configuration data is backed up. In particular, there are two relevant options: Crossover High Availability (XHA) provides the ability to cluster Adonis systems in an active/passive pair. Should the active system become unavailable, the passive system detects this, becomes active and serves DNS requests. All information is automatically synchronized between the active and passive pair to ensure that no data is lost and all information is exact on both systems. XHA ensures that organizations are never left without DNS running. Separation of services all configuration data for on Adonis server under control of Proteus is kept in the Proteus database. This provides a backup of all DNS data on the management server in case of a failure.

14 10 BlueCat Networks Should an Adonis system need to be replaced, Proteus contains the entire configuration for the Adonis system, which can then be copied to the replacement unit within minutes. This separation of services and management ensures that organizations can quickly get back up and running in the event of a failure. Provide a sufficient level of fault tolerance for the device to backup to existing device - Although neither Proteus nor Adonis implement a file encryption system, both servers are secured against attack to limit exposure. The ZSK signs all resource record sets in the zone NIST makes the following checklist recommendation regarding zone signing: Checklist item 17: Signature generation using the KSK should be done offline, using the KSK-private stored offline or using a secure, protected module; then the DNSKEY RRSet, along with its RRSIG RR, can be loaded into the primary authoritative name server. Public Key Publishing and Trust Anchors Because there is no native support for third-party authentication in DNS, the public keys must be distributed out-of-band. NIST recommends using channels such as or uploading through web sites to distribute keys. Although providing a method for distributing keys is not within the realm of functionality provided by BlueCat Networks, Proteus does help to facilitate the distribution of public keys through the user interface. In the event that one more KSK public keys need to be delivered to a parent zone to establish a chain of trust, an administrator with the appropriate security privileges can access the public key, and then forward it using a secure distribution method, such as encrypted . In order for a DNSSEC-enabled resolver to properly resolve DNSSEC information for a zone, the resolver must have knowledge of the zone s public key. If the parent of said zone is also DNSSECaware, then DNSSEC-enabled resolver must have knowledge of the parent zone s public key. This is done using trust anchors, which allows administrators to install the public key on a resolver in order to establish trust with those servers hosting the DNSSEC authoritative zones. BlueCat provides the ability to define trust anchors from the Proteus interface to ensure that Adonis, when acting in the role of a DNSSEC resolver can communicate with DNSSEC-aware name servers. Trust anchors are defined from the user interface using a DNS option that defines the zone name and the public key. After enabling the option, the administrator deploys it to the Adonis server. The public keys (Trust anchors) for the associated zone can then be used when resolving DNSSEC information from them. Zone Signing The process for signing a zone involves the following sequence of steps: The zone file is sorted in canonical order of domain names NSEC/NSEC3 resource records are generated for every owner name in the zone The KSK signs the DNSKEY resource record set As discussed earlier, because of the need to support dynamic updates, the ZSK and KSK private keys are kept on the Adonis server. Because the private key is not stored offline, it is not possible to generate signatures offline. To reduce the exposure of the keys, BlueCat has implemented a number of security measures, as outlined earlier in the document, to increase the overall security of the system and reduce exposure. Trust Chains and Signature Verification In order for a DNSSEC-aware resolver to verify the authenticity of the public key for the signed zone, the resolver must be able to trust the public key. If another DNS zone will vouch for the authenticity of the public key, such as the zone s parent, instead of needing to acquire a Trust anchor for the zone, the resolver can establish trust in the zone through its parent. The sequence of zones from parent to child, used to establish trust in the public key is called a chain of trust. A self-signed zone where no chain of trust exists is known as an Island of Security. When configuring a self-signed zone, an administrator must perform the following actions: Generate the public/private key pair Store the private key in a secure manner. Publish of the public key through the DNSKEY RR Generate digital signatures for zone data If configuring a chain of trust between a parent zone and child zone, additional steps need to be taken: Generate the public/private key pair Store the private key in a secure manner. Publish of the public key through the DNSKEY RR Generate digital signatures for zone data Use a secure means of transmission to deliver the child s KSK to the parent zone Generate a Delegation Signer (DS) record and digital signature for the DS record on the parent zone BlueCat s Adonis appliance can act as both an island-of-security and as part of the chain of trust.

15 DNSSEC - Secure DNS for Government 11 Island of Security - Enable DNSSEC for the zone and create the requisite keys on the system. Chain of Trust - when Adonis is part of a chain of trust and is hosting the parent for a DNSSEC enabled zone, delegated signer (DS) records are added to the parent zone. This action is performed automatically on behalf of the organization by the Proteus and Adonis products. When a child zone and its parent are both DNSSEC-enabled, a DS record is automatically created in the parent zone, and then deployed removing the need for an administrator to manually create the DS records. If the parent zone is hosted on a DNS server not under Proteus control, the public portion of the KSK can be retrieved from the Proteus interface, and then forwarded to the administrator of the parent zone using a secure communications channel. Upon receipt, the administrator of the parent zone can create the DS record, and then add it to the parent zone thus establishing the chain of trust. Securing the DNS Data NIST outlines the threats to hosting DNS data as: Lame delegation, in which the fully qualified domain name (FQDN) and/or IP address of name servers have been changed in the child zone but not in the parent. Zone drift, in which the refresh and retry fields in the SOA have been set too high and the zone file is changed frequently, resulting is a potential mismatch between the primary and secondary name servers; and zone trash, in which the refresh and retry values in the SOA have been set too low causing zone transfers to occur too frequently. Unintended exposing of information, such as HINFO and TXT records, which can provide software and version information that can be used by attackers. In order to protect against these threats, NIST recommends that organizations take caution when configuring DNS. In particular they recommend that organizations: Choose appropriate Start of Authority (SOA) values Take the necessary precautions when configuring informational resource records BlueCat s Adonis DNS appliance, under Proteus control addresses each of these concerns: Appropriate SOA Values When configuring a start of authority records, NIST provides the following checklist recommendations: Checklist item 18: The refresh value in the zone SOA RR should be chosen with the frequency of updates in mind. If the zone is signed, the refresh value should be less than the RRSIG validity period. Checklist item 19: The retry value in a zone SOA RR should be 1/10th of the refresh value. Checklist item 20: The expire value in the zone SOA RR should be 2 to 4 weeks. Checklist item 21: The minimum TTL value should be between 30 seconds and 5 days. When an administrator creates a Start of Authority record in a zone, the settings are configured with the following pre-defined values: Refresh 3600 seconds Retry 600 seconds Expire (4 weeks 2 days) Minimum TTL 3600 If an administrator does not explicitly define a SOA record in a zone, Proteus creates the record automatically on deployment to the Adonis DNS servers and assigns a set of pre-defined values. Information Leakage There are several resource records in DNS that are designed to relate information about a host, such as the Text (TXT) and Host Information (HINFO) records. While sometimes useful, these record types can be potentially dangerous if they contain sensitive information. An HINFO record could contain information about the host s operating system that could be used by an attacker and a TXT record can contain any text string at all. Because of the potential for sensitive information leakage, care should be taken before adding these records to a zone... NIST provides the following checklist recommendations when configuring these types of resource records: Checklist item 22: A DNS administrator should take care when including HINFO, RP, LOC, or other RR types that could divulge information that would be useful to an attacker or the external view of a zone if using split DNS. These RR types should be avoided if possible and only used if necessary to support operational policy. Checklist item 23: A DNS administrator should review the data contained in any TXT RR for possible information leakage before adding it to the zone file. Proteus makes it easy to address both recommendations. Proteus allows an administrator to limit the types of

16 12 BlueCat Networks resource records that can be added to a DNS zone using access controls. Preventing junior and other administrators from creating these types of records helps to ensure that sensitive data is not exposed. To prevent information leakage through TXT resource records, system administrators can enable Proteus workflow module, which adds a change approval mechanism. Administrators adding TXY records can be required to submit their changes for approval to a senior administrator before these records are added to the database. This provides a review process and helps to prevent mistakes such as accidental information leakage. Using RRSIG Validity Periods to Minimize Key Compromise A compromised key could have serious repercussions for an organization. An effective strategy to limit key compromise is to limit the resource record s signature (RRSIG) validity period within a zone and its parent. A suitably short signature validity period limits the window that an attacker has to take advantage of a compromised key. An attacker can only use a compromised ZSK during the KSK s signature validity period. Similarly, an attacker can only use a compromised KSK for as long as the signature validity interval of the RRSIG covering the DS record in the delegating parent. To minimize the impact of key compromise, NIST makes the following checklist recommendations: Checklist item 24: The validity period for the RRSIGs covering a zone s DNSKEY RRSet should be in the range of 2 days to 1 week. This value helps reduce the vulnerability period resulting from a key compromise. Checklist item 25: A zone with delegated children should have a validity period of a few days to 1 week for RRSIGs covering the DS RR for a delegated child. This value helps reduce the child zone s vulnerability period resulting from a KSK compromise. While every DNSSEC Signing Policy is configured with pre-set values, an administrator can change the validity period for the RRSIG for all resource records from the policy. Note that when an administrator changes the validity period, it is changed for all resource records including the DNSKEY and DS records. Hashed Authenticated Denial of Existence One of the resource records in the DNSSEC specifications, the NSEC resource record, was included to provide authenticated denial of existence. If a client queried a server for a record that did not exist, an NSEC record was returned as part of the response. The NSEC response included the closest record in the canonical listing of the zone. By issuing queries for records that do not exist, a client could then walk the zone by sending a series of follow-up queries. While zone enumeration does not constitute an attack on its own, it could provide an attacker with enough information to formulate an attack. A new resource record was introduced to minimize information leakage through zone enumeration. The NSEC3 resource record is very similar in format to the NSEC resource record but it uses a hash of the owner name and the next name to obscure the information. NIST makes the following checklist recommendations with regards to NSEC3 resource records: Checklist item 26: If the zone is signed using NSEC3 RRs, the salt value should be changed every time the zone is completely resigned. The value of the salt should be random, and the length should be short enough to prevent a FQDN to be too long for the DNS protocol (1 to 15 octets should be sufficient). Checklist item 27: If the zone is signed using NSEC3 RRs, the iterations value should be based on available computing power available to clients and attackers. The value should be reviewed annually and increased if the evaluation conditions change. Initial values should be between 1 and 20 iterations when using SHA-1 and 1 and 10 if using SHA-256. BlueCat includes support for NSEC3 resource records to ensure hashed authenticated denial of existence. To sign a zone using NSEC3, the administrator simply selects the appropriate NSEC3 algorithm in the DNSSEC signing policy. DNS Security Administration In addition to protecting the DNS query/response transaction, administrators should be aware of additional security operations that need to be performed in a DNSSEC-enabled environment. Scheduled Key Rollovers Keys used for the KSK and ZSK must be changed periodically because keys are more likely to be compromised after being used for a period of time. A compromise of the private key would mean that a site could spoof a zone by signing resource record data with the private key. A scheduled key rollover is a period of time after which the old key must be replaced with a new key. The frequency after which keys should be changed period is based on the following factors: Larger zone files have a larger data set and hence a greater number of signatures making it easier to crack the private key Smaller private keys are easier to crack Given these two factors, and the recommended key sizes for the KSK

17 DNSSEC - Secure DNS for Government 13 and ZSK, NIST makes the following checklist recommendation: Checklist item 28: The KSK needs to be rolled over less frequently than the ZSK. The recommended rollover frequency for the KSK is once every 1-2 years, whereas the ZSK should be rolled over every month for operational consistency but may be used longer if necessary for stability. Both keys should have an Approved length according to NIST SP Part 1 [800-57P1], [800-57P3]. An administrator can configure a scheduled rollover period for both the ZSK and the KSK from a DNSSEC signing policy. By default, the rollover frequency period is 30 days for a ZSK and 360 days for a KSK. Proteus provides a notification mechanism for keys approaching expiry by allowing an administrator to activate key expiry checks, which are performed at user-defined intervals to determine whether a key is about to expire. Notification can be sent as either an SNMP alert or an to a group of configured administrators when a key is about to expire. This expiration service helps to notify an administrator that a key rollover needs to take place, allowing him to enough time to generate and deploy the new key sets. The impact of a key rollover depends on whether the zone is an island of trust (also known as locally secure) or part of a chain of authority (also known as globally secured). Locally Secured Zone When a zone changes its ZSK, but leaves its KSK unchanged, some distant resolvers or name servers may still have the old key in cache. The solution to this problem is to prepublish the new public key a certain number of days before rollover. The process is as follows: Generate a new key pair. Add the public key of the new key pair to the zone file (DNSKEY record). Sign the zone using the private key of the currently active key pair and the KSK (if present). Wait for a period equal to the TTL of the DNSKEY RRSet or the MinTTL of the zone SOA record (whichever is greater). Delete the retiring DNSKEY RR from the zone key set and the expired RRSIG RRs. Re-sign the DNSKEY RRSet with the new ZSK. NIST makes the following checklist recommendations when rolling over keys in locally secure zone: Zones that pre-publish the new public key should observe the following: Checklist item 29: The secure zone that pre-publishes its public key should do so at least one TTL period before the time of the key rollover. Checklist item 30: After removing the old public key, the zone should generate a new signature (RRSIG RR), based on the remaining keys (DNSKEY RRs) in the zone file. When rolling over the KSK, the secure zone may not know which resolvers are using the current public key as a trust anchor. In this case, administrators should use an out-of-band method to contact any resolver administrators they know of to determine a secure method for disseminating the new public key. For resolvers that are unknown to the administrator, little can be done other than publishing the new KSK with enough time to give resolver administrators time to learn the new KSK. Scheduled rollover is configured automatically as part of a DNSSEC Signing Policy in Proteus. By default, the ZSK uses the pre-publish method by default and the KSK uses the double-signing method by default. Chained Secure Zone The procedure for rolling over a ZSK for a chained secure zone is no different than the procedure for a locally secured zone (as mentioned above). However, there is a difference in the rollover for the KSK, because it is used to provide trust from the zones parent. When a zone changes its KSK, there is the risk of breaking the trust relationship between the zone and its parent. To maintain this trust relationship, the following actions need to be taken: Generate a new KSK Sign the zone key set with the new KSK as well as the old KSK Transfer the new KSK to the parent zone in a way that allows the parent to authenticate it. The parent must generate a new DS RR to replace the old one. In the case of a chained secure zone, it is necessary to notify the parent zone that a change has occurred. Using the key expiry notification service provides administrators with advanced notice that a key is reaching its expiration date. Because BlueCat s products support double signing, once the administrator creates the new set of keys they can be published within the Adonis server. The administrator then needs to send the new public KSK key to the parent. The administrator can obtain the KSK from the Proteus user interface and then send it using encrypted or other secure method to the administrator of the parent zone for inclusion on their server.

18 14 BlueCat Networks Emergency Key Rollovers An emergency key rollover may be necessary if a key in the zone has become compromised, or a private key has been lost. Emergency ZSK Rollover The process for performing an emergency ZSK rollover depends on whether a new DNSKEY record has already been published in the zone as part of a scheduled rollover operation. If the ZSK currently being used is compromised, the administrator can immediately rollover to the new key. There is no need to wait because the new key has already been published for some time. The administrator can remove the old RRSIGs and re-sign with the new ZSK, albeit earlier than expected. If the new ZSK, the one being rolled over to, has been compromised, then the administrator should replace the key immediately and re-sign the zone key set with the new key. There is still the danger that an attacker could use the compromised ZSK to forge responses from the zone. This danger exists as long as the current KSK is valid. Because of this, an administrator should always initiate a KSK rollover whenever a ZSK has been compromised. Because BlueCat supports double signing for keys, an administrator has the ability to create a backup set of keys that are always available. When a zone s KSK has been compromised, the only response is to initiate a KSK rollover with the parent. The administrator of the parent will need to be contacted and the new KSK transmitted and verified using some secure method. NIST makes the following checklist recommendations for communicating an emergency KSK rollover to a parent zone: Checklist item 31: A DNS administrator should have the emergency contact information for the immediate parent zone to use when an emergency KSK rollover must be performed. Checklist item 32: A parent zone must have an emergency contact method made available to its delegated child subzones in case of emergency child subzone KSK rollover. There also should be a secure means of obtaining the subzone s new KSK. Proteus allows administrators to define additional metadata for any object within the database. In the case of DNSSEC keys, an administrator can create a field with a label such as Parent zone contact. The administrator could add this metadata to all DNSSEC keys on the product. When a zone is enabled for DNSSEC, an administrator could enter the emergency contact information into the contact field. In the event that an emergency rollover is required, the contact details would be readily available. Re-signing a Zone The zone file must be re-signed, with new RRSIG records generated, in the following situations: The signatures have expired or are about to expire The zone file content has changed One of the signing keys has been compromised. There are essentially two strategies for re-signing zone data: Complete re-signing all existing RRSIG records are deleted, the zone file is sorted again, all NSEC records are regenerated and the new signature records generated. Incremental re-signing used to generate signatures only for records that have changed, usually as a result of dynamic updates. NIST makes the following checklist recommendations for resigning a zone: Checklist item 33: Periodic re-signing should be scheduled before the expiration field of the RRSIG RRs found in the zone. This is to reduce the risk of a signed zone being rendered bogus because of expired signatures. Checklist item 34: The serial number in the SOA RR must be incremented before re-signing the zone file. If this operation is not done, secondary name servers may not pick up the new signatures because they are refreshed purely on the basis of the SOA serial number mismatch. The consequence is that some security-aware resolvers will be able to verify the signatures (and thus have a secure response) but others cannot. As mentioned above, BlueCat provides the ability to double sign a zone, so that new keys can be pre-published before the old keys are set to expire. To help facilitate this, Proteus provides a key expiry notification service that can used to notify an administrator that a key is about to expire. This provides administrators with an automated tool that gives them ample notice of a key expiration, allowing them to create a new set of keys to pre-publish. BlueCat automatically increments the SOA serial number each time a change occurs. This includes when a zone file is re-signed.

19 DNSSEC - Secure DNS for Government 15 Conclusion DNS is one of the most critical components of every network, but is often one of the most overlooked services. Organizations need to implement the proper security measures in order to provide a secure DNS solution that is resilient to attack and exploit. BlueCat s DNS, DHCP, and IPAM platform provides organizations with the tools they need to secure their DNS infrastructure, without the administrative burden. Through the implementation of security best practices, BlueCat helps to reduce the effort involved in managing DNS by providing strong defaults, automated settings and tools that ease the setup and management of DNS. References R. Chandramouli and S. Rose, Secure Domain Name System (DNS) Deployment Guide, NIST Special Publication r1, February K. Evans, Securing the Federal Government s Domain Name System Infrastructure, OMB Memorandum M-08-23, September m08-23.pdf Given the OMB mandate M for all Federal agencies to implement DNSSEC according to the NIST Special Publication r1, organizations need a solution that provides DNSSEC capabilities. Given the complexity of DNSSEC, BlueCat s products can ease the burden of implementing and administering DNSSEC, as well as address all other DNS security requirements outlined in the NIST Special Publication r1. BlueCat provides a proper management solution, reducing administrative effort, while still delivering and maintaining DNS security for an organization.

20 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 services an account base of over 1000 accounts with thousands of units sold worldwide. Our award-winning Proteus TM IPAM platforms and Adonis TM 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 company s 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 32 countries. To Learn More For more information on BlueCat Networks, and our award winning Proteus IPAM solutions, please visit our website at or call us at North American Corporate/R&D Headquarters: Yonge Street Toronto, ON M2P 1N6 Phone: Fax: Toll Free: EMEA Head Office: United Kingdom BlueCat Networks Europe Merlin House Brunel Road Theale Berkshire RG7 4AB Phone: Fax: Germany BlueCat Networks (Zentraleuropa) Altrottstrasse 31 D Walldorf, Germany Telephone: Fax: US Offices: Reston, VA 1818 Library Street Suite 500 Reston, VA Phone: Atlanta, GA Deerfield Parkway Suite 100 Alpharetta, GA Phone: 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.