September 2016 - gtld-tech - lists.icann.org

FW: Proposal to remove RDAP from the Thick Whois CL&D Policy (was Proposed Path Forward | Thick Whois CL&D Policy, RDAP and RySG Request for Reconsideration)
by Francisco Arias Sept. 21, 2016

Sept. 21, 2016

FYI, On 9/21/16, 10:41 AM, "gnso-impl-thickwhois-rt-bounces(a)icann.org<mailto:gnso-impl-thickwhois-rt-bounces@icann.org> on behalf of Dennis Chang" <gnso-impl-thickwhois-rt-bounces(a)icann.org<mailto:gnso-impl-thickwhois-rt-bounces@icann.org> on behalf of dennis.chang(a)icann.org<mailto:dennis.chang@icann.org>> wrote: Dear IRT members, As you know, on 7 February 2014, the ICANN Board adopted GNSO consensus policy recommendations regarding the provision of “Thick” Whois by all gTLD registries. In consultation with the consensus policy Implementation Review Team (IRT), the implementation team identified two expected outcomes in the policy development process (PDP) recommendations: * The consistent labeling and display of WHOIS output for all gTLDs * The transition from Thin to Thick WHOIS for .COM, .NET and .JOBS The first outcome was published as a consensus policy, the Registry Registration Data Directory Services Consistent Labeling and Display Policy<https://www.icann.org/resources/pages/rdds-labeling-policy-2016-07-26-en> (CL&D Policy), on 26 July 2016. In August 2016, the Registry Stakeholder Group (RySG) submitted a Request for Reconsideration<https://www.icann.org/resources/pages/reconsideration-16-10-rysg-request-20…> (RfR) regarding the CL&D Policy. The RfR objects to the inclusion of RDAP as part of the Consensus Policy as RDAP was not contemplated or referenced in the policy recommendations. To resolve this matter, ICANN proposes the following path forward for the IRT: 1. ICANN to issue a revised CL&D Policy to all registry operators, removing provision 12. For your reference, provision 12 states: “The implementation of an RDAP service in accordance with the "RDAP Operational Profile for gTLD Registries and Registrars<https://www.icann.org/rdap-gtld-profile>" is required for all gTLD registries in order to achieve consistent labeling and display.” Additionally, I have attached the proposed revised CL&D Policy. 2. Issue a revised notification to registry operators regarding implementation of the CL&D Policy, clearly indicating what has changed in the revised CL&D Policy. 3. Set the revised CL&D Policy effective date to allow for full 6-month implementation from the date of the revised notice. 4. Update the published CL&D Policy on the ICANN website, noting a change has been made. Note: The revised CL&D Policy would not be subject to another Public Comment process. 5. Rescind the notification sent to registrars to implement RDAP. ICANN intends to issue notices for registries and registrars to implement RDAP after further dialogue with the community. Please let us know if you have comments or concerns by responding to this list (gnso-impl-thickwhois-rt(a)icann.org) Unless we hear otherwise, we intend to move forward with the plan outlined above on 4 October 2016. — Kind Regards, Dennis S. Chang GDD Services & Engagement Program Director +1 213 293 7889 Skype: dennisSchang www.icann.org "One World, One Internet"

1 0

Delegated nameservers RFC compliance
by Mark Andrews Sept. 1, 2016

Sept. 1, 2016

As part of preparations for shipping nameservers that support DNS COOKIES (RFC 7873) I have been measuring EDNS Compliance in a number data sets the results of which are available at https://ednscomp.isc.org along with a online tester. We wanted how much will break when we ship BIND 9.11.0 which has DNS COOKIES on by default. We found there were zones that could no longer resolve if validation was enabled. Named falls back to plain DNS on certain detected errors as there isn't time to probe exact failure causes by trial and error. Even if trial and error worked for DNS COOKIEs the problem will get worse as more EDNS features get used. We found zones that were taking multiple seconds to resolve. We were back to the sort of resolution times we saw when EDNS was first introduced for some zones. We saw increased queries being needed to be made as servers didn't correctly ignore unknown EDNS options. All these errors are easily determinable by running a handful of queries against each server. RFC 1034 and RFC 1035 were written assuming that servers delegated to would be RFC compliant. Currently GTLD servers are checked and there is no reason that servers delegated to by the GTLD servers can't also be checked and the operators asked to fix the faults detected. This can be done at both the RFC 1034 and RFC 1035 level and at the EDNS level. It is not a actionable condition if all the EDNS tests fail in a way that indicated the EDNS is not supported. I would suggest that {E}DNS compliance checking be done within a week of a new server being registered and delegated to and 1/2 yearly thereafter. If a server fails a test that the operator / registrant be informed and the server be retested in a month. I would also suggest that compliance testing results and test date should be record in whois or similar so there is no need to retest too frequently. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka(a)isc.org

3 5

RDAP referral to registrar ?
by Pascal Bouchareine Sept. 1, 2016

Sept. 1, 2016

Hello, Francisco already replied to me here - the question was: // Is there going to be a guarantee that one will be able to perform a domain RDAP lookup up to the registrar RDAP service ? Section 2.3 of the RDAP operational profile does not seem to enforce a link to the registrar RDAP server for other cases than thin registries. // >From an automation and information publishing perspective, we think always having a link to registrar from the registries might be very convenient. Is there a way to publish this whenever it's available ? (the use case we're working on was https://github.com/Gandi/dnsknife/bl ob/master/docs/extending_registrar_functions.txt) Or is this a small enough constraint that can be relaxed later and doesn't need inclusion in the operational guidelines right now ? Or maybe I'm just misunderstanding the implementation goals- if so sorry about that. Thank you!

7 9