Technical Analysis of the Naming Scheme Used For Individual Root Servers (R5)
| Date Issued | Document | Reference ID | Current Phase |
|---|---|---|---|
| Technical Analysis of the Naming Scheme Used For Individual Root Servers (R5) | RSSAC028 | CLOSED |
Description:
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.
STATUS UPDATES
| Date | Phase | Type | Status Updates |
|---|---|---|---|
| Closed | Phase Change | This Advice Item is now Closed |
| Phase 2 | AP Feedback | ICANN received confirmation of the updated understanding. |
| Phase 2 | Board Understanding | Upon further review of our original Understanding, the org would like to revise it. Because this recommendation is listed as speculative, the org believes there is no action for the ICANN Board to take and this item should be closed. |
| Phase 2 | Phase Update | Updated Understanding sent to RSSAC for review. |
| Phase 2 | Phase Change | Now in Phase 2: Understand |
| Phase 2 | Phase Update | Advice Item returned to Phase 2: Understand to request further clarification of recommendation. |
| Phase 3 | Phase Change | Now in Phase 3: Evaluate and Consider |
| Phase 2 | AP Feedback | Received confirmation of understanding. RSSAC states: The RSSAC / RSSAC Caucus will scope the study. After that collaboration may be needed between the RSSAC / RSSAC Caucus and ICANN org to perform the studies. |
| Phase 2 | Phase Update | Understanding sent to RSSAC for review. |
| Phase 2 | Board Understanding | The ICANN org understands that the RSSAC has also provided an additional, speculative recommendation, which states that if node re-delegation attacks pose a serious risk that needs to be mitigated, the following should also be considered:
Additional studies are needed to determine which of these options, if any, would be more favorable than the other in practice. The ICANN org requests clarification from the RSSAC as to whether the RSSAC is recommending the RSSAC/root server community or the ICANN org to perform the studies. |
| Phase 2 | Phase Change | Now in Phase 2: Understand |
| Phase 1 | Phase Update | ICANN acknowledged receipt of Advice. |
| Phase 1 | Phase Update | RSSAC published RSSAC028: Technical Analysis of the Naming Scheme Used For Individual Root Servers Link: https://www.icann.org/en/system/files/files/rssac-028-03aug17-en.pdf. |
