DNSSEC and BIND

DNSSEC extends standard DNS to prove the data is not modified and came from the official source. ISC BIND supports the full DNSSEC standard.

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.

At this time, DNSSEC can’t be tracked all the way back to the root zone because it is not signed*. Also only a few top-level domains (TLD) support DNSSEC by signing the entries in their zone: .bg, .br, .pr, and .se. Some gTLDs, like .org, are in the last stages of planning DNSSEC rollout for their domains. However, making sure that all the necessary registry and registrar capabilities are in place for DNSSEC will take some time. System administrators can hurry it a little bit by asking their parent domain operators to support DNSSEC.

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 Documentation