<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Title" content="">
<meta name="Keywords" content="">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.msoIns
{mso-style-type:export-only;
mso-style-name:"";
text-decoration:underline;
color:teal;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:595.0pt 842.0pt;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:444344846;
mso-list-template-ids:399422834;}
@list l1
{mso-list-id:782841659;
mso-list-template-ids:405968482;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2
{mso-list-id:1812359159;
mso-list-template-ids:1925607196;}
@list l2:level2 lfo1
{mso-level-start-at:0;
mso-level-number-format:alpha-lower;
mso-level-numbering:continue;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:0in;
text-indent:0in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style>
</head>
<body bgcolor="white" lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Dear Boban, Laurin and Žarko,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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: <a href="https://docs.google.com/document/d/14eJwDGP-LvS9ltTmZoh1i19Fi0_pB2nJ4JYMsS7lsco/edit#">
https://docs.google.com/document/d/14eJwDGP-LvS9ltTmZoh1i19Fi0_pB2nJ4JYMsS7lsco/edit#</a>.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Please let us know if you have any questions.<o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;background:yellow;mso-highlight:yellow"><o:p> </o:p></span></b></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;background:yellow;mso-highlight:yellow">Review Team volunteers: Boban,
</span></b><span style="font-size:11.0pt;background:yellow;mso-highlight:yellow">Laurin, Žarko</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Workstream: DNS SSR</span></b><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Topic: TLD Label Management<o:p></o:p></span></b></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Outstanding questions: 0 <o:p>
</o:p></span></b></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt"><o:p> </o:p></span></b></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Q: What technologies are used to ensure integrity and authentication?<o:p></o:p></span></p>
<p style="margin:0in;margin-bottom:.0001pt;vertical-align:baseline">A: <span style="color:black">
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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black">We operate a custom workflow system for managing TLD labels in the root zone called the Root Zone Management System (RZMS).</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black">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.</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black">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.</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black">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.)</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Q: What procedures are used to address SSR concerns when it comes to TLD label management?
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Review Team volunteers: <span style="background:yellow;mso-highlight:yellow">Laurin,</span></span></b><span style="font-size:11.0pt;background:yellow;mso-highlight:yellow"> Boban, Žarko</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Workstream: DNS SSR</span></b><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Topic: Root Zone Change Management (Verification, etc.)<o:p></o:p></span></b></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Outstanding questions: 0 <o:p>
</o:p></span></b></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Q: What technologies are used to verify requests?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Q: How are actors verified when changes to the root zone are requested / undertaken? Are there procedures, and where can they be found?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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 <a href="https://www.iana.org/help/obtaining-consent">
https://www.iana.org/help/obtaining-consent</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Note the requirement described above that changes must have also been enacted in the child zone.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Help documentation that covers the basic workflow, technical requirements and other aspects is at <a href="https://www.iana.org/domains/root/help">https://www.iana.org/domains/root/help</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Review Team volunteers: <span style="background:yellow;mso-highlight:yellow">Boban,
</span></span></b><span style="font-size:11.0pt;background:yellow;mso-highlight:yellow">Laurin, Žarko</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Workstream: DNS SSR</span></b><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Topic: NS/DS Record Management<o:p></o:p></span></b></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Outstanding questions: 0<o:p></o:p></span></b></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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?) <o:p></o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal" style="margin-left:0in;mso-list:l1 level1 lfo3"><span style="font-size:11.0pt">Are there procedures, and where can they be found?<o:p></o:p></span></li><li class="MsoNormal" style="margin-left:0in;mso-list:l1 level1 lfo3"><span style="font-size:11.0pt">What technologies are used to verify requests?<o:p></o:p></span></li><li class="MsoNormal" style="margin-left:0in;mso-list:l1 level1 lfo3"><span style="font-size:11.0pt">What procedures are used to address SSR concerns when it comes to NS/DS record management inside the root zone?<o:p></o:p></span></li><li class="MsoNormal" style="margin-left:0in;mso-list:l1 level1 lfo3"><span style="font-size:11.0pt">What technologies are used to ensure integrity and authentication when it comes to NS/DS record management inside the root zone?<o:p></o:p></span></li><li class="MsoNormal" style="margin-left:0in;mso-list:l1 level1 lfo3"><span style="font-size:11.0pt">What are the provisions and procedures for emergency changes and emergency rollbacks in/to the root zone?<o:p></o:p></span></li></ul>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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?”<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Both PTI and Verisign maintain 24x7 capabilities to respond and process emergency changes to the root zone.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black">-- <o:p></o:p></span></p>
<div>
<p class="MsoNormal"><b><span style="font-size:11.0pt;color:#595959">Jennifer Bryce</span></b><span style="font-size:11.0pt;color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#595959">Senior Reviews Coordinator </span><span style="font-size:11.0pt;color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#595959">Internet Corporation for Assigned Names and Numbers (ICANN)</span><span style="font-size:11.0pt;color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#595959">Email: jennifer.bryce@icann.org</span><span style="font-size:11.0pt;color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#595959">Skype: jennifer.bryce.icann</span><span style="font-size:11.0pt;color:black"><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#595959">www.icann.org</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
</div>
</body>
</html>