Home / Blogs

Top Level Domains and a Signed Root

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.

By Jakob Schlyter, IT Security Advisor

Filed Under

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

VINTON CERF
Co-designer of the TCP/IP Protocols & the Architecture of the Internet

Comments

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

Related

Topics

IPv4 Markets

Sponsored byIPv4.Global

Threat Intelligence

Sponsored byWhoisXML API

Brand Protection

Sponsored byCSC

Domain Names

Sponsored byVerisign

Cybersecurity

Sponsored byVerisign