Our last post explained the basics of how DNSSEC works. A security-aware resolver's ability to validate nameserver responses is accomplished by establishing an authentication chain from a known trust anchor(s) (i.e., a DNSKEY or signed DS record) to the zone which has provided the signed response. If a resolver is configured with a trust anchor(s) that exists higher in the DNS tree, e.g., the root's public key, it can theoretically verify any signed responses. This is because a path can always be constructed from the root to lower zones, assuming every zone in the path is signed and carries a Delegation Signer (DS) Resource Record for child zones. This architectural design highlights the critical importance of parent nameservers maintaining DS records and of signing those records to widespread deployment of DNSSEC across the Internet.
However, what happens in a scenario if portions of the DNS tree, and particularly the root, is not signed? A broken authentication hierarchy, where a parent zone does not support DNSSEC, creates the “islands of trust” problem. For instance, the .se zone (which launched commercial service recently) is signed yet it's parent is not. It is isolated from the rest of the DNS tree, an island. Therefore, the .se registry must provide a trust anchor to security aware resolvers and be responsible for the associated key management tasks (e.g., distribution, rollover to new key, etc.). Another example might be USG agencies, where implementation of DNSSEC is being driven by the need to be compliant with Federal Information Security Management Act driven standards. It is possible to deploy DNSSEC in zones the USG is responsible for (e.g., .gov, .mil) without securing the root. Another option for dealing with the absence of signed DS records in the root is DNSSEC Look-aside Validation (DLV). Originally put forth as an interim solution until the root was signed, DLV bypasses the normal DNS hierarchy and proposes one or more third parties maintain a registry of validated entry points to secure zones, thereby relieving the need to sign the root. In theory, the introduction of multiple DLV registries could be beneficial from a market competition standpoint.
Since DNSSEC allows for resolvers to store and use multiple trust anchors, incremental deployment using either of the scenarios above is possible. But while these alternatives remove the difficult political hurdles associated with signing the root zone file, it also changes who absorbs the deployment and ongoing costs of DNSSEC. Trust anchor management (and security policy decisions) would move away from ICANN and the root zone maintainer (currently VeriSign). E.g., the current DLV specification suggests that IANA assume this role. However, any new organization would still have to deal with the same operational questions and expense, namely key management and liability surrounding holding such a critical position in an authentication hierarchy. Perhaps more importantly, such an approach potentially eliminates efficiencies gained by maintaining a single or relatively few trust anchors for the secure DNS. Having numerous trust anchors would increase the burden of security policy evaluation and key updating for resolver operators (i.e., to ISPs running caching resolvers, and perhaps ultimately, to security-aware stub resolvers used by end-user applications). Arguably, it presents a situation that is simply not scalable across the entire Internet.
So what are we left with? The DNSSEC specification is based on a hierarchical model of trust, and ideally that means the root is signed, with an organization(s) overseeing the critical DS records and providing trust anchor(s) for security aware resolvers to use to validate them. Our next post will outline a new system for the management of a DNSSEC-enabled root. One that distributes authority more than the current method while avoiding the risks and pitfalls of an intergovernmental power sharing scheme.
 To be precise, the key mentioned above is actually the “key signing key” (KSK) for the root zone. In fact, in most cases each zone will manage two types of key-pairs, KSKs and zone signing keys (ZSKs). The ZSK key-pair is used to sign a particular zone's record sets and will be used frequently by resolvers in queries, while the KSK key-pair is used less frequently because it is used only to sign and authenticate a zone's ZSK.
 This is not exhaustive list of alternatives dealing with an unsigned root. Other non-hierarchical solutions have been suggested. E.g., one proposes out of band “web-of-trust” trust anchor distribution, another suggests islands cross-sign KSKs. Furthermore, it does not include trust anchor update alternatives the Working Group has considered, e.g. trustupdate-threshold, trustupdate-timers, and TAKREM.
 One implementation is currently run by ISC, makers of the market dominant BIND name serving software.