With DNSSEC for the root zone going into production in a couple of weeks, it is now possible for Top Level Domain (TLD) managers to submit their Delegation Signer (DS) information to IANA. But what does this really mean for a TLD? In this post we’re going to try to sort that out.

What is Delegation Signer?

The Delegation Signer (DS) resource record contains a cryptographic hash (“fingerprint”) of the child zone’s Key Signing Key (KSK). When signing this record, a chain of trust is established between the parent and the child zone. By looking up and validating a signed DS record at the parent, a validating resolver can follow the chain of trust from the parent to the child, and continue any secure lookup from the child onward.

Validating Resolvers

As the root zone is signed using the RSA/SHA-256 algorithm, a resolver validating signed responses from the root zone must be able to understand this algorithm. The following most common resolvers are known to support this algorithm in later versions:

- ISC BIND (version 9.6.2 or later)
- Unbound (version 1.4.0 or later)
- Nominum Vantio

But what happens if a resolver that does not implement RSA/SHA-256 tries to validate the signed root? The DNSSEC specification states that keys and signatures by an unsupported algorithm shall be ignored. This implies that signatures made with such an algorithm will simply be ignored by the resolver, and the root zone will be considered unsigned.

Currently configured trust anchors for a TLD with DNSSEC will still function with a signed root, but once a trust anchor for the root is configured—and the TLD DS records are published—they become redundant and may be removed. One could even argue that they should be removed to prevent them from becoming stale when the TLD updates their current KSK.

Expected Deployment Rate

We expect that most of the TLDs that has deployed DNSSEC to submit their DS records to IANA within the near future. How fast the signed root is actually used by validating resolvers is still unknown, but based on feedback from large Internet Service Providers, we anticipate that the trust anchor for the root will be added gradually as updated versions of validating resolvers are being deployed.

Implications on Network Infrastructure

At the time of writing, all the root servers are serving the Deliberately Unvalidatable Root Zone (DURZ). This effectively means that all responses from the root servers already contains the keys and signatures required for DNSSEC validation, but as the keys are blinded the response cannot be validated. When the zone is unblinded (i.e., the real keys are visible) and the trusted anchor is published, the response packet sizes from the root servers does not change. Any harmful effect that would have been a result of the increase in packet size, would have been seen gradually from the point where the DURZ was incrementally rolled out, beginning January, and finally completed in May.

Conclusion

We recommend TLD managers with a signed zone to submit their DS records to IANA, and that they recommend their stakeholders (e.g., Internet Service Providers and Enterprises that validate the TLD responses) to start migration towards using the root trust anchor instead of the TLD trust anchor.

Resolver operators should start evaluating their environment by testing validation using the root trust anchor, reassuring that their resolvers and communication services works as expected with the signed root.