Similar to digital signatures for e-mail, DNSSEC authenticates that DNS records originate from an authorized sender (DNS server) using private/public-key cryptography.
The main purpose of this is to protect DNS against falsified information (DNS spoofing).
DNSSEC does NOT encrypt or hide anything - all data is still in "clear text". Its only purpose is the verification of data authenticity.
- DNSSEC signingWhen a zone is DNSSEC signed, a number of DNS records are added to the zone (indeed DNSSEC signing a zone can make it many times larger).First, a DNSKEY-record is added for each key used to sign the zone. DNSKEY-records hold the public keys that clients can use the verify signatures.Next, an NSEC-record or NSEC3-record is added for each unique record name in the zone (+ a single NSEC3PARAM-record if using NSEC3). Each NSEC/NSEC3 record lists all the record types that exist for the name that it represents, and points to the next record name in the zone forming a chain between all existing names in the zone. These (signed) NSEC/NSEC3 records are returned in responses to DNSSEC enabled queries (DO flag set) for non-existing names/types, so that clients can verify the non-existence.Finally, all the DNS records in the zone (including the DNSKEY and NSEC/NSEC3 records) are signed by adding an RRSIG-record for every unique record name and type combination in the zone. RRSIG-records for the records they sign are returned in responses to DNSSEC enabled queries.
- Delegation/link of trustThere are no 3rd party certification authorities involved with DNSSEC - you create your own keys (or private/public key sets) - see DNSSEC Keys dialog.In order to establish a "link of trust" so that other Internet users can verify your keys and signatures, you create a DS-record (delegation signature) containing a cryptographic hash of one of your KSK (see key types below) DNSKEY-records (see "DS Records" button in the DNSSEC Keys dialog).This DS-record needs to be included (and signed) in the parent zone. For example, if your domain name is "example.org", the DS-record needs to be added to the ".org" zone. The procedure for "uploading" the DS-record depends on your parent zone / TLD operator, and/or your domain name registrar.Note that some registrars will automatically generate the DS-record(s) for you based on the DNSKEY-records in your zone.
TLD level domains (".org" etc.) are "linked" to the root zone the same way. And this way all DNSSEC signed zones are linked up to the root.
DNSSEC enabled resolvers are configured with a copy of the public key part of the key signing the root - and are therefore able to verify any correctly signed/delegated DNS zone on the Internet.
- Key types - KSK / ZSK / SimpleRFC4641 (DNSSEC Operational Practices) defines two key types; "Key Signing Key" (KSK) and "Zone Signing Key" (ZSK). Typically a zone is signed with both a KSK and a ZSK (or two of either type during rollovers - see below).A KSK only signs the public key records (DNSKEY) for a zone. KSKs are used as "Secure Entry Points" (SEP) and are referenced in parents zones through a DS-record (see above).A ZSK signs all the other records in a zone. ZSKs are not Secure Entry Points, and are not referenced directly in parent zones (but indirectly because the DNSKEY-record representing the ZSK is signed by the KSK).
A KSK is often a stronger key (algorithm / key size) than a ZSK.
This KSK/ZSK arrangement allows a zone operator to change his ZSKs (see Rollover below) without having to update the delegation signature in the parent zone. And it makes it possible to re-sign a zone as needed using only the ZSK. The KSK is only needed when changing keys (because this only signs the DNSKEY records - which only change when the keys change), allowing the KSK to be stored in a more secure manner.
- Key rollover A "rollover" is the process of replacing a DNSSEC key - adding a new key and removing the old - along with the related DNS records. It is recommended (in RFCs and by various security experts) that DNSSEC keys are replaced periodically. Generally, KSKs should be replaced every few years and ZSKs every few months.During a rollover, DNSSEC records for both the old and the new key should be present in the zone for a short period allowing old keys to time out in caches, etc.This means that in the overlapping periods, a zone might be signed by up to 4 different keys (2 KSKs + 2 ZSKs) at the same time.
- Signature validity period/expiration When you sign a zone, you specify how long the signatures are valid. This stores a fixed expiration date/time as part of each signature record (RRSIG).A zone must always be re-signed before the previous signatures expire.This validity period should be kept as short as possible so that any bad data will time out as quickly as possible - but:
- If you are using automatic signing (see below), the validity period should be long enough to allow for an outage on the primary DNS server (which does the signing) to be recovered before the signatures expire. Secondary servers do NOT automatically re-sign the zone while the primary is out.
- If you are not using automatic signing, then the validity period also depends on how often you are willing to manually re-sign the zone.