BIND fully supports DNSSEC and we encourage the use of DNSSEC as a best practice.
In addition to verifying the integrity of your zone data, the DNSSEC chain of trust can now also be used to associate other information with your domain, such as pgp keys, to help improve the security of applications.
What is DNSSEC?
DNSSEC (Domain Name System Security Extensions) adds resource records and message header bits which can be used to verify that the requested data matches what the zone administrator put in the zone and has not been altered in transit. DNSSEC doesn’t provide a secure tunnel; it doesn’t encrypt or hide DNS data. It was designed with backwards compatibility in mind. The original standard DNS protocol continues to work the same.
The new resource record types are: RRSIG (for digital signature), DNSKEY (the public key), DS (Delegation Signer), and NSEC (pointer to next secure record). The new message header bits are: AD (for authenticated data) and CD (checking disabled). A DNSSEC validating resolver uses these records and public key (asymmetric) cryptography to prove the integrity of the DNS data. A private key (specific to a zone) is used to encrypt a hash of a set of resource records — this is the digital signature stored in a RRSIG record.
The corresponding public key is stored in the DNSKEY resource record. The validating resolver uses that DNSKEY to decrypt the RRSIG and then compares the result with the hash of the corresponding resource record set to verify it is not changed. A hash of the public DNSKEY is stored in a DS record. This is stored in the parent zone. The validating resolver retrieves from the parent the DS record and its corresponding signature (RRSIG) and public key (DNSKEY); a hash of that public key is available from its parent. This becomes a chain of trust — also called an authentication chain. The validating resolver is configured with a trust anchor — this is the starting point which refers to a signed zone. The trust anchor is a DNSKEY or DS record and should be securely retrieved from a trusted source (not using DNS).
Also all the names in the zone have corresponding NSEC records listed in order creating a chain of all the signed record sets. (Corresponding RRSIG records are also created to verify the NSEC data.) Because there is no gap, NSEC records are used to provide proof of non-existence of an resource record or to authenticate negative replies.
Preparing for DNSSEC
Use resolvers that are DNSSEC capable and configured to do the validation. All versions of BIND 9 are DNSSEC capable. Make sure network devices don’t lose or stop EDNS0 (Extension Mechanisms for DNS) or squash DNSSEC-related traffic. DNSSEC requires EDNS0 to support the larger DNS message sizes and for the DNSSEC OK (DO) EDNS header bit.
DNSSEC will increase DNS traffic with more requests and larger responses. For high volume DNS traffic, prepare for increased bandwidth needs. DNSSEC is more sensitive to time issues (system clocks being really off) than vanilla DNS; make sure your system clocks are reasonably accurate.
If hosting DNSSEC signed zones, make sure your secondaries also support and have DNSSEC enabled.
(2016 report from the Internet Society)
Related Current Documentation
DNSSEC Quick Reference Card (prints on a single sheet of paper, double-sided)
DNSSEC Key Manager utility (added in BIND 9.11.0)
DELV, a new BIND tool that checks the DNSSEC validation chain
Older, possibly still useful references
- “Deploying DNSSEC with BIND 9.7” given by Alan Clegg at NANOG50
- How to Configure Auto-Signed Dynamic Zones with BIND9 by Eugene Crosser
- DNSSEC — Living and Loving Life after Kaminsky; Or: How I overcame my fear and signed my zones. A recorded presentation by ISC’s Alan Clegg (requires Flash)
- DNSSEC goes Mainstream: Deployment Incentives, Experience, Questions, a presentation by Suzanne Woolf at NANOG Jun2009.