[Ssr2-review] DNS SSR answers

[Jennifer Bryce]

Dear Boban, Laurin and Žarko,

Please see below for the answers to 5 questions in the DNS SSR workstream, re: TLD label management, root zone change management, and NS/DS record management. With these answers, there are no outstanding questions in each of these topics. The answers have been added to the Q&A Google doc: https://docs.google.com/document/d/14eJwDGP-LvS9ltTmZoh1i19Fi0_pB2nJ4JYMsS7lsco/edit#.

Please let us know if you have any questions.

Review Team volunteers: Boban, Laurin, Žarko
Workstream: DNS SSR
Topic: TLD Label Management
Outstanding questions: 0

Q: What technologies are used to ensure integrity and authentication?

A: We understand this question relates to a TLD operator managing their label in the root zone. If this is referring to something else, please advise.

We operate a custom workflow system for managing TLD labels in the root zone called the Root Zone Management System (RZMS).

Authentication of customer users to the RZMS is performed by username and password, using randomized usernames that are issued by IANA, and passwords that need to meet minimum complexity requirements. Access to privileged users (such as staff) is via an entirely different host, which in addition to username and password access requires through the company VPN and active privileges on the company-wide Active Directory service. Access to the VPN requires multi-factor authentication.

It is worth noting that customer use of RZMS in the current trust model is a convenience that does not provide additional privileges beyond that of an anonymous customer. It provides a convenient access to submit change request, review pending and historical change requests, and withdraw change requests in a self-service manner, but access is not required to perform these functions. The ability to submit and authorize a change request is possible via historical methods (such as email or fax) and does not require access privileges to RZMS.

The IANA team is currently building its next generation RZMS system which involves a substantial rewrite of the authorization model. The plans we have shared with our user community involve moving to a model where authentication is made a requirement for lodgment of routine change requests and to provide authorization by authorizing users. (The policy is such that third parties have standing to submit change requests, such as in the case of a transfer request, so that will still be available. In addition, we plan to retain the flexibility to receive out-of-band requests to stay nimble in response to emergency scenarios where connectivity may be limited.)

Q: What procedures are used to address SSR concerns when it comes to TLD label management?
A: In general, an extremely conservative approach is taken to managing the root zone in recognition of its critical role in the DNS ecosystem, which supports our objectives for security, stability and resiliency.

In terms of the general operational workflow, processing follows a well-understood process that involves significant review of each change by multiple parties. Automated testing of changes is performed by two independent entities (PTI as the Root Zone Manager, and Verisign as the Root Zone Maintainer). Key management for the root zone is similarly split (PTI as the Root KSK Operator, and Verisign as the Root ZSK Operator). All changes are manually reviewed throughout the process, and staff are empowered to ask questions and engage with the customer whenever a request raises a concern prior to implementation.

Evolutionary activities have been accompanied by highly conservative approaches. Implementation of our automation systems have been accompanied by extended periods of 'parallel testing', where existing and future operations are run in parallel for an extended period (e.g. 90 days) to ensure there are no regressions before the new system becomes primary. Growth of the root zone during the last gTLD round was limited to a rate of 20/week (i.e. 1,000/year) to ensure operations could be measured for deleterious effects. The initial signing of the root zone with DNSSEC, and the recent first KSK rollover, used techniques such as the Deliberately Unvalidatable Root Zone, and phased approaches that involved monitoring key transitions and fallback Key Signing Responses allowing quick restoration of prior state if needed.

Institutionally, there are multiple ICANN committees that provide recommendations and review of the operational environment. The Customer Standing Committee conducts performance related oversight. The Root Zone Evolution Review Committee reviews any architectural changes to the root zone. The relevant Supporting Organizations develop applicable policy that governs what may be delegated in the root zone, and the SSAC and RSSAC also have responsibility for facets of the system.

Review Team volunteers: Laurin, Boban, Žarko
Workstream: DNS SSR
Topic: Root Zone Change Management (Verification, etc.)
Outstanding questions: 0

Q: What technologies are used to verify requests?
A: There are two primary techniques used to verify requests: obtaining authorization/consent from the nominated representatives of the TLDs upon receipt of a request, and performing a set of technical checks for the technical attributes of a TLD's delegation.

As noted earlier, the submission of a change request is not limited to specific parties but is possible by anyone. Proceeding with a change request is not dependent on who submitted it, but an analysis that the change request comports with relevant policies and procedures, including consent from representatives of the TLD manager.

Changes to the technical delegation data that appears in the root zone (i.e. NS records, DS records, and associated glue records) requires that the change be reflected in the child zone prior to being proposed for the root zone. Part of the checking is to ensure NS changes reflect changes implemented in the apex of the TLD zone, that DS records have matching DNSKEYs in the apex of the TLD zone, and the authoritative zone for glue records reflects the addresses proposed as glue in the root zone. This testing is performed by two independent implementations (one by PTI, one by Verisign). In addition, for gTLD delegations, it is tested by a third independent implementation (as part of pre-delegation testing during the gTLD's evaluation prior to delegate, independent of the root zone change process.)

Q: How are actors verified when changes to the root zone are requested / undertaken? Are there procedures, and where can they be found?
A: In the current model, a nonce is sent via email to the two contacts for the domain and both must use to approve or reject the change request. Contacts can nominate a private email address that does not appear in the WHOIS for this purpose. See https://www.iana.org/help/obtaining-consent

Note the requirement described above that changes must have also been enacted in the child zone.

Help documentation that covers the basic workflow, technical requirements and other aspects is at https://www.iana.org/domains/root/help

Review Team volunteers: Boban, Laurin, Žarko
Workstream: DNS SSR
Topic: NS/DS Record Management
Outstanding questions: 0

Q: How are actors verified by IANA when any changes to the root zone are requested / undertaken? (For example, what happens if TLD op requests IP change of authoritative server?)

  *   Are there procedures, and where can they be found?
  *   What technologies are used to verify requests?
  *   What procedures are used to address SSR concerns when it comes to NS/DS record management inside the root zone?
  *   What technologies are used to ensure integrity and authentication when it comes to NS/DS record management inside the root zone?
  *   What are the provisions and procedures for emergency changes and emergency rollbacks in/to the root zone?

A: These seem to be the same questions just restated in a different way, except for one, “What are the provisions and procedures for emergency changes and emergency rollbacks in/to the root zone?”

Both PTI and Verisign maintain 24x7 capabilities to respond and process emergency changes to the root zone.

TLD managers are given an escalation call center number to signal an emergency. Generally, they are asked to submit their change request, if they are able, via the RZMS, and then call the call center to escalate the request.

Upon receipt of an emergency escalation, IANA staff will discuss the nature of the emergency with the customer to ensure it requires that level of response. Assuming that is so, Verisign will be activated to be ready to implement the root zone outside their normal schedule. IANA processes the change request on an expedited schedule according to normal procedures, and transmits the request to Verisign with an emergency flag set. Verisign will typically issue an expedited root zone earlier than their typical daily publication schedule.

There is no provision for "emergency rollbacks" of root zone changes. Any changes to the root zone to reverse the effect of a prior change would be by issuing a subsequent new root zone with the record changes unwound, but not rolling back to a previous version of the root zone. TLD managers who wished to reverse the effects of an implemented change would submit a new change request requesting changes with the new configuration they desire.

--
Jennifer Bryce
Senior Reviews Coordinator
Internet Corporation for Assigned Names and Numbers (ICANN)

Email: jennifer.bryce at icann.org
Skype: jennifer.bryce.icann
www.icann.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ssr2-review/attachments/20190327/8881e215/attachment.html>