CZDS system updates for access extension requests
Hello, Please note that a release was just completed in the Centralized Zone Data Service (CZDS) system with some new functionality. Active CZDS users and Registry Operators should be receiving the notification from ICANN directly too, however I thought I’d share here as well for anyone interested. Zone file access requesters already authorized to access a top-level domain (TLD) zone file in the CZDS system will now have the option to submit an access extension request up to 30 days prior to the expiration date of their currently approved access. To request an access extension though the CZDS portal, go to the TLD zone access request details page. If the expiration date is within 30 days or less, the option to request an extension will be displayed next to the expiration date. Click the “Request Extension” button and confirm the action in order to submit the extension request to the registry operator. Please note that an extension request still requires approval by the TLD registry operator to extend the expiration date. If the extension request is not approved prior to the access expiration date, the access request will expire normally. If you have any questions, please contact globalsupport@icann.org. Best, Eduardo Alvarez Global Domains and Strategy, Technical Services Internet Corporation for Assigned Names and Numbers (ICANN)
On Tue, Jun 28, 2022 at 09:29:53PM +0000, Eduardo Alvarez via gtld-tech wrote:
Zone file access requesters already authorized to access a top-level domain (TLD) zone file in the CZDS system will now have the option to submit an access extension request up to 30 days prior to the expiration date of their currently approved access.
Is there an API mechanism to do the same? What are the URLs for requesting such an extension and what parameters do they take?
To request an access extension though the CZDS portal, go to the TLD zone access request details page. If the expiration date is within 30 days or less, the option to request an extension will be displayed next to the expiration date. Click the “Request Extension” button and confirm the action in order to submit the extension request to the registry operator.
Can the API URLs and required parameters be directly inferred from the Web UI?
Please note that an extension request still requires approval by the TLD registry operator to extend the expiration date. If the extension request is not approved prior to the access expiration date, the access request will expire normally.
I assume that in this case pending requests will still remain pending until the RO will get around to them.
If you have any questions, please contact globalsupport@icann.org.
I am optimistic that my questions are of general interest to other CZDS users, so have elected to reply on list. -- Viktor.
It appears that Viktor Dukhovni via gtld-tech <ietf-dane@dukhovni.org> said:
Is there an API mechanism to do the same? What are the URLs for requesting such an extension and what parameters do they take?
Can the API URLs and required parameters be directly inferred from the Web UI?
I am optimistic that my questions are of general interest to other CZDS users, so have elected to reply on list.
I was about to ask exactly the same thing. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
On Tue, Jun 28, 2022 at 06:05:45PM -0400, Viktor Dukhovni via gtld-tech wrote:
Is there an API mechanism to do the same? What are the URLs for requesting such an extension and what parameters do they take?
Can the API URLs and required parameters be directly inferred from the Web UI?
I was able to make partial progress, I can now retrieve the details for each approved request that will expire in less than 30 days, and see that the returned JSON data for each request id has among other fields: { ... , "extensible": true , "extensionInProcess": false , ... } It now remains to "POST" a suitable HTTP request to the URL associated with the request in question. How is the URL in question formed from the request id, and what parameters, headers and request body does it expect? -- Viktor.
On Thu, Jun 30, 2022 at 01:49:10AM -0400, Viktor Dukhovni via gtld-tech wrote:
On Tue, Jun 28, 2022 at 06:05:45PM -0400, Viktor Dukhovni via gtld-tech wrote:
Is there an API mechanism to do the same? What are the URLs for requesting such an extension and what parameters do they take?
Can the API URLs and required parameters be directly inferred from the Web UI?
I was able to make partial progress, I can now retrieve the details for each approved request that will expire in less than 30 days, and see that the returned JSON data for each request id has among other fields:
{ ... , "extensible": true , "extensionInProcess": false , ... }
It now remains to "POST" a suitable HTTP request to the URL associated with the request in question. How is the URL in question formed from the request id, and what parameters, headers and request body does it expect?
With a bit more sleuthing, the API entry point is: fetch("https://czds-api.icann.org/czds/requests/extension/<requestId>", { "headers": { "content-type": "application/json", "authorization": "Bearer <auth-token>", "accept": "application/json", }, "body": "{}", "method": "POST" }); To get the request ids however one iterates fetch("https://czds-api.icann.org/czds/requests/all", { "headers": { "content-type": "application/json", "authorization": "Bearer <auth-token>", "accept": "application/json", }, "body": approved(n), "method": "POST" }); where approved(n : Int) is the encoding of JSON object: { "status": "Approved" , "filter": "" , "pagination": { "size": 100, "page": n } , "sort": { "field": "Expired", "direction": "asc" } } this returns an object with: { "requests": [ r1, r2, ..., ] , "totalRequests": N } where "totalRequests" is perhaps the total across all pages (which I ignore), and "requests" is a list of request summaries, which if empty signals that the page number is too high. However, in practice I stop well short of that, because once the request expiration time is more than ~29 days in the future, there no point in fetching the rest. The request objects look like: { ... -- stuff we don't need , "requestId": String -- the magic <requestId> , "expired": String -- ISO8601 expiration date-time (Zulu timezone) , "tld": String -- A-label TLD name , ... -- stuff we don't need } Often the first 100 is all you'll ever need, though perhaps now and then more than 100 will be up for expiration in 30 days or less. Armed with the "requestId", it is possible to grab the request details: fetch("https://czds-api.icann.org/czds/requests/<requestId>", { "headers": { "authorization": "Bearer <auth-token>", "accept": "application/json", }, "method": "GET" }); Which are another JSON object containing many fields, but you only need: "requestId": String "extensible": Bool "extensionInProcess": Bool to decide whether to request an extension for a request and has "extensible" true and "extensionInProcess" false. Now that my next 30 days of zones have all been requested for extension, I'm changing the code to only examine the details for requests that are at least 21 days from expiring and at most 29. With the script running every day, things that expire sooner will have been requested previously and don't need to be rechecked. Best of luck with your implementations. -- Viktor.
On Tue, Jun 28, 2022 at 06:05:45PM -0400, Viktor Dukhovni via gtld-tech wrote:
Please note that an extension request still requires approval by the TLD registry operator to extend the expiration date. If the extension request is not approved prior to the access expiration date, the access request will expire normally.
I assume that in this case pending requests will still remain pending until the RO will get around to them.
This just happened for me today with "tirol", who took longer than ~6 days to approve the extension. The request now shows "Expired", but wouldn't it have made sense for it to automatically move to "Pending"? The original request could have been cloned as a new "Pending" request, or just re-entered the "Pending" state directly. Of course in my case tomorrow's daily batch job will automatically file a fresh request for "tirol", and they may now have two open requests to handle. I hope this won't cause any confusion when they come around to looking at these. -- Viktor.
It appears that Viktor Dukhovni via gtld-tech <ietf-dane@dukhovni.org> said:
This just happened for me today with "tirol", who took longer than ~6 days to approve the extension. The request now shows "Expired", but wouldn't it have made sense for it to automatically move to "Pending"?
Don't be silly. If we had any interest in making CZDS meet the needs of its users, it would be renewing everything automatically instead of fooling around with optional extensions. But instead ... For anyone else, I have used Viktor's excellent notes to update my python script so it can both make extend requests for everything eligible to be extended, and renewals for anything eligible to be renewed. If you want a copy, just ask. R's, John
On Mon, Jul 04, 2022 at 09:13:40PM -0400, Viktor Dukhovni via gtld-tech wrote:
Please note that an extension request still requires approval by the TLD registry operator to extend the expiration date. If the extension request is not approved prior to the access expiration date, the access request will expire normally.
I assume that in this case pending requests will still remain pending until the RO will get around to them.
This just happened for me today with "tirol", who took longer than ~6 days to approve the extension. The request now shows "Expired", but wouldn't it have made sense for it to automatically move to "Pending"? The original request could have been cloned as a new "Pending" request, or just re-entered the "Pending" state directly.
Of course in my case tomorrow's daily batch job will automatically file a fresh request for "tirol", and they may now have two open requests to handle. I hope this won't cause any confusion when they come around to looking at these.
Actually, the status is a bit more interesting, while "tirol" shows up as "Expired", it does not appear on the list of TLDs eligible for a renewal request, so perhaps it is in fact in some sort state that is equivalent to "Pending", while being nominally "Expired". I am curious to see what happens next... -- Viktor.
On Mon, Jul 04, 2022 at 10:24:13PM -0400, Viktor Dukhovni via gtld-tech wrote:
Actually, the status is a bit more interesting, while "tirol" shows up as "Expired", it does not appear on the list of TLDs eligible for a renewal request, so perhaps it is in fact in some sort state that is equivalent to "Pending", while being nominally "Expired". I am curious to see what happens next...
Never mind, this was a time-delay mistake, my "bot" filed a renewal request, which was not immediately visible in the dashboard... -- Viktor.
On 28/06/2022 22:29, Eduardo Alvarez via gtld-tech wrote:
Hello,
Please note that a release was just completed in the Centralized Zone Data Service (CZDS) system with some new functionality.
Active CZDS users and Registry Operators should be receiving the notification from ICANN directly too, however I thought I’d share here as well for anyone interested.
Zone file access requesters already authorized to access a top-level domain (TLD) zone file in the CZDS system will now have the option to submit an access extension request up to 30 days prior to the expiration date of their currently approved access.
To request an access extension though the CZDS portal, go to the TLD zone access request details page. If the expiration date is within 30 days or less, the option to request an extension will be displayed next to the expiration date. Click the “Request Extension” button and confirm the action in order to submit the extension request to the registry operator.
Please note that an extension request still requires approval by the TLD registry operator to extend the expiration date. If the extension request is not approved prior to the access expiration date, the access request will expire normally.
If you have any questions, please contact globalsupport@icann.org <mailto:globalsupport@icann.org>.
It is a nice feature, Eduardo, It has to be done manually for each request and that means using the dashboard. The dashboard resets when reloaded to the default ordering for the requests. That means that the list of requests has to be reordered every time unless the user is using a spreadsheet and can search for the request. Would it be possible to put the request option on the dashboard beside the request so that it would be easier to see the requests available for extension and request the extension from the dashboard rather than the request page? An "Expires in next 30 days" button might also help sort the list Regards...jmcc -- ********************************************************** John McCormac * e-mail: jmcc@hosterstats.com MC2 * web: http://www.hosterstats.com/ 22 Viewmount * Domain Registrations Statistics Waterford * Domnomics - the business of domain names Ireland * https://amzn.to/2OPtEIO IE * Skype: hosterstats.com ********************************************************** -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On Tue, Jun 28, 2022 at 09:29:53PM +0000, Eduardo Alvarez via gtld-tech wrote:
Zone file access requesters already authorized to access a top-level domain (TLD) zone file in the CZDS system will now have the option to submit an access extension request up to 30 days prior to the expiration date of their currently approved access.
Many thanks, this is working nicely. So far for me 30 TLDs zones were extended by the RO: allfinanz asda basketball bmw buzz cbre ceo cfa chanel cuisinella deloitte dvag emerck george global koeln kpmg kred mini northwesternmutual ovh pohl qpon rugby samsclub schmidt walmart wien woodside yahoo within a day of the extension request, which will ensure continuity of zone access for the above TLDs. With a bit of luck, now most TLDs will be extended before the corresponding request expires, with actual brief expirations a thing of the past. Of course the ROs who take months to review renewal requests may likewise neglect extension requests, time will tell. Presently, my "laggards" are: citadel 2019-01-28 voting 2022-06-09 scb 2022-06-21 With citadel, cancelling and filing a new request on 2022-06-02 has not yet been effective, but this did resolve a long overdue issue with xn--kput3i, so support cancellation is also a win, if not a silver bullet. -- Viktor.
participants (4)
-
Eduardo Alvarez -
John Levine -
John McCormac -
Viktor Dukhovni