posted on Monday, November 16, 2009 4:20 AM
DNS is insecure. Rogue DNS servers can impersonate real ones and compromise your infrastructure. DNSSEC addresses this particular flaw, but the complexity of the solution has been hampering adoption, leaving hundreds of thousands of DNS servers vulnerable.
While DNS has many known security flaws, most have been solved with configuration changes and best practices. However, recent, more serious exploits have drawn greater attention and have prompted the Office of Management and Budget (OMB) to mandate all federal agencies deploy DNSSEC by the end of 2009. DNSSEC deployment has so far been hindered by the complexity of available solutions, but with this mandate, its expected adoption rate will increase.
DNSSEC requires a public/private key signing infrastructure to support DNS. Every response to a query needs to be signed with the appropriate key as a means to authenticate the validity of the records returned. It is assumed that by signing records clients (also augmented with DNSSEC capabilities) will be able to trust the results of a query and not end up the victim of a DNS exploit.
But implementing what is essentially a PKI infrastructure alongside existing DNS infrastructure introduces complexity, additional management touch points, and new points of failure into the architecture. Implementation and subsequent management of keys, signing, recovery, logs, and zones becomes more time consuming, more costly, and operationally inefficient as the number of DNS servers requiring DNSSEC increases.
As the usage of cloud computing in myriad ways continues to accelerate, the possibility that applications will be served from various locations – local data centers, cloud data centers, global data centers – it becomes increasingly important that the veracity of DNS responses provided to ensure clients are able to access those applications across a variety of locations can be assured.
F5 BIG-IP GTM (Global Traffic Manager) v10.1 introduces support for DNSSEC. GTM supports two deployment models for DNSSEC implementations:
- When GTM is configured to act in its capacity as a DNS server it can be directed to use the DNSSEC feature when signing DNS responses. This implementation alleviates the need to deploy a separate DNSSEC-enabled signing solution along side existing DNS servers as is currently required by other solutions.
This solution is best for organizations who need to secure a small number of DNS servers with DNSSEC or who employ the use of a GSLB solution to provide global availability and support disaster recovery scenarios as the existing infrastructure (GTM) can be leveraged to provide both functions.
- When GTM with DNSSEC enabled is deployed in front of existing DNS servers, it can be configured to perform DNSSEC signing for the backend DNS servers. Essentially GTM becomes a DNSSECE-enabled proxy to all DNS servers in the infrastructure, eliminating the requirement to enable and subsequently manage DNSSEC capabilities on every DNS server in the backend infrastructure.
This solution is particularly suitable for service providers and other organizations who maintain or support large numbers of DNS server farms because there is no need to make changes to the existing infrastructure. GTM is deployed in front of the DNS server farms and implements DNSSEC on behalf of existing servers.
Both deployment models greatly simplify the implementation of DNSSEC-enabled infrastructure and reduce the number of solutions required to deploy to support DNSSEC initiatives.
Related Resources: