Page History

No changes should be made to the current naming scheme used in the root server system until more studies have been conducted.

Study reducing the priming response size.

When considering the priming response under DNSSEC, the scheme explained in Section 5.6 generated the smallest possible size, as expected. However, some implementations would become brittle if this naming scheme was adopted. Future work in this area could include modeling and proposing protocol changes to support this configuration, noting that the total cost shown by such a model might exceed the accompanying total benefit. RSSAC should study having a specific upper limit on the size of priming responses where the query has DO=1. Research to reduce the response size might consider:

• Choosing a naming scheme with a single root server name
• Testing the consequences of all large responses having the TC bit set
• Backward-compatible protocol enhancements using EDNS0 to support a priming specific single signature over the entire priming set (NS, A, AAAA, DNSKEYs). Further, more speculative studies about how to reduce the response size might include:
  • Using different cryptographic algorithms
  • Advertising what is expected in the Additional section (this would require modifying the DNS protocol)
  • Having a single key for the root zone instead of the current KSK + ZSK scheme
  • Effects of leaving the Additional section in priming responses empty

The fundamental recommendation of the RSSAC is to not change the current root server system naming scheme until the studies listed in section 7.2 can be completed. However, during the preparation of this document, the RSSAC Caucus Root Server Naming Work Party also made some observations that could be considered as recommendations based on particular outcomes in the further studies, and based on the risk analysis in Section 6.

If node re-delegation attacks pose a serious risk that needs to be mitigated, the following seem reasonable to consider:

• The root server addresses should be signed with DNSSEC to enable a resolver to authenticate resource records within the priming response. The root server addresses should be signed in a way that reduces the potential for operational breakage.
• Because the root server IP address information and the root zone are closely correlated, both sets of information should continue to be hosted on the same servers. This can be done using delegation or including the root server names in the root zone. All information necessary to validate the root-servers’ A/AAAA RRsets and the root zone should be hosted on the root servers.
• Among the various options considered in this document, moving the root server names to the root zone (5.3), or adding a new TLD under the root zone (5.4) are both viable options that would result in signing the root server addresses. Additional studies are needed to determine which of these options, if any, would be more favorable than the other in practice.