Synchronized IDN ccTLDs - Questions and Answers
- What are synchronized IDN ccTLDs?
- What does "synchronized" mean in the context of this process?
- What impact do synchronized IDN ccTLDs have on DNSSEC?
- What is the synchronized process intending to solve?
- What is the reason behind the requirements and rules in the synchronized process?
- What is meant by "resolving to the same address or value"?
- What does it mean to maintain synchronization?
- What does it mean for a registrant that the domains under synchronized IDN ccTLDs must resolve to the same address or value?
- What does it mean for the IDN ccTLD manager that domains under synchronized IDN ccTLDs must resolve to the same address or value?
- What kind of experience does a requester need to demonstrate?
- Who can request synchronized IDN ccTLDs?
- What scripts can be used for synchronized IDN ccTLDs?
- What happens after a request for synchronizing IDN ccTLDs has been evaluated and approved?
- How is a synchronized IDN ccTLD delegated in the DNS root zone?
- Can synchronized IDN ccTLDs be confusingly similar?
- How many synchronized IDN ccTLDs can I request?
- Can an IDN ccTLD change from being synchronized to not being synchronized?
- How will ICANN ensure that synchronized IDN ccTLDs are continuously fulfilling the requirements?
What are synchronized IDN ccTLDs?
Synchronized IDN ccTLDs are two or more IDN ccTLDs that have been deemed equivalent in the sense that there is a user expectation (based on cultural or linguistic traditions) that domains under each IDN ccTLD "resolve to the same address or values".
This has an effect on the registration of domain names under the IDN ccTLDs. For the registrant it means that making a registration of "domainname.syncTLDa" also results in a registration of "domainname.syncTLDb".
Registry operators are required to have mechanisms in place to ensure that synchronized domains provide end-users with appropriate responses. Such mechanisms must ensure as far as possible that the synchronized resolution takes place beyond the second level under the IDN ccTLDs, and the registry must review and implement correction procedures to alleviate any situations where lack of synchronization in a sub-tree occurs.
| back to top |
What does "synchronized" mean in the context of this process?
"Synchronized" in the context of this process relates solely to policy and procedural requirements. There is no technical mechanism by which synchronized IDN ccTLDs will be made to be identical at the DNS protocol level.
From a purely technical, DNS protocol perspective two synchronized IDN ccTLDs are simply two separate delegations from the root zone.
What is required is for the IDN ccTLD manager to have mechanisms in place to ensure that the synchronization is being kept in place as best as can be done with manual procedures.(see more details and explanations below)
| back to top |
What impact do synchronized IDN ccTLDs have on DNSSEC?
Synchronized IDN ccTLDs are provisioned in the root zone as separate delegations. Each daughter zone is distinct and can be signed independently of the other; trust anchors for each zone can be installed in the root zone as DS RRSets once the root zone is signed, or distributed in other ways.
The creation of synchronized IDN ccTLDs has no impact on DNSSEC deployment.
| back to top |
What is the synchronized process intending to solve?
The implementation plan for synchronized IDN ccTLDs is intended to provide a procedure by which a very limited number of variants of IDN ccTLDs can become eligible to initiate the String Delegation step in the IDN Fast Track Process. A full description of the IDN ccTLD Fast Track process can be found at http://www.icann.org/en/resources/idn/fast-track.
These are referred to as synchronized IDN ccTLDs and are allowed to continue to the String Delegation step in the Fast Track Process following the satisfaction of certain synchronization criteria and evaluations thereof. Introduction of synchronized IDN ccTLDs are not possible in the Fast Track Process as it stands today.
The synchronized IDN ccTLD requirements must be successfully met in the evaluation process based on information provided by the requester before the Fast Track String Delegation step can be initiated. Such information must include a demonstration that a problem is solved in the community that the synchronized IDN ccTLDs would be serving.
By allowing a very limited set of synchronized IDN ccTLDs it is also anticipated that the experience gained (following successful String Delegation) can be helpful to the entire community in the ongoing work of finding processes and mechanisms that work for the broader range of variants of IDN TLDs.
More detailed information can be found in the Synchronized ccTLD IDN Implementation Plan, http://www.icann.org/en/news/announcements/announcement-22mar10-en.htm.
| back to top |
What is the reason behind the requirements and rules in the synchronized process?
The requirements and rules in the synchronized process are designed to allow for continued evaluation and String Delegation of variants of IDN ccTLDs that otherwise would not be eligible for delegation. These requirements and rules are set at a level that is more detailed and comprehensive than is usual for arrangements between ICANN and TLD managers. It is a very careful approach following explicit principles provided by the ICANN Board, which makes the process technically secure and stable and the introduction of synchronized IDN ccTLDs, following this process, is not expected to create any issues for Internet users.
Once experience is gained and more technical testing and analysis has been conducted in the field of variants, aliasing, and related areas, it is possible that new and less restrictive processes and procedures can be rolled out.
| back to top |
What is meant by "resolving to the same address or value"?
"Resolving to the same address or value" is not specified in the Synchronized plan as a technical requirement of the DNS, but rather in the sense of ensuring an appropriate and consistent user experience.
It is entirely plausible that at the DNS protocol level the answers to queries for names under one synchronized IDN ccTLD might be different from those to names under a synchronized IDN ccTLD but that the two sets of answers could still be considered to be "synchronized". At the protocol level there are examples of similar incoherence in the DNS today with respect to DNS protocol elements which nevertheless preserve user expectations, such as those introduced by load balancers or used by content distribution networks.
The intention is that given two names synchronized to each other, a user's experience is that the two names refer to the same thing.
| back to top |
What does it mean to maintain synchronization?
Much like the answer above to "resolving to the same address or value", synchronization is not expected to be enforced using technical mechanisms, and the controls necessary to maintain synchronization are based in policy rather than in the DNS protocol.
What is required is for the IDN ccTLD manager to have mechanisms in place to ensure that the synchronization is being kept in place as best as can be done with manual procedures. Such manual procedures are, for example, requirements in the IDN ccTLD manager’s registration policy and management of the zones so that second level registration will have matching name servers (see examples below).
| back to top |
What does it mean for a registrant that the domains under synchronized IDN ccTLDs must resolve to the same address or value?
As above, the goal is to ensure an appropriate user experience, not to mandate identical answers to DNS queries at the protocol level.
For a registrant, synchronization means that making a registration of "domainname.syncTLDa" also results in a registration of "domainname.syncTLDb". The registrant of the domain names, and any variants of these domain names, must be the same. This might be presented by the IDN ccTLD manager as a bundled registration to the registrant.
If a blocked or reserved registration model is preferred then the IDN ccTLDs are not considered synchronized as this will not fulfill the definition of synchronized IDN ccTLDs where the user expectation is that usage of the IDN ccTLDs produces the same result.
The registrant is obligated to keep synchronization at lower levels of the registration. This means that the domains cannot be used for a purpose that is different. This will be apparent in the registration policy between the registry (or registrars/resellers) and the registrant.
| back to top |
What does it mean for the IDN ccTLD manager that domains under synchronized IDN ccTLDs must resolve to the same address or value?
As above, the goal is to ensure an appropriate user experience, not to mandate identical answers to DNS queries at the protocol level.
The requirement is that the registry operator has mechanisms in place that ensure that queries for names under "domainname.syncTLDa" and queries for names under "domainname.syncTLDb" result in a similar end-user experience. In addition, mechanism must be in place to ensure as far as possible that the synchronization in continued beyond the second level under the IDN ccTLDs. Review and correction procedures must be in place to remedy any situations where this is not the case.
This is facilitated by requirements for the requester to have synchronization mechanisms in place, and to provide information about those mechanisms when they submit their request to ICANN for synchronized IDN ccTLDs, including:
- DNS responses must produce equivalent results, as described in the previous Q/A’s, in all levels of the DNS tree within each synchronized IDN ccTLD domain.
- The requester must describe the technical mechanism they have in place to achieve 1)
- The requester must provide the Registration Policy they have in place to achieve 1)
- The requester must describe how they will enforce the registration policy, e.g., by a monitoring system and activities to fix situations that diverge from their policy
- The requester must agree to provide annual reporting to ICANN about experience/results/issues
The following demonstrate how synchronization can be achieved at the second level, and where S1 and S2 are two synchronized IDN ccTLDs, and where variants of domains registered are either synchronized via NS or DNAME:
; S1 zone, as maintained by the S1/S2 registry manager
$ORIGIN S1.
; registered domain DOMAIN.S1 is delegated
domain IN NS ns1.example.com.
IN NS ns2.example.com.
; variant DOMAIN-VARIANT1.S1 is provisioned using DNAME
domain-variant1 IN DNAME domain
; variant DOMAIN-VARIANT2.S1 is provisioned using a delegation
domain-variant2 IN NS ns1.example.com.
IN NS ns2.example.com.
; S2 zone, as maintained by the S1/S2 registry manager
$ORIGIN S2.
; registered domain DOMAIN.S2 is delegated
domain IN NS ns1.example.com.
IN NS ns2.example.com.
; variant DOMAIN-VARIANT1.S2 is provisioned using DNAME
domain-variant1 IN DNAME domain
; variant DOMAIN-VARIANT2.S2 is provisioned using a delegationdomain-variant2 IN NS ns1.example.com.
IN NS ns2.example.com.
; DOMAIN.S1 zone, as maintained by the registrant
$ORIGIN domain.S1.
@ IN SOA …
IN NS ns1.example.com.
IN NS ns2.example.com.
; WWW.DOMAIN.S1 (and also WWW.DOMAIN-VARIANT1.S1)
; is served by this particular server
www IN A 192.0.2.1
IN AAAA 2001:db8::1
; DOMAIN.S2 zone, as maintained by the registrant
$ORIGIN domain.S2.
@ IN SOA …
IN NS ns1.example.com.
IN NS ns2.example.com.
; WWW.DOMAIN.S2 (and also WWW.DOMAIN-VARIANT1.S2)
; is served by this particular server
www IN A 192.0.2.1
IN AAAA 2001:db8::1
; DOMAIN-VARIANT2.S1 zone, as maintained by the registrant
$ORIGIN domain-variant2.S1.
@ IN SOA …
IN NS ns1.example.com.
IN NS ns2.example.com.
; WWW.DOMAIN-VARIANT2.S1 is served by this particular server
www IN A 192.0.2.1
IN AAAA 2001:db8::1
; DOMAIN-VARIANT2.S2 zone, as maintained by the registrant
$ORIGIN domain-variant2.S2.
@ IN SOA …
IN NS ns1.example.com.
IN NS ns2.example.com.
; WWW.DOMAIN-VARIANT2.S2 is served by this particular server
www IN A 192.0.2.1
IN AAAA 2001:db8::1
The registrant registered DOMAIN.S1 and received DOMAIN.S2 automatically. Both domains have the same NS record in the S1 and S2 zones, in accordance with this example registry’s implementation policy.
The S1/S2 registry manager also provides support for variant strings at the second level. DOMAIN.S1 and DOMAIN.S2 have corresponding variant domains DOMAIN-VARIANT1.S1 and DOMAIN-VARIANT1.S2 (provisioned using DNAME in this example) and DOMAIN-VARIANT2.S1 and DOMAIN-VARIANT2.S2 (provisioned using delegations).
Per the registration policy of the S1/S2 registry manager, the registrant, when adding names under the DOMAIN.S1 domain, is also required to add equivalent names under the DOMAIN.S2 domain. In the example shown:
- WWW.DOMAIN.S1 and WWW.DOMAIN.S2, names which support web services, are made equivalent by the registrant provisioning identical A and AAAA records in each zone;
- WWW.DOMAIN-VARIANT1.S1 and WWW.DOMAIN-VARIANT1.S2 are made equivalent to WWW.DOMAIN.S1 and WWW.DOMAIN.S2 by the S1/S2 registry manager provisioning those variants using DNAME;
- WWW.DOMAIN-VARIANT2.S1 and WWW.DOMAIN-VARIANT2.S2 are made equivalent to WWW.DOMAIN.S1 and WWW.DOMAIN.S2 by the registrant provisioning identical A and AAAA records in each zone.
| back to top |
What kind of experience does a requester need to demonstrate?
All of the requirements for a requester of synchronized IDN ccTLDs are specified in the Requirements Section of the Implementation Plan. How the requirements will be evaluated is further explained in the section for Evaluation of Requests.
One of the evaluation criteria that are important to point out is that of experience. It is expected that the requester has successful experience with managing synchronized domains, either in a live environment at lower levels of existing TLDs or in a test environment that adequately simulates the DNS root zone.
| back to top |
Who can request synchronized IDN ccTLDs?
Any successful participant in the IDN ccTLD Fast Track Process involving IDN ccTLDs that are considered synchronized can participate in the process and request to deem those IDN ccTLDs as synchronized.
Certain requirements are necessary to be demonstrated, including experience with managing synchronized domains and explanation of what problem is being solved by the introduction of the IDN ccTLDs.
The requirements and the described evaluation of them are set forth in the Implementation Plan and are recommended to be reviewed prior to submission of a request.
| back to top |
What scripts can be used for synchronized IDN ccTLDs?
There is no list of scripts or languages, or any other lists, that will indicate that a certain IDN ccTLD need to be operated as synchronized IDN ccTLDs.
Whether an IDN ccTLD can be used in a synchronoized fashion is determined by a user expectation that the IDN ccTLDs are run in a synchronized manner as described above. Usually this means that the IDN ccTLDs are considered variants and that the characters that are variants are identified as variants in the associated IDN tables.
However, the sole demonstration that the IDN ccTLDs are variants is not sufficient for a requester to be eligible for the synchronized process. See Participation requirements in the Implementation Plan.
| back to top |
What happens after a request for synchronizing IDN ccTLDs has been evaluated and approved?
Much like the Fast Track process itself, there are two distinct processes involved in the deployment of synchronized IDN ccTLDs. Firstly, a request must be submitted to have the IDN ccTLDs considered synchronized. Once that request has been approved, the requesters may submit requests for the delegation of the synchronized IDN ccTLDs. This is done by following ICANN's standard processes for TLD delegation, through the IANA function.
| back to top |
How is a synchronized IDN ccTLD delegated in the DNS root zone?
Once a request for a synchronized IDN ccTLD has been approved and the request for delegation of the synchronized IDN ccTLDs has been passed, the IDN ccTLDs are delegated in the DNS root zone as per the standard process today. That is done by standard and separate NS delegations. The requirements for keeping the contents of the IDN ccTLD zones synchronized are done by the registry operator. ICANN will not be auditing the IDN ccTLD zones.
From a root zone operational standpoint, while they are technically two distinct delegations, operational and management actions such as delegations, redelegations and maintenance changes are required to be requested by the IDN ccTLD manager in concert to preserve their synchronization.
Should technical developments facilitate alternative mechanisms for supporting variants of TLDs in the root zone which are found to be preferable to provisioning variants using distinct delegations, ICANN will develop an appropriate phase-in period and operators of synchronized IDN ccTLDs will need to migrate as appropriate to the new methodology.
| back to top |
Can synchronized IDN ccTLDs be confusingly similar?
No, the synchronized IDN ccTLDs cannot be confusingly similar. They can also not be confusingly similar to any other TLDs requested through the Fast Track Process or through the gTLD Program, nor to any reserved words, blocked TLDs, or any TLDs currently in the DNS root zone.
This is a requirement in the Fast Track Process, which, as all other Fast Track requirements, still stands for the synchronized IDN ccTLDs. It is validated as part of the evaluations in the Fast Track Process. Hence only requests that have successfully passed the String Evaluation of the Fast Track Process can enter the process for synchronized IDN ccTLDs.
The visual confusability is assessed by the DNS Stability Panel and guidance for their assessment is provided online at: http://blog.icann.org/2010/03/clearing-the-confusion-fast-track/
| back to top |
How many synchronized IDN ccTLDs can I request?
As the Fast Track limitation rules are still in effect for synchronized IDN ccTLDs, the maximum number for any requester is still one per script or language that is official in the country or territory corresponding to the request.
Due to the nature of synchronized IDN ccTLDs, there must be at least two IDN ccTLDs that are synchronized to each other. This implies that a country or territory must have a minimum of two official languages or scripts in order to be eligible for synchronized IDN ccTLDs.
ICANN understands that these limitations do not resolve all issues currently present concerning variants of IDN ccTLDs, but it is a first step allowing for delegation of variants of IDN ccTLDs in a limited and careful approach.
ICANN will continue work to address the remaining issues, in particular with a goal of allowing delegation of other IDN TLD variants, aliasing or sameness in a broader scale. In that work, ICANN will follow the work of the DNS Extensions (DNSEXT) working group of the IETF, together with other parts of the technical community, and hope that the experience with synchronized IDN ccTLDs will help facilitate additional progress in this area.
ICANN understands that there have been some recent discussions about the validations and definitions used for script in relation to the Fast Track Process. The Fast Track Process has a review mechanism in place and subsequent to the Process for Synchronized IDN ccTLDs, ICANN staff will make an analysis of whether the a review of the Fast Track process should be initiated immediately to accommodate for a revision of the script criteria. In any event, the Fast Track Process is scheduled for a review no later than 16 November 2010. This review will be conducted in an open and transparent manner and reply heavily on user input and feedback as the intent with the review is to ensure that the Fast Track process functions well for all participants and users involved with IDN ccTLDs.
| back to top |
Can an IDN ccTLD change from being synchronized to not being synchronized?
An IDN ccTLD cannot change from being synchronized to being unsynchronized unless a very substantial linguistic and cultural change takes place. Such substantial change is not expected to take place. If the IDN ccTLDs are considered equivalent and there is a specific user expectation that they are synchronized, then this is not expected to change.
| back to top |
How will ICANN ensure that synchronized IDN ccTLDs are continuously fulfilling the requirements?
The registry manager is required to report to ICANN showing how the synchronized requirements are fulfilled and how correction mechanisms and actions are resolving any issues that are found as a result of the active monitoring of the synchronized requirements.
ICANN will not be auditing the IDN ccTLD manager, the IDN ccTLD zone content, or other parts of their system.
As more work is conducted in the general field of synchronized, aliased, and other variant related approaches it is plausible that other and more automated mechanisms are developed and found more appropriate to manage synchronized IDN ccTLDs. In such a case, the IDN ccTLD managers are required to transition to the new technology if technically possible and appropriate. Such development could result in more automation or in some cases completely eliminate the need for the IDN ccTLD manager to conduct compliance checks against the required synchronized requirements. This in turn could reduce the amount of reporting required to ICANN.
Detailed plans will need to be developed for such situations.
| back to top |