- gtld-tech - lists.icann.org

ICANN DNS Forum 2018
by Rubens Kuhl Dec. 21, 2017

Dec. 21, 2017

Hi Folks. Is there any sign that ICANN DNS Forum will happen in 2018 alongside DNS-OARC and ICANN 61, or ICANN GDD Summit ? Thanks, Rubens

4 4

Fwd: New Version Notification for draft-brown-whoami-00.txt
by Gavin Brown Dec. 20, 2017

Dec. 20, 2017

(apologies to those who receive multiple copies due to cross-posting) Dear colleagues, As you will probably be aware, the EU's General Data Protection Regulation (GDPR) comes into force in May next year. This has forced domain registries and registrars to reassess their approach to data collection, retention, and disclosure - particuarly in regard to Whois/RDAP. Having thought about this topic for a little while, it occurred to me that there might be some benefit in a "straw man" proposal for how centralised databases of registration data might be avoided. So I wrote this Internet-Draft which describes a simple decentralised alternative to Whois/RDAP directories. Obviously it is far from a perfect solution, but I have yet to think of any criticism of it that does not equally to Whois/RDAP as they currently exist. So I have published my draft for feedback. Flame on! G. -------- Forwarded Message -------- Subject: New Version Notification for draft-brown-whoami-00.txt Date: Wed, 20 Dec 2017 06:02:07 -0800 From: internet-drafts(a)ietf.org To: Gavin Brown <gavin.brown(a)centralnic.com> A new version of I-D, draft-brown-whoami-00.txt has been successfully submitted by Gavin Brown and posted to the IETF repository. Name: draft-brown-whoami Revision: 00 Title: A Method For Identifying a Domain Operator's Point of Contact (WHOAMI) Document date: 2017-12-19 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-brown-whoami-00.txt Status: https://datatracker.ietf.org/doc/draft-brown-whoami/ Htmlized: https://tools.ietf.org/html/draft-brown-whoami-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-brown-whoami-00 Abstract: This document proposes a decentralised alternative to traditional WHOIS directories. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Gavin Brown Chief Technology Officer CentralNic Group plc (LSE:CNIC) Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.

1 0

Call for Participation -- ICANN DNSSEC Workshop at ICANN61 San Juan, Puerto Rico
by Jacques Latour Dec. 12, 2017

Dec. 12, 2017

Hi All! The next ICANN DNSSEC Workshop will be on Wednesday, March 14, in San Juan, Puerto Rico. If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to dnssec-sanjuan(a)isoc.org<mailto:dnssec-sanjuan@isoc.org> by **03 January 2017** Thanks, Jack Call for Participation -- ICANN DNSSEC Workshop at ICANN61 San Juan, Puerto Rico The DNSSEC Deployment Initiative and the Internet Society Deploy360 Programme, in cooperation with the ICANN Security and Stability Advisory Committee (SSAC), are planning a DNSSEC Workshop during the ICANN61meeting held from 10-15 March 2018 in San Juan, Puerto Rico. The DNSSEC Workshop has been a part of ICANN meetings for several years and has provided a forum for both experienced and new people to meet, present and discuss current and future DNSSEC deployments. For reference, the most recent session was held at the ICANN Annual General Meeting in Abu Dhabi, UAE, https://schedule.icann.org/event/CbKE/dnssec-workshop-part-ii[schedule.ican…<https://urldefense.proofpoint.com/v2/url?u=https-3A__schedule.icann.org_eve…>, and https://schedule.icann.org/event/CbKF/dnssec-workshop-part-iii[schedule.ica…<https://urldefense.proofpoint.com/v2/url?u=https-3A__schedule.icann.org_eve…>. At ICANN61 we are particularly interested in live demonstrations of uses of DNSSEC or DANE. Examples might include: * Innovative uses of APIs to do something new and different using DNSSEC/DANE. * Email clients and servers using DNSSEC, OPENPGPKEY, or S/MIME for secure email. * DNSSEC automation and deployment using CDS, CDNSKey, and CSYNC. * DNSSEC signing solutions and innovation. * Tools for automating the generation of DNSSEC/DANE records. * Services for monitoring or managing DNSSEC signing or validation. * Tools or services for using DNSSEC/DANE along with other existing protocols and services such as SSH, XMPP, SMTP, S/MIME or PGP/GPG. Our interest is to provide current examples of the state of development and to show real-world examples of how DNSSEC and DANE related innovation can be used to increase the overall security of the Internet. We are open to presentations and demonstrations related to any topic associated with DNSSEC and DANE. Examples of the types of topics we are seeking include: 1. DNSSEC Activities For this panel we are seeking participation from those who have been involved in DNSSEC deployment and also from those who have not deployed DNSSEC but who have a keen interest in the challenges and benefits of deployment. In particular, we will consider the following questions: Are you interested in reporting on DNSSEC validation of your ISPs? What can DNSSEC do for you? What doesn't it do? What are the internal tradeoffs to implementing DNSSEC? What did you learn in your deployment of DNSSEC? We are interested in presentations from both people involved with the signing of domains and people involved with the deployment of DNSSEC-validating DNS resolvers. 2. Impact of Root Key Rollover We would like to bring together a panel of people who can talk about the impacts to ISPs, equipment providers and end users, and also what could be done to mitigate those issues. In particular, we are seeking participation from vendors, ISPs, and the community that could be affected by distribution of new root keys. If you have a specific concern about the Root Key Rollover we would like to hear from you. 3. Implementing next generation DNSSEC signing at Registries and DNS Operators Now that DNSSEC technology has matured many Registries, and DNS Operators have upgraded their legacy DNSSEC signing services with innovative solutions. * Real world use cases of HSMs and key management. * Signing at the edge. We would be interested in seeing presentations or demonstrations on those topics. 4. The operational realities of running DNSSEC Now that DNSSEC has become an operational norm for many registries, registrars, and ISPs, what have we learned about how we manage DNSSEC? What is the best practice around key rollovers? How often do you review your disaster recovery procedures? Is there operational familiarity within your customer support teams? What operational statistics have we gathered about DNSSEC? Are there experiences being documented in the form of best practices, or something similar, for transfer of signed zones? 5. Innovation around DANE and DNSSEC application automation For DNSSEC to reach massive deployment levels it is clear that a higher level of automation is required than is currently available. There also is strong interest for DANE usage within web transactions as well as for securing email and Voice-over-IP (VoIP). We are seeking presentations on topics such as: * How can the industry use DANE and other DNSSEC applications as a mechanism for creating a more secure Internet? * What tools, systems and services are available to help automate DNSSEC key management? * Can you provide an analysis of current tools/services and identify gaps? * What are some of the new and innovative uses of DANE and other DNSSEC applications in new areas or industries? * What tools and services are now available that can support DANE usage? We would be particularly interested in any live demonstrations of DNSSEC / DANE application automation and services. Demonstrations of new tools that make the setup of DNSSEC or DANE more automated would also be welcome. 6. DNSSEC and DANE in the enterprise and in the enterprise tool set Enterprises and enterprise software can play a critical role in both providing DNSSEC validation to their internal networks and also through signing of the domains owned by the enterprise. We are seeking presentations from enterprises and enterprise software providers that have implemented DNSSEC on validation and/or signing processes and can address questions such as: * What enterprise software support or plan do you have to support DNSSEC? * What are the benefits to enterprises of rolling out DNSSEC validation? And how do they do so? * What are the challenges to deployment for these organizations and how could DANE and other DNSSEC applications address those challenges? * How should an enterprise best prepare its IT staff and network to implement DNSSEC? * What enterprise tools and systems are available to assist enterprises in the deployment of DNSSEC? * How can the DANE protocol be used within an enterprise to bring a higher level of security to transactions using SSL/TLS certificates? 7. Implementing DNSSEC validation at Internet Service Providers (ISPs) Internet Service Providers (ISPs) play a critical role by enabling DNSSEC validation for the caching DNS resolvers used by their customers. We have now seen massive rollouts of DNSSEC validation within large North American ISPs and at ISPs around the world. We are interested in presentations on topics such as: * Can you describe your experiences with negative Trust Anchors and operational realities? * What does an ISP need to do to prepare its network for implementing DNSSEC validation? * How does an ISP need to prepare its support staff and technical staff for the rollout of DNSSEC validation? * Can you provide results and/or impacts of the impact of root key rollover? * What rollover technique do you use, i.e., RFC 5011 or other? In addition, we welcome suggestions for additional topics. If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to dnssec-sanjuan(a)isoc.org<mailto:dnssec-sanjuan@isoc.org> by **03 January 2017** We hope that you can join us. Thank you, Kathy Schnitt On behalf of the DNSSEC Workshop Program Committee: Jean Robert Hountomey, AfricaCERT Jacques Latour, .CA Xiaodong Lee, CNNIC Russ Mundy, Parsons Ondřej Filip, CZ.NIC Yoshiro Yoneya, JPRS Dan York, Internet Society Mark Elkins, DNS/ZACR

1 0

Re: [gtld-tech] Request ROID for .BAIDU
by Victor Figueroa Nov. 11, 2017

Nov. 11, 2017

Hi, You may verify the requirements at https://www.iana.org/assignments/epp-repository-ids/epp-repository-ids.xhtml and send the request to iana(a)iana.org. Regards, -Victor From: <gtld-tech-bounces(a)icann.org> on behalf of "honghong(a)zdns.cn" <honghong(a)zdns.cn> Date: Thursday, November 9, 2017 at 9:39 PM To: "gtld-tech(a)icann.org" <gtld-tech(a)icann.org> Cc: 'gaolei' <gaolei(a)zdns.cn> Subject: [gtld-tech] Request ROID for .BAIDU Hi I’m from Chinese ZDNS, which is the backend for .TOP and .WANG and other TLDs, recently .BAIDU will be delegated to our system, so we want to request a EPP Repository Identifier for .BAIDU: Change Controller ID: baidu Change Controller Name:baidu Change Controller Email:fengshuo@zdns.cn Reference/Contact ID:fengshuo Reference/Contact Name:fengshuo Reference/Contact Email:fengshuo@zdns.cn Do the information above is enough and right for the request? Regards Hong, Hong

1 0

RDAP questions
by Taras Heichenko Nov. 10, 2017

Nov. 10, 2017

Hi all! According to https://community.icann.org/display/RP/RDAP+Pilot this mailing list is used for RDAP pilot program. I work at .UA registry and we plan to implement RDAP. But during RFCs reading I got some questions. I wrote one question to another mailing list and had received some answers with possible solutions. But variants are questionable (I will show them after question) and may be anyone has better solutions. 1. Contact data of our registrants can be in ASCII encoding (international-int) and/or in UTF-8 encoding (local-loc). For local data the UTF-8 encoding is used but language of data is not defined. It is impossible to define language because EPP does not provide language definition mechanism. So when we show ENTITY we can not define strings language for local data according to vCard RFC. The question is: How should we present data in conformity with RFC? To this question I received two answers: 1a. Do not define language at all. Just include multiply values without language definition. As for me this answer does not conflict with RFC but it is very inconvenient for user recognition and/or data processing (we do not think that JSON is the best format for data presentation for end user, isn't it?) 1b. The second advice is better (as for me). Int and loc data we can separate by ALTID property parameter. This allows at least differentiate data of different languages and encoding. Of course we just shift data representation to those who will process and present received JSON data. But all local data uses UTF-8 encoding and this should not cause any problem on web. But may be anyone has better solution for this question? 2. The second question is also concerns of entity data presentation. According to legislation of our country private person may demand to hide private data. In this case registrator in EPP request defines fields that must not be shown. Besides all it can be registrant's name. According to vCard RFC FN field is mandatory but according to our legislation sometimes I must not show this field. What should I do in this case? Do not show this entity at all? Or may be I should write "privacy protected" in FN field? Any ideas? -- Best regards Taras Heychenko tasic(a)hostmaster.ua

2 1

Request ROID for .BAIDU
by honghong＠zdns.cn Nov. 10, 2017

Nov. 10, 2017

Hi I'm from Chinese ZDNS, which is the backend for .TOP and .WANG and other TLDs, recently .BAIDU will be delegated to our system, so we want to request a EPP Repository Identifier for .BAIDU: Change Controller ID: baidu Change Controller Name:baidu Change Controller Email:fengshuo@zdns.cn Reference/Contact ID:fengshuo Reference/Contact Name:fengshuo Reference/Contact Email:fengshuo@zdns.cn Do the information above is enough and right for the request? Regards Hong, Hong

1 0

Proposed Registrar Data Escrow Agent reporting specification
by Eduardo Alvarez Oct. 23, 2017

Oct. 23, 2017

Dear colleagues, As part of the ongoing RFP for an ICANN designated Agent for Data Escrow Services (https://www.icann.org/news/announcement-2-2017-08-17-en) and in an effort to improve the Registrar Data Escrow process, ICANN plans to update the existing RRI system to add support for approved Registrar Data Escrow Agents, and optionally for Registrars, to submit Data Escrow notifications to ICANN. This update aims to facilitate tracking of any outstanding Data Escrow reporting, and Registrars will have the option to monitor their Data Escrow status. Attached you will find the proposed specification draft-icann-registrar-interfaces. I have also attached the proposed updates required in the draft-lozano-icann-registry-interfaces and daft-arias-noguchi-dnrd-objects-mapping specifications to support the new registrar Data Escrow functionality. The new and updated specifications are planned to be published as IETF internet-drafts. It is important to clarify that the Registry Data Escrow process remains unaffected by the proposed updates to the draft-lozano-icann-registry-interfaces and daft-arias-noguchi-dnrd-objects-mapping specifications. Please note that although the draft-icann-registrar-interfaces specification includes functionality to support data escrow notifications to be submitted by Registrars, this specification does not impose any obligation for Registrars to provide these notifications to ICANN. Your feedback on this topic is welcome. If you wish to provide any comments, please send them to the gtld-tech(a)icann.org mailing list by 27 November 2017. An informative session is also planned to take place on 01 November 2017 at 13:00 UTC during the upcoming ICANN60 meeting in Abu Dhabi to address this topic. Regards, Eduardo Alvarez GDD Technical Services Sr. Manager ICANN

1 0

New gtlds.json ICANN report available
by Eduardo Alvarez Oct. 23, 2017

Oct. 23, 2017

Dear Colleagues, ICANN has published a new report in JSON format that you may find useful, which lists all gTLDs and some of their characteristics, at: https://www.icann.org/resources/registries/gtlds/v2/gtlds.json Attached you may find the report's specification after incorporating the feedback provided in the gtld-tech mailing list earlier. As indicated before, the gtlds.json report lists all gTLDs that have signed a Registry agreement with ICANN, including gTLDs removed from the root, and is expected to be updated at least every 6 hours. The existing new gTLDs CSV report, has also been relocated to the following URL: https://www.icann.org/resources/registries/gtlds/v1/newgtlds.csv Please note that the old report location (https://newgtlds.icann.org/newgtlds.csv) is still available, but it is planned to be replaced with a HTTP 301 response in the following weeks in order to redirect requests to the new report location. If you are using the newgtlds.csv report please use the new report location. Feel free to contact me should you have any questions. Best regards, Eduardo Alvarez Technical Services Sr. Manager Global Domains Division, ICANN

4 5

Re: [gtld-tech] New gtlds.json ICANN report available
by Eduardo Alvarez Oct. 20, 2017

Oct. 20, 2017

Hi Maxim, There are no plans to incorporate ccTLDs in the gtlds.json report. Regards, Eduardo Alvarez Technical Services Sr. Manager Global Domains Division, ICANN From: Maxim Alzoba [mailto:m.alzoba@gmail.com] Sent: Thursday, October 19, 2017 5:06 AM To: Eduardo Alvarez <eduardo.alvarez(a)icann.org> Cc: gtld-tech(a)icann.org Subject: [Ext] Re: [gtld-tech] New gtlds.json ICANN report available Hello Eduardo, Do you know if any changes to be expected to the location or format of <https://urldefense.proofpoint.com/v2/url?u=http-3A__data.iana.org_TLD_tlds-…>http://data.iana.org/TLD/tlds-alpha-by-domain.txt[data.iana.org] ?(it contains ccTLDs too, so it is more useful as a source of all TLDs,including gTLDs and ccTLDs)P.s: Are there any plans to add "ccTLD" elements, so the source could be seenas a complete list ?Sincerely Yours,Maxim AlzobaSpecial projects manager,International Relations Department,FAITIDm. +7 916 6761580(+whatsapp)skype oldfroggerCurrent UTC offset: +3.00 (.Moscow)On Oct 18, 2017, at 23:58, Eduardo Alvarez <eduardo.alvarez(a)icann.org<mailto:eduardo.alvarez@icann.org> > wrote:Dear Colleagues,ICANN has published a new report in JSON format that you may find useful,which lists all gTLDs and some of their characteristics, at: <ht tps://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources_…>https://www.icann.org/resources/registries/gtlds/v2/gtlds.json[icann.org]At… you may find the report's specification after incorporating thefeedback provided in the gtld-tech mailing list earlier. As indicated before,the gtlds.json report lists all gTLDs that have signed a Registry agreementwith ICANN, including gTLDs removed from the root, and is expected to beupdated at least every 6 hours.The existing new gTLDs CSV report, has also been relocated to the followingURL: <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resource… _uGLPpKqjY4Kypr3UX8dkt-rEwM2hwajQceqS5_bkA&s=7La9k1dNPXBrK_4tqv33M3eVYrPjEBrIjss2juEAOO8&e=>https://www.icann.org/resources/registries/gtlds/v1/newgtlds.csv[icann.org]… note that the old report location (<https://urldefense.proofpoint.com/v2/url?u=https-3A__newgtlds.icann.org_new…>https://newgtlds.icann.org/newgtlds.csv[newgtlds.icann.org]) is stillavailable, but it is planned to be replaced with a HTTP 301 response in thefollowing weeks in order to redirect requests to the new report location. Ifyou are using the newgtlds.csv report please use the new report location.Feel free to contact me should you have any questions.Best regards,Eduardo AlvarezTechnical Services Sr. ManagerGlobal Domains Division, ICANN

2 1

ICANN Monthly Reports and the new Registry Agreement
by Benoit Levac Sept. 8, 2017

Sept. 8, 2017

Hey everyone, Specification 3 of the new registry agreement that just went into effect renames one of the fields in the Per-Registrar Transaction Report, and removes two fields from the Registry Functions Activity Report. https://newgtlds.icann.org/sites/default/files/agreements/agreement-approve… Can anyone from ICANN comment on whether registries are expected to change the format of our monthly reports starting this month? Will the ry-api remain backwards compatible for some period of time? I don't recall seeing anything published on this topic, but sorry if I missed it. Thank you, Ben

3 4