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

Delegated nameservers RFC compliance
by Mark Andrews Aug. 31, 2016

Aug. 31, 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

Call for Participation ICANN 55 Marrakesh
by Dr Eberhard W Lisse Aug. 29, 2016

Aug. 29, 2016

Call for Participation TechDay at ICANN 55 in Marrakesh, Morocco The ICANN Tech Working Group is again planning a technical workshop at the ICANN 55 meeting on 07 March 2016 in Marrakesh, Morocco. The TechDay 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 technical topics related to registry and DNS work and security. For reference, the most recent session was held at the ICANN meeting in Dublin, Ireland on 19 October 2015. The presentations and transcripts are available at: https://meetings.icann.org/en/dublin54/schedule/mon-tech. We are specially interested in: 1. Registration information accuracy panel For this panel, we are interested in presentations relating to registry contact data cleanup, address validation, malicious registration data verification, batch and/or real-time validation. We would like, in particular, to see solutions leveraging Open Source, Open Data or Open Research in order to make them available to a wider audience. 2. Next Generation DNS Infrastructure Panel: For this panel we are seeking presentations from next generation DNS infrastructure platform implementers. We are looking presentation on DNS Anycast platform that are small footprint, low cost, highly performant and scalable. We are particularly interested in presentations on DNS infrastructure that use an innovative approach to deliver new breakthroughs in either footprint, cost, performance or scalability. We are interested in understanding how provisioning is performed, detailed hardware and software routing architecture, logging, monitoring, packet capture, multi-tenancy, performance metrics. 3. In addition, we welcome suggestions for additional topics, such as; * Registry, EPP, RDAP initiatives * Big Data & associated data analysis * IETF DNS protocol updates * Registry security 4. And, as usual we shall invite a host presentation. If you are interested in participating, please email one or all of el(a)lisse.NA ondrej.filip(a)nic.cz jacques.latour(a)cira.ca kimberly.carlson(a)icann.org preferably by 2016-01-17. We hope that you can join us and request that you disseminate this Request to other lists where it might of of interest. el

5 8

gTLD RDAP profile - release candidate 2
by Francisco Arias Aug. 18, 2016

Aug. 18, 2016

Dear colleagues, I’ve attached release candidate 2 (i.e., draft final 2) of the gTLD RDAP profile in Office Open XML format. This version is a redline vs release candidate 1 (last version shared here on 30-June). We plan to publish the final version by early next week. Leaving aside minor wording and format edits, the main changes are as follows: 1. Section III: added reference to the upcoming Consistent Labeling and Display policy. 2. Section 1.5.17: clarified that registrars only need to show the variant names they know about. 3. Section 3.1.1: clarified footnote regarding expected requirement for registrations under .com, .jobs, and .net. Regards, -- Francisco

3 3

FW: ICANN News Alert -- New Registration Data Directory Services Requirements for gTLD Registries, Registrars to Take Effect in February 2017
by Gustavo Lozano Aug. 1, 2016

Aug. 1, 2016

Hello Colleagues, I think that you may find this news alert of your interest. Regards, Gustavo From: ICANN News Alert <no-reply(a)external.icann.org> Reply-To: "no-reply(a)external.icann.org" <no-reply(a)external.icann.org> Date: Tuesday, July 26, 2016 at 17:34 To: Gustavo Lozano <gustavo.lozano(a)icann.org> Subject: ICANN News Alert -- New Registration Data Directory Services Requirements for gTLD Registries, Registrars to Take Effect in February 2017 > ICANN News Alert > <http://www.icann.org/> > News Alert > https://www.icann.org/news/announcement-2016-07-26-en > > New Registration Data Directory Services Requirements for gTLD Registries, > Registrars to Take Effect in February 2017 > 26 July 2016 > > ICANN today announced that gTLD contracted parties must update their > Registration Data Directory Services (RDDS) by 1 February 2017. Registries and > registrars are required to implement the new Registration Data Access Protocol > (RDAP) gTLD Profile <https://www.icann.org/rdap-gtld-profile> . Registries > must also implement the data specifications defined in the Registry > Registration Data Directory Services Consistent Labeling and Display Policy > <https://www.icann.org/resources/pages/rdds-labeling-policy-2016-07-26-en> . > > The RDAP gTLD Profile and the RDDS Consistent Labeling and Display Policy are > the products of community efforts to improve the current system used to > discover who controls a domain name. This system comprises data retrieval > protocols WHOIS and a web-based version of WHOIS and databases controlled > by registries and registrars that contain domain registration information. > > ICANN has notified contracted parties that they are responsible for modifying > their systems within six months. ICANN consulted these parties when defining > the new requirements and implementation plans. > Background > The Registration Data Access Protocol was developed by the Internet > Engineering Task Force <https://ietf.org/> to eventually replace the WHOIS > protocol. This new protocol is superior to WHOIS in terms of data access > security, support for international characters, extensibility, and in the > standardization of query, response and error messages. The RDAP gTLD Profile > maps ICANN policy and contractual requirements onto technical requirements in > order to standardize directory services across gTLD contracted parties. > > The RDDS Consistent Labeling and Display Policy is a Consensus Policy > developed and adopted in accordance with ICANN Bylaws. The policy is the > result of recommendations adopted by the GNSO Council after the completion of > the Thick WHOIS Policy Development Process. The ICANN board adopted these > recommendations on 7 February 2014. > > The goal of the RDDS Consistent Labeling and Display Policy is to align the > way registries and registrars label and display registration data outputs. The > policy uses the output specifications found in the 2013 Registrar > Accreditation Agreement as the standard, thus only registries need to update > their systems. Changes might include renaming or re-ordering fields and > displaying additional data, such as registrar abuse contact information. > > For more information on these topics, visit: > * Registration Data Access Protocol gTLD Profile > <https://www.icann.org/rdap-gtld-profile> > * Registry RDDS Consistent Labeling and Display Policy > <https://www.icann.org/resources/pages/rdds-labeling-policy-2016-07-26-en> > * Thick WHOIS Policy Implementation > <https://www.icann.org/resources/pages/thick-whois-2016-06-27-en> > * Policy Implementation at ICANN <https://www.icann.org/policy/implementation> > About ICANN > ICANN's mission is to help ensure a stable, secure and unified global > Internet. To reach another person on the Internet, you have to type an address > into your computer - a name or a number. That address has to be unique so > computers know where to find each other. ICANN helps coordinate and support > these unique identifiers across the world. ICANN was formed in 1998 as a > not-for-profit public-benefit corporation and a community with participants > from all over the world. ICANN and its community help keep the Internet > secure, stable and interoperable. It also promotes competition and develops > policy for the top-level of the Internet's naming system and facilitates the > use of other unique Internet identifiers. For more information please visit: > www.icann.org <https://www.icann.org/> . > > > This message was sent to gustavo.lozano(a)icann.org from: ICANN News Alert | > no-reply(a)external.icann.org | ICANN | 12025 Waterfront Drive Suite 300 | Los > Angeles, CA 90094-2536 Email Marketing by > <http://www.icontact.com/a.pl/144186> > Manage Your Subscription > <http://app.icontact.com/icp/mmail-mprofile.pl?r=23976128&l=6333&s=2VAT&m=99… > 78&c=165637>

2 1

number of characters in a domain?
by Ryan Finnesey July 23, 2016

July 23, 2016

I was hoping someone can help me confirm my research. I am correct that domains are now limited to 67 characters in length including the extension? Cheers Ryan

3 2

Re: [gtld-tech] gtld-tech Digest, Vol 39, Issue 5
by Brian Mountford July 22, 2016

July 22, 2016

Francisco, I have questions about sections 1.5.14, 1.5.16 and 2.8.2. Profile Directive 1.5.14. The domain object in the RDAP response MUST contain the following events: - An event of eventAction type registration. - An event of eventAction type expiration. - An event of eventAction type last changed. The event of eventAction type last changed MUST be omitted if the domain name has not been updated since it was created. - An event of eventAction type last update of RDAP database. Is any particular ordering preferred in the results? Expiration will probably be later than last changed and last update. Should it come before or after the last changed and last update? Profile Directive 1.5.16. Entities MUST use jCard [RFC7095] structured addresses. RFC 7095 defines two different types of structured address: 3.3.1.3. Structured Property Values The vCard specification defines properties with structured values, for example, "GENDER" or "ADR". In vCard, a structured text value consists of one or multiple text components, delimited by the SEMICOLON character. Its equivalent in jCard is a structured property value, which is an array containing one element for each text component, with empty/missing text components represented by zero-length strings. jCard Example: ["adr", {}, "text", [ "", "", "123 Main Street", "Any Town", "CA", "91921-1234", "U.S.A." ] ] Some vCard properties, for example, ADR, also allow a structured value element that itself has multiple values. In this case, the element of the array describing the structured value is itself an array with one element for each of the component's multiple values. jCard Example: ["adr", {}, "text", [ "", "", ["My Street", "Left Side", "Second Shack"], "Hometown", "PA", "18252", "U.S.A." ] ] Which form is to be used in RDAP responses? If it is the first version (list of simple strings), what is to be done with addresses containing more than two street address lines? Profile Directive 2.8.2. Registrar object lookup using an entity search on the fn element MUST be supported. RFC 7482 3.2.3. says: XXXX is a search pattern representing the "FN" property of an entity (such as a contact, registrant, or registrar) name as specified in Section 5.1 of [RFC7483]. This is straightforward enough when referring to contacts and registrants, but I am not sure how it applies to registrars. Our database stores registrars, which have a name, and also registrar contacts, which hang off registrars, and themselves also have names. Are you asking us to search by registrar name (which we would prefer), or by registrar contact name? Thanks. Brian

2 3

Do not implement before date in CL&D and RDAP profile
by Francisco Arias July 21, 2016

July 21, 2016

Dear colleagues, As you may recall the gTLD RDAP profile and Thick Whois policy implementation – Consistent Labeling and Display (CL&D for short) are synchronized and have a proposed effective date of 1 February 2017. This means enforcement would start on that date. However, in monitoring compliance with a given policy or contractual requirement we also need time to develop our tools and be able to *not* report false compliance issues (e.g., our current tool would raise an issue if it encounters the new Whois output that is specified in CL&D). We need to update that tool to avoid that issue from happening. We’d like to add to both CL&D and the RDAP profile a “do not implement before” date to avoid the aforementioned issue. We are thinking we are going to need approximately four months to update/build our tools be able to identify the updated Whois output and RDAP output. That would give contracted parties approximately a two-month window for release before the effective. We are planning to add such a date to the documents, unless there is a reason why people think we should not. Regards, -- Francisco

6 9