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.

DNSSEC Look-aside Validation (DLV) can be used to provide an additional DNSSEC entry point in the absence of a signed root zone and TLDs. ISC provides a DLV registry. For further details see our DLV page.

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.

Related Current Documentation

Older, possibly still useful references

Last modified: November 24, 2015 at 5:12 pm