Why DNSSEC?
DNS resolution assumes that information received from remote DNS servers is always valid. As a result of the Kaminsky exploit from mid-2008, organizations are now realizing that this is not always true. DNS is susceptible to cache poisoning attacks that can be used to misdirect users to malicious sites. To help provide added security, the DNS Security Extensions (DNSSEC) were created to provide a method for validating DNS information. Organizations need to begin implementing DNSSEC to safeguard against DNS threats.
DNSSEC - How It Works
DNSSEC is designed to protect DNS resolvers (clients) from forged DNS data, which occurs as the result of a DNS attack, such as cache poisoning. DNSSEC secures DNS by signing all records hosted on the authoritative server, using a digital signature. When a DNS resolver requests a DNS record, it also downloads the DNSSEC key to verify that the record it received is identical to the record on the authoritative server.
For example, BlueCat Networks has implemented DNSSEC and signed all hosts for the bluecatnetworks.com domain using the private key of an asymmetric key pair. When a client makes a request for www.bluecatnetworks.com, they will receive the signed DNS record. Using BlueCat Networks’ public key, they will be able to verify that the www.bluecatnetworks.com was signed by BlueCat and is therefore valid.
Should someone exploit an organization’s DNS server that is using DNSSEC, any record that they alter will not have been signed using the company’s private key. When a client receives the altered record and attempts to verify the record integrity, an error will be received indicating that the record is invalid and has been tampered with. This prevents users from receiving poisoned DNS and increased the reliability of records they receive from DNSSEC-enabled DNS servers.
Why BlueCat?
BlueCat Networks has been providing secure DNS solutions since 2001, and as a trusted advisor in DNS security, organizations have looked to BlueCat to help address their security concerns. As part of BlueCat Networks’ dedication to security, the DNS Security Extensions have been added to BlueCat’s award winning Proteus and Adonis appliances. Through the addition of DNSSEC, BlueCat provides organizations with the ability to easily deploy and maintain DNSSEC records and keys.
Note:
DNSSEC does not provide condentiality of data. It provides a means to authenticate DNS responses, but does not encrypt the information.
DNSSEC Resolution
DNSSEC Validation and Trust Anchors
BlueCat provides the ability to configure Trust Anchors, which are used to validate responses from other authoritative name servers. Trust Anchors are configurable at the server level as a DNS option. You can configure as many Trust Anchors as necessary. After a Trust Anchor has been added to the validating Adonis DNS server, it can properly validate signed records from DNSSEC signed zones.
DNSSEC Hosting
DNSSEC Resource Records
BlueCat supports all the required resource records needed to provide DNSSEC functionality for authoritative zones including Resource Record Signatures (RRSIGs), DNSKEY records, and Next Secure (NSEC) and (NSEC3) records.
Signing the Zone with DNSSEC Signing Policies
You can configure the settings related to DNS keys in a DNSSEC Signing Policy. In a Signing Policy, you configure the settings for Zone Signing Keys (ZSK) and Key Signing Keys (KSK). ZKSs are used to sign the records within a zone – such as the www host in the zone bluecatnetworks.com. KSKs are used to sign the DNSKEY resource records (public keys) and are stored on resolving DNS servers as the trust anchor for the zone. After you have created the Signing Policy, you simply apply it to forward or reverse zones.
Scheduled Key Rollover
BlueCat automates the method in which old keys are replaced by new keys (known as key rollover). The new keys are generated based on settings you configure in the DNSSEC Signing Policy. When the new key is set to be added to the zone, the Proteus service responsible for key management creates the new key pair and adds the key to the zone. Both sets of keys (old and new) will be used until the old set of keys expires. This provides a mechanism for rolling over keys to ensure that DNSSEC keys never unduly expire.
|
