Starting today, ICANN-accredited registrars may submit Delegation Signer (DS) records to Verisign, the .com administrator. Most organizations obtain and register their domain names with domain registrars, who may also be their ISP. Contact your registrar to determine if they are participating in this process. Verisign will include submitted DS records in a"deliberately unvalidatable" .com zone that will be published on Monday, February 28. This deliberately unvalidatable zone will contain dummy keys for testing purposes.
As recently announced , the .com zone will be signed in production on March 31, 2011. The submitted DS records will be included in the signed .com zone and the .com DS record will be published in the root zone, fully linking the chain of trust for .com zones!
This linked chain of trust vastly simplifies the management of trusted keys on validating resolvers (typically within recursive or caching DNS servers which are queried by clients or "stub resolvers"). Prior to this linkage, a validating resolver requires a copy of each .com's trusted subzone's public key (key signing key, KSK). So if a DNS administrator desired to implement DNSSEC validation to protect the cache of his/her DNS servers, a trusted key for each subzone needed to be configured on each caching server. If you think about all the .com subzones your users browse or email to, that's a lot of trusted keys! Fortunately, with a fully linked chain of trust, only the root zone's public key (KSK) need be configured for successful validation of .com subzones.
The KSK of a signed zone basically signs the zone's key records, consisting of the KSK and the zone signing key(s) (ZSKs). The ZSK signs the zone, meaning that it is used to produce a signature for each resource record set within the zone. The DS record is analogous to the NS record. The NS record provides referrals to the next subzone in the domain tree for name resolution. The DS record provides a "trust referral" to a signed subzone by incorporating a hash of the subzone's KSK. If a validating resolver does not "trust" the subzone's KSK, it can check if the parent zone links trust to this KSK via a corresponding DS record; if so the validating resolver can determine if it trusts the parent zone's KSK, and so on up the domain tree to the root!