Welcome to the Transfer Policy PDP WG
Dear Working Group members, Welcome to the Working Group tasked with reviewing the Transfer Policy. I'm looking forward to working with all of you on this PDP. You should have received an invite for our first meeting, which is scheduled for this Friday, 14 May at 18:00 UTC, though not ideal for some, we did want to get moving and in our first meeting we will select a more agreeable reoccurring date/time for our regular meetings going forward. I want to share a few notes in advance of our first meeting to help ensure that we can get through all of the start-up tasks for the Working Group in a timely manner. In preparation for the first meeting, please take the time to begin familiarizing yourself with the following materials: * Working Group Charter<https://community.icann.org/display/TPRPDP/2.+WG+Charter> * Final Issue Report<https://gnso.icann.org/sites/default/files/file/field-file-attach/final-issu...> * Transfer Policy<https://www.icann.org/resources/pages/transfer-policy-2016-06-01-en> * Consensus Playbook<https://gnso.icann.org/sites/default/files/file/field-file-attach/pdp-3-4-co...> * GNSO Working Group Guidelines<https://gnso.icann.org/sites/default/files/file/field-file-attach/annex-1-gn...> & PDP Manual<https://gnso.icann.org/sites/default/files/file/field-file-attach/annex-2-pd...> * ICANN70 session providing an introduction to the PDP<https://icann.zoom.us/rec/play/dK9qk08zEpYxTFWJSz7qomUQhdr9z-lbkWRYQN7D1TAR4...> By the second Working Group meeting, I will expect that everyone has carefully read all of these documents. Once you have completed your document review, please confirm here<https://docs.google.com/forms/d/e/1FAIpQLSe3xz-e80x6moG8KSRDbCgYQOTN1Er6PYuM...>. The goal of this exercise is to ensure that everyone is starting off on the same page with the same foundation of information, which will enable us to be a more effective team. In addition, a document library is included on the Working Group's workspace (see https://community.icann.org/x/UIaUCQ). An understanding of these documents and their contents will help to ensure your full and productive participation in Working Group deliberations. The following items will be on the agenda for the first meeting: 1. Introductions: As standard practice during the first meeting of a PDP WG, members will do a round of verbal introductions so we can get to know each other. Please be prepared to speak briefly (no more than two minutes) about your relevant experience/background and any objectives you have for participating. 2. Vice Chair: We have an opportunity to select one or two Vice Chairs for this Working Group, but we are not required to do so. For now, I would suggest that we proceed without a Vice Chair and revisit the topic if necessary in the future. 3. Charter: It would be helpful if everyone could read through the Charter<https://community.icann.org/display/TPRPDP/2.+WG+Charter> before the first call. We will briefly go over some key points and answer any questions that members have. 4. Operating Mode/Working Methods: In our first meeting, we'll talk about some of the logistical elements of how we will work, including the decision-making process for this Working Group. We'll also review what is expected of those participating in this Working Group. From the outset, I would like to emphasize the importance of working towards developing consensus recommendations, which means working constructively and collaboratively to find outcomes that members can ultimately accept. To this end, the Consensus Playbook<https://gnso.icann.org/sites/default/files/file/field-file-attach/pdp-3-4-co...> is among the resources that you are being asked to read by the second meeting. We'll be drawing on the methods and techniques in the playbook throughout the life of the PDP, so everyone should be familiar with it. 5. Work Plan: On our first call, we will have an opportunity to speak a bit about the Work Plan and what can be expected in our first weeks of work on this PDP. As a preview, the initial areas of focus will be: * High-level review of the topics within the Charter for Phase 1 * Prepare to request input from SO/AC/SG/Cs on topics in Phase 1 * Deliver Phase 1 Work Plan to GNSO Council 1. Meeting Frequency and Schedule: We'll have an opportunity to discuss the meeting frequency and the proposed day/time of the calls. I look forward to seeing all of you on the call. Thanks Roger
On the call Friday, I commented that a change of registrar may also require a change in DNS service at the same time. I also asked if the distinction between inter-registrant and inter-registrant mentioned in the charter covered the case where both the registrant and registrar were changing at the same time. Attached is a note digging into these cases. In brief, I recommend consideration of both the one-at-a-time changes AND full understanding of how to make multiple changes. Thanks, Steve
Hi Steve, Regarding inter-registrar transfers, that is covered by the Temp Spec (specifically Appendix G, Section 1.2). I do not think it needs to be tied to the inter-registrant process due to the post-Temp Spec transfer process due to limited registrant data in the RDDS. While I think the other issues you raise are worthy of consideration, they are outside of the scope for Phase 1a: gaining/losing FOA, auth-code management, and Wave 1, Recommendation 27. Looking ahead, I do not see them in the other phases as well. While I appreciate a desire for a holistic review, this PDP is bound by its charter which is based upon concerns raised in the issues report (which did not mention those items). We need to be wary of scope creep to ensure that we can timely focus on and resolve the items identified in our charter. Regards, Owen
On May 16, 2021, at 20:53, Steve Crocker <steve@shinkuro.com> wrote:
On the call Friday, I commented that a change of registrar may also require a change in DNS service at the same time. I also asked if the distinction between inter-registrant and inter-registrant mentioned in the charter covered the case where both the registrant and registrar were changing at the same time.
Attached is a note digging into these cases. In brief, I recommend consideration of both the one-at-a-time changes AND full understanding of how to make multiple changes.
Thanks,
Steve
<Consideration of Multiple Changes and the Inclusion of DNS Operations v2.docx>_______________________________________________ GNSO-TPR mailing list GNSO-TPR@icann.org https://mm.icann.org/mailman/listinfo/gnso-tpr
Owen, Thanks. The touchstone for me is whether a registrant can successfully transfer his registration from one registrar to another. With respect to the registrant's DNS service, I believe this is most often provided free of charge by the registrar as part of the registrar's service. As a consequence, when the registrant moves their registration to another registrar, they will also have to move their DNS service. As things stand, I believe this often means there will be a disruption in resolution. And for a signed zone, this also means a disruption in validation. If I understand your point, you're saying because this was not raised in the issues report, it's not in scope for this PDP. Putting these points together, the goal for this PDP is to reach consensus on how a registrant can transfer their registration from one registrar to another with the understanding they will likely not be able to sustain uninterrupted service. Steve On Mon, May 17, 2021 at 8:49 PM Owen Smigelski via GNSO-TPR < gnso-tpr@icann.org> wrote:
Hi Steve,
Regarding inter-registrar transfers, that is covered by the Temp Spec (specifically Appendix G, Section 1.2). I do not think it needs to be tied to the inter-registrant process due to the post-Temp Spec transfer process due to limited registrant data in the RDDS.
While I think the other issues you raise are worthy of consideration, they are outside of the scope for Phase 1a: gaining/losing FOA, auth-code management, and Wave 1, Recommendation 27. Looking ahead, I do not see them in the other phases as well. While I appreciate a desire for a holistic review, this PDP is bound by its charter which is based upon concerns raised in the issues report (which did not mention those items). We need to be wary of scope creep to ensure that we can timely focus on and resolve the items identified in our charter.
Regards,
Owen
On May 16, 2021, at 20:53, Steve Crocker <steve@shinkuro.com> wrote:
On the call Friday, I commented that a change of registrar may also require a change in DNS service at the same time. I also asked if the distinction between inter-registrant and inter-registrant mentioned in the charter covered the case where both the registrant and registrar were changing at the same time.
Attached is a note digging into these cases. In brief, I recommend consideration of both the one-at-a-time changes AND full understanding of how to make multiple changes.
Thanks,
Steve
<Consideration of Multiple Changes and the Inclusion of DNS Operations v2.docx>_______________________________________________ GNSO-TPR mailing list GNSO-TPR@icann.org https://mm.icann.org/mailman/listinfo/gnso-tpr
_______________________________________________ GNSO-TPR mailing list GNSO-TPR@icann.org https://mm.icann.org/mailman/listinfo/gnso-tpr
Hi Steve, My suggestion is that when the registrant moves their registration to another registrars, as the gaining registrar, it should be able to allow the registrant to use the current DNS service during the inter-registrars transfer process or after the inter-registrars transfer is completed, then it can be solved and without a disruption in resolution. In my opinion, this is not a complicated function. Thanks. Best regards, Min Feng International Affairs Team 22Net, Inc Phone: +86-571-88276021 Fax: +86-571-88276022 Address: 11/F,Bldg No.2, Hangzhou Internet Innovation Pioneer Park, No.176 Zixia Street, Hangzhou, Zhejiang, China Post code:310030 From: Steve Crocker Date: 2021-05-18 09:01 To: Owen Smigelski CC: gnso-tpr@icann.org Subject: Re: [GNSO-TPR] Concurrent changes; transfer of DNS service Owen, Thanks. The touchstone for me is whether a registrant can successfully transfer his registration from one registrar to another. With respect to the registrant's DNS service, I believe this is most often provided free of charge by the registrar as part of the registrar's service. As a consequence, when the registrant moves their registration to another registrar, they will also have to move their DNS service. As things stand, I believe this often means there will be a disruption in resolution. And for a signed zone, this also means a disruption in validation. If I understand your point, you're saying because this was not raised in the issues report, it's not in scope for this PDP. Putting these points together, the goal for this PDP is to reach consensus on how a registrant can transfer their registration from one registrar to another with the understanding they will likely not be able to sustain uninterrupted service. Steve On Mon, May 17, 2021 at 8:49 PM Owen Smigelski via GNSO-TPR <gnso-tpr@icann.org> wrote: Hi Steve, Regarding inter-registrar transfers, that is covered by the Temp Spec (specifically Appendix G, Section 1.2). I do not think it needs to be tied to the inter-registrant process due to the post-Temp Spec transfer process due to limited registrant data in the RDDS. While I think the other issues you raise are worthy of consideration, they are outside of the scope for Phase 1a: gaining/losing FOA, auth-code management, and Wave 1, Recommendation 27. Looking ahead, I do not see them in the other phases as well. While I appreciate a desire for a holistic review, this PDP is bound by its charter which is based upon concerns raised in the issues report (which did not mention those items). We need to be wary of scope creep to ensure that we can timely focus on and resolve the items identified in our charter. Regards, Owen On May 16, 2021, at 20:53, Steve Crocker <steve@shinkuro.com> wrote: On the call Friday, I commented that a change of registrar may also require a change in DNS service at the same time. I also asked if the distinction between inter-registrant and inter-registrant mentioned in the charter covered the case where both the registrant and registrar were changing at the same time. Attached is a note digging into these cases. In brief, I recommend consideration of both the one-at-a-time changes AND full understanding of how to make multiple changes. Thanks, Steve <Consideration of Multiple Changes and the Inclusion of DNS Operations v2.docx>_______________________________________________ GNSO-TPR mailing list GNSO-TPR@icann.org https://mm.icann.org/mailman/listinfo/gnso-tpr _______________________________________________ GNSO-TPR mailing list GNSO-TPR@icann.org https://mm.icann.org/mailman/listinfo/gnso-tpr
Hi Steve- I tend to agree with Owen about focus and scope with the transfer stuff - keeping a keen focus on getting things done. You're raising good points and thinking of the registrant, which is something that is good for us all to be doing. Considering the things you are raising is helpful to factor in along the way so we don't complete our process with zero awareness of DNS information transfer, but the focus seems on the Registration vs the Resolution parallel paths of transfer, because that's been what is in focus with all the EPDP _stuff_ and the transfers happen most entirely within the SRS on the registration side. Auth-Info Codes, Status Code lifecycles, validations, etc. are all in the EPP/SRS world. DNSSEC _might_ creep into scope due to the way DNSSEC was put into the world. The registrant's registrar for a given domain is the only path to adding the records for a given name to the registry. Most folks get this set up at the gaining registrar or 3p service and then update the info on the losing registrar early or pre-transfer. With respect to transfers on the rest of the Resolution side of things.... Typically, in a transfer scenario, the DNS resolution _stuff_ is addressed by the registrant as a separate and sometimes parallel project path. Also typically, the gaining registrar gets set up first with the DNS zone, either record by record through painful user interfaces or in whole zone fashion, OR there is a third party DNS provider being used so the name move really is completely separate. If one looks at the process through a commercial lens, the gaining registrar is motivated more than the losing registrar to help or develop tools for this, which I can't fault the logic of. That said, most registrars in the RrSG go out of their way to help their customers/registrants where they can due to the relational nature of the business. -J Jothan Frakes On Mon, May 17, 2021 at 6:01 PM Steve Crocker <steve@shinkuro.com> wrote:
Owen,
Thanks. The touchstone for me is whether a registrant can successfully transfer his registration from one registrar to another. With respect to the registrant's DNS service, I believe this is most often provided free of charge by the registrar as part of the registrar's service. As a consequence, when the registrant moves their registration to another registrar, they will also have to move their DNS service. As things stand, I believe this often means there will be a disruption in resolution. And for a signed zone, this also means a disruption in validation.
If I understand your point, you're saying because this was not raised in the issues report, it's not in scope for this PDP. Putting these points together, the goal for this PDP is to reach consensus on how a registrant can transfer their registration from one registrar to another with the understanding they will likely not be able to sustain uninterrupted service.
Steve
On Mon, May 17, 2021 at 8:49 PM Owen Smigelski via GNSO-TPR < gnso-tpr@icann.org> wrote:
Hi Steve,
Regarding inter-registrar transfers, that is covered by the Temp Spec (specifically Appendix G, Section 1.2). I do not think it needs to be tied to the inter-registrant process due to the post-Temp Spec transfer process due to limited registrant data in the RDDS.
While I think the other issues you raise are worthy of consideration, they are outside of the scope for Phase 1a: gaining/losing FOA, auth-code management, and Wave 1, Recommendation 27. Looking ahead, I do not see them in the other phases as well. While I appreciate a desire for a holistic review, this PDP is bound by its charter which is based upon concerns raised in the issues report (which did not mention those items). We need to be wary of scope creep to ensure that we can timely focus on and resolve the items identified in our charter.
Regards,
Owen
On May 16, 2021, at 20:53, Steve Crocker <steve@shinkuro.com> wrote:
On the call Friday, I commented that a change of registrar may also require a change in DNS service at the same time. I also asked if the distinction between inter-registrant and inter-registrant mentioned in the charter covered the case where both the registrant and registrar were changing at the same time.
Attached is a note digging into these cases. In brief, I recommend consideration of both the one-at-a-time changes AND full understanding of how to make multiple changes.
Thanks,
Steve
<Consideration of Multiple Changes and the Inclusion of DNS Operations v2.docx>_______________________________________________ GNSO-TPR mailing list GNSO-TPR@icann.org https://mm.icann.org/mailman/listinfo/gnso-tpr
_______________________________________________ GNSO-TPR mailing list GNSO-TPR@icann.org https://mm.icann.org/mailman/listinfo/gnso-tpr
_______________________________________________ GNSO-TPR mailing list GNSO-TPR@icann.org https://mm.icann.org/mailman/listinfo/gnso-tpr
Steve, Successful transfers are indeed the benchmark and from my point of view transfers with DNSSEC Zones are already done today successfully. This will not be changed by any of the policy under debate in this PDP. Transferring DNS is like transferring email or web content part of our everyday headache running a registrar/webhost ;) but not necessarily related to the Inter Registrar Transfer and the matter of FOAs, Auth Codes. Best tom
Am 18.05.2021 um 03:01 schrieb Steve Crocker <steve@shinkuro.com>:
Owen,
Thanks. The touchstone for me is whether a registrant can successfully transfer his registration from one registrar to another. With respect to the registrant's DNS service, I believe this is most often provided free of charge by the registrar as part of the registrar's service. As a consequence, when the registrant moves their registration to another registrar, they will also have to move their DNS service. As things stand, I believe this often means there will be a disruption in resolution. And for a signed zone, this also means a disruption in validation.
If I understand your point, you're saying because this was not raised in the issues report, it's not in scope for this PDP. Putting these points together, the goal for this PDP is to reach consensus on how a registrant can transfer their registration from one registrar to another with the understanding they will likely not be able to sustain uninterrupted service.
Steve
On Mon, May 17, 2021 at 8:49 PM Owen Smigelski via GNSO-TPR <gnso-tpr@icann.org <mailto:gnso-tpr@icann.org>> wrote: Hi Steve,
Regarding inter-registrar transfers, that is covered by the Temp Spec (specifically Appendix G, Section 1.2). I do not think it needs to be tied to the inter-registrant process due to the post-Temp Spec transfer process due to limited registrant data in the RDDS.
While I think the other issues you raise are worthy of consideration, they are outside of the scope for Phase 1a: gaining/losing FOA, auth-code management, and Wave 1, Recommendation 27. Looking ahead, I do not see them in the other phases as well. While I appreciate a desire for a holistic review, this PDP is bound by its charter which is based upon concerns raised in the issues report (which did not mention those items). We need to be wary of scope creep to ensure that we can timely focus on and resolve the items identified in our charter.
Regards,
Owen
On May 16, 2021, at 20:53, Steve Crocker <steve@shinkuro.com <mailto:steve@shinkuro.com>> wrote:
On the call Friday, I commented that a change of registrar may also require a change in DNS service at the same time. I also asked if the distinction between inter-registrant and inter-registrant mentioned in the charter covered the case where both the registrant and registrar were changing at the same time.
Attached is a note digging into these cases. In brief, I recommend consideration of both the one-at-a-time changes AND full understanding of how to make multiple changes.
Thanks,
Steve
<Consideration of Multiple Changes and the Inclusion of DNS Operations v2.docx>_______________________________________________ GNSO-TPR mailing list GNSO-TPR@icann.org <mailto:GNSO-TPR@icann.org> https://mm.icann.org/mailman/listinfo/gnso-tpr <https://mm.icann.org/mailman/listinfo/gnso-tpr>
GNSO-TPR mailing list GNSO-TPR@icann.org <mailto:GNSO-TPR@icann.org> https://mm.icann.org/mailman/listinfo/gnso-tpr <https://mm.icann.org/mailman/listinfo/gnso-tpr>_______________________________________________ GNSO-TPR mailing list GNSO-TPR@icann.org https://mm.icann.org/mailman/listinfo/gnso-tpr
Thomas, I'd be very interested in how you transfer a DNSSEC signed zone without incurring any disruption of either resolution or validation. Perhaps best if we take this offline. Thanks, Steve On Tue, May 18, 2021 at 3:07 AM Thomas Keller <thomas.keller@ionos.com> wrote:
Steve,
Successful transfers are indeed the benchmark and from my point of view transfers with DNSSEC Zones are already done today successfully. This will not be changed by any of the policy under debate in this PDP. Transferring DNS is like transferring email or web content part of our everyday headache running a registrar/webhost ;) but not necessarily related to the Inter Registrar Transfer and the matter of FOAs, Auth Codes.
Best
tom
Am 18.05.2021 um 03:01 schrieb Steve Crocker <steve@shinkuro.com>:
Owen,
Thanks. The touchstone for me is whether a registrant can successfully transfer his registration from one registrar to another. With respect to the registrant's DNS service, I believe this is most often provided free of charge by the registrar as part of the registrar's service. As a consequence, when the registrant moves their registration to another registrar, they will also have to move their DNS service. As things stand, I believe this often means there will be a disruption in resolution. And for a signed zone, this also means a disruption in validation.
If I understand your point, you're saying because this was not raised in the issues report, it's not in scope for this PDP. Putting these points together, the goal for this PDP is to reach consensus on how a registrant can transfer their registration from one registrar to another with the understanding they will likely not be able to sustain uninterrupted service.
Steve
On Mon, May 17, 2021 at 8:49 PM Owen Smigelski via GNSO-TPR < gnso-tpr@icann.org> wrote:
Hi Steve,
Regarding inter-registrar transfers, that is covered by the Temp Spec (specifically Appendix G, Section 1.2). I do not think it needs to be tied to the inter-registrant process due to the post-Temp Spec transfer process due to limited registrant data in the RDDS.
While I think the other issues you raise are worthy of consideration, they are outside of the scope for Phase 1a: gaining/losing FOA, auth-code management, and Wave 1, Recommendation 27. Looking ahead, I do not see them in the other phases as well. While I appreciate a desire for a holistic review, this PDP is bound by its charter which is based upon concerns raised in the issues report (which did not mention those items). We need to be wary of scope creep to ensure that we can timely focus on and resolve the items identified in our charter.
Regards,
Owen
On May 16, 2021, at 20:53, Steve Crocker <steve@shinkuro.com> wrote:
On the call Friday, I commented that a change of registrar may also require a change in DNS service at the same time. I also asked if the distinction between inter-registrant and inter-registrant mentioned in the charter covered the case where both the registrant and registrar were changing at the same time.
Attached is a note digging into these cases. In brief, I recommend consideration of both the one-at-a-time changes AND full understanding of how to make multiple changes.
Thanks,
Steve
<Consideration of Multiple Changes and the Inclusion of DNS Operations v2.docx>_______________________________________________ GNSO-TPR mailing list GNSO-TPR@icann.org https://mm.icann.org/mailman/listinfo/gnso-tpr
_______________________________________________ GNSO-TPR mailing list GNSO-TPR@icann.org https://mm.icann.org/mailman/listinfo/gnso-tpr
_______________________________________________ GNSO-TPR mailing list GNSO-TPR@icann.org https://mm.icann.org/mailman/listinfo/gnso-tpr
On Tue, May 18, 2021 at 09:38:02AM -0400, Steve Crocker wrote:
I'd be very interested in how you transfer a DNSSEC signed zone without incurring any disruption of either resolution or validation. Perhaps best if we take this offline.
If we are out of scope, please let me (as an alternate) add some notes. Current minimal policy requirement is, that the gaining registrar is able to delete the DNSSEC information from the registry. So this procedure is possible: 1) Transfer the registry permissions to the gaining registrar. 2) Delete the DNSSEC (DS) data at the registry. 3) Wait (policy must exist, the the old NS must not be disconnected) 4) Set new name server glue at the registry. 5) Losing name server operator ends the service. This way the losing registrar is not required to do anyhing. If the gaining registrar is able to operate with DNSSEC, a different method can be used: 1) Transfer the registry permissions to the gaining registrar. 2) Add new DNSSEC (DS) data without delete the existing one at the registry. 3) Wait (policy must exist, the the old NS must not be disconnected) 4) Set new name server glue at the registry. 5) Losing name server operator ends the service. 6) Remove old DNSSEC (DS) data without delete the new one at the registry. This way the losing registrar is not required to do anyhing. If there is no policy to upheld the name server operations after the transfer, some early activities are necessary: 1) The losing registrar receives new DNSSEC (DS) data from the gaining name server operator via the registrant. 2) The losing registrar adds the new DNSSEC (DS) data in addition to the old one at the registry. 3) Wait 4) Transfer the registry permissions to the gaining registrar. 6) Gaining registrar sets new name server glue and removes old DS records at the registry. 7) Losing name server operator ends the service. Here we only need a policy, that the losing registrar is required to add an additional DNSSEC record when handing out an authinfo code. If we do not have any of those policies, the service will be disrupted during the transfer.
Hi Lutz and everyone, Thank you for checking about protocol for alternates on the mailing list. This is a good moment to remind everyone -- members may contribute on the mailing list at any time. Alternates may only contribute on the mailing list if they are acting as a designated substitute for a member. If they are not "standing in" for a member who is absent, they should refrain from commenting. Thanks in advance for being mindful of this. If there are any questions, please feel free to ask. Kind regards, Emily On 18/05/2021, 16:21, "GNSO-TPR on behalf of Lutz Donnerhacke" <gnso-tpr-bounces@icann.org on behalf of lutz@donnerhacke.de> wrote: On Tue, May 18, 2021 at 09:38:02AM -0400, Steve Crocker wrote: > I'd be very interested in how you transfer a DNSSEC signed zone without > incurring any disruption of either resolution or validation. Perhaps best > if we take this offline. If we are out of scope, please let me (as an alternate) add some notes. Current minimal policy requirement is, that the gaining registrar is able to delete the DNSSEC information from the registry. So this procedure is possible: 1) Transfer the registry permissions to the gaining registrar. 2) Delete the DNSSEC (DS) data at the registry. 3) Wait (policy must exist, the the old NS must not be disconnected) 4) Set new name server glue at the registry. 5) Losing name server operator ends the service. This way the losing registrar is not required to do anyhing. If the gaining registrar is able to operate with DNSSEC, a different method can be used: 1) Transfer the registry permissions to the gaining registrar. 2) Add new DNSSEC (DS) data without delete the existing one at the registry. 3) Wait (policy must exist, the the old NS must not be disconnected) 4) Set new name server glue at the registry. 5) Losing name server operator ends the service. 6) Remove old DNSSEC (DS) data without delete the new one at the registry. This way the losing registrar is not required to do anyhing. If there is no policy to upheld the name server operations after the transfer, some early activities are necessary: 1) The losing registrar receives new DNSSEC (DS) data from the gaining name server operator via the registrant. 2) The losing registrar adds the new DNSSEC (DS) data in addition to the old one at the registry. 3) Wait 4) Transfer the registry permissions to the gaining registrar. 6) Gaining registrar sets new name server glue and removes old DS records at the registry. 7) Losing name server operator ends the service. Here we only need a policy, that the losing registrar is required to add an additional DNSSEC record when handing out an authinfo code. If we do not have any of those policies, the service will be disrupted during the transfer. _______________________________________________ GNSO-TPR mailing list GNSO-TPR@icann.org https://mm.icann.org/mailman/listinfo/gnso-tpr
Lutz, Thanks for the detailed set of steps. With respect to the middle scenario, it's not sufficient to add the new DS record to the registry. The keys of both the old and new operators have to be included in the keysets on both sides. On Tue, May 18, 2021 at 10:21 AM Lutz Donnerhacke <lutz@donnerhacke.de> wrote:
On Tue, May 18, 2021 at 09:38:02AM -0400, Steve Crocker wrote:
I'd be very interested in how you transfer a DNSSEC signed zone without incurring any disruption of either resolution or validation. Perhaps best if we take this offline.
If we are out of scope, please let me (as an alternate) add some notes.
Current minimal policy requirement is, that the gaining registrar is able to delete the DNSSEC information from the registry. So this procedure is possible: 1) Transfer the registry permissions to the gaining registrar. 2) Delete the DNSSEC (DS) data at the registry. 3) Wait (policy must exist, the the old NS must not be disconnected) 4) Set new name server glue at the registry. 5) Losing name server operator ends the service. This way the losing registrar is not required to do anyhing.
If the gaining registrar is able to operate with DNSSEC, a different method can be used: 1) Transfer the registry permissions to the gaining registrar. 2) Add new DNSSEC (DS) data without delete the existing one at the registry. 3) Wait (policy must exist, the the old NS must not be disconnected) 4) Set new name server glue at the registry. 5) Losing name server operator ends the service. 6) Remove old DNSSEC (DS) data without delete the new one at the registry. This way the losing registrar is not required to do anyhing.
If there is no policy to upheld the name server operations after the transfer, some early activities are necessary: 1) The losing registrar receives new DNSSEC (DS) data from the gaining name server operator via the registrant. 2) The losing registrar adds the new DNSSEC (DS) data in addition to the old one at the registry. 3) Wait 4) Transfer the registry permissions to the gaining registrar. 6) Gaining registrar sets new name server glue and removes old DS records at the registry. 7) Losing name server operator ends the service. Here we only need a policy, that the losing registrar is required to add an additional DNSSEC record when handing out an authinfo code.
If we do not have any of those policies, the service will be disrupted during the transfer.
Dear Working Group members, It looks like Steve’s note has already generated some good discussion on the mailing list. Taking a step back, your staff support team has just shared a document outlining a proposed process for our initial review of topics within the charter. In this process, the Working Group will have an opportunity to go through all of the charter questions in Phase 1, and also consider whether any issues/questions have been missed. This issues Steve raises in his memo are a great example of an item that can be covered in step 3 of the process (see attached). Kind regards, Emily, Caitlin, and Berry From: GNSO-TPR <gnso-tpr-bounces@icann.org> on behalf of Steve Crocker <steve@shinkuro.com> Date: Monday, 17 May 2021 at 05:59 To: "gnso-tpr@icann.org" <gnso-tpr@icann.org> Subject: [GNSO-TPR] Concurrent changes; transfer of DNS service On the call Friday, I commented that a change of registrar may also require a change in DNS service at the same time. I also asked if the distinction between inter-registrant and inter-registrant mentioned in the charter covered the case where both the registrant and registrar were changing at the same time. Attached is a note digging into these cases. In brief, I recommend consideration of both the one-at-a-time changes AND full understanding of how to make multiple changes. Thanks, Steve
participants (8)
-
Emily Barabas -
Jothan Frakes -
Lutz Donnerhacke -
Owen Smigelski -
registrar＠22.cn -
Roger D Carney -
Steve Crocker -
Thomas Keller