Definition - DNSSEC |
Simple DNS Plus v. 5.2 Copyright © 1999-2011 JH Software ApS |
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 verification of data authenticity.
When 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 private/public key set 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.
There are no 3rd party certification authorities involved with DNSSEC - you create your own private/public key sets (see DNSSEC Key File 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 DNSKEY-records (see KSK below). This DS-record needs to be included and "counter signed" in the parent zone. For example if your domain name is "example.se", the DS-record needs to be added to the ".se" zone. The procedure for "uploading" the DS-record depends on your parent zone / TLD operator, and/or your domain name registrar.
The DNSSEC Sign Zone dialog includes an option to create the DS-record.
RFC4641 (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.
KSKs only sign the public key records (DNSKEY) for a zone, and usually have a long validity period (like 13 months).
KSKs are used as "Secure Entry Points" (SEP), and are referenced in parents zones through a DS-record (see above).
ZSKs sign all the record sets in a zone, and usually have a shorter validity period (like 1 month).
ZSKs are not Secure Entry Points, and are not referenced directly in parent zones.
This arrangement allows a zone operator to change his keys (ZSKs) more frequently without having to update the delegation signature in the parent zone.
Note that when the signatures for either of these keys are about to expire, new keys and signatures must be added, so that in overlapping periods a zone might be signed by 3 or 4 different keys at the same time.
Using KSK/ZSKs also makes it possible to re-sign a zone with the ZSK as needed without access to the KSK private key as long as no keys are changed, allowing the KSK private key to be stored in a more secure manner.
In Simple DNS Plus, DNSSEC keys are stored in a special key file with an option to password encrypt private keys - optionally only for KSKs.
For example, using a key file where only KSKs are password protected, an assistant could re-sign the zone as needed when records were changed etc, but it would require a manager who knows the KSK password to add/remove/update any DNSSEC keys.
Simple DNS Plus also supports a 3rd key type - "Simple".
This is basically a combined KSK and ZSK - a key used as a Secure Entry Point and also to sign all record sets in a zone.
This is just a simpler model which may be easier to use in some scenarios - but of course doesn't provide the benefits of KSK/ZSK separation.
Off-line signing / dynamic DNS data
To protect private keys and because DNSSEC signing is a very CPU intensive operation, DNSSEC was designed for signing to be done off-line.
In other words, DNS-records are pre-signed so that the private keys can be stored off-line and the DNS server doesn't have to calculate signatures for every request. Note that adding/deleting records in a zone not only requires calculating new signatures for new records, but also requires re-creating the NSEC/NSEC3 records and re-calculating their signatures.
This makes it impractical to use DNSSEC with any type of dynamic DNS data.
WARNING: Several options in Simple DNS Plus provide dynamic and/or synthesized DNS records, which will not automatically be DNSSEC signed. So make sure not to use those options in any way that would result in serving un-signed records under a domain that should be signed.
DNSSEC is not yet widely supported by operating systems or client applications, so practical use is limited at this time (April 2009).
However, this may change soon as several countries, including Brazil (.br), Bulgaria (.bg), Czech Republic (.cz), Puerto Rico (.pr) and Sweden (.se), have now DNSSEC signed their TLDs, and the U.S. government recently mandated that all federal agencies (.gov) must implement DNSSEC by the end of 2009.
DNSSEC has been under way for more than a decade, and has been the subject of many changes and much controversy over the years.
A significant obstacle for DNSSEC is that the Internet DNS root is not signed yet. This is stuck in international politics (has been for years), because this is ultimately about who gets to hold the "master key" to the entire Internet.
Until this happens, DNSSEC enabled resolver / client programs need to manually maintain a list of "trust anchors" for domains they want to verify, making it rather cumbersome.
DNSSEC support in Simple DNS Plus
Simple DNS Plus v. 5.2 supports hosting DNSSEC signed zones (responds with additional DNSSEC records when the DO-flag is set in requests) and has GUI functions for managing DNSSEC keys and for signing zones.
However it does not request or validate DNSSEC signatures while resolving other Internet domain names. We expect to be adding this in future versions when DNSSEC is more widely implemented and supported by client applications.
To DNSSEC sign a zone, in the DNS Records window, right-click a primary zone in the zone list and select "DNSSEC sign..." from the pop-up menu. This opens the DNSSEC Sign Zone dialog.
DNSSEC is defined in RFC3225, RFC4033, RFC4034, RFC4035, RFC4641, and RFC5155.