Procedures for Test IDN Deployment

This document is historical and no longer maintained. It is preserved for reference purposes but should not be relied upon for up-to-date information, and should not be considered active. As a step toward envisaged operational deployment of Internationalized Domain Names in the DNS Root Zone, a trial will be conducted to place no-value IDN TLD A-labels in the root. This paper describes the IANA procedures for inserting and managing such labels.

Assumptions

Under the overall guidance of the ICANN Board, The Internet Assigned Numbers Authority (IANA) takes a careful and considered approach to adding, modifying and deleting delegations to the DNS root zone. As one of the most critical elements of Internet infrastructure, due diligence is required to ensure no adverse affects compromise the integrity of this critical service.

As alterations to the production root, adding and removing test IDN labels is no different in most respects to a regular top-level domain. The key differences can be described as:

1. The labels have no value -- that is to say that there are no production services relying on their existence. This means that apart from delaying testing, they can be removed from the root zone without any serious effects. Production labels, on the other hand, represent key infrastructure with sometimes millions of sub-domains.
2. The semantic name of the label is different from the label inserted into the root. IDNs rely on the conversion of a Unicode string into an IDNA equivalent beginning with “xn--".
3. There will be no largely autonomous registry responsible for operation of test IDN delegations; instead, the delegations of these labels will be administered by ICANN as the sponsoring organization.

Principles

1. As the test is primarily designed to test for adverse impact on root zone operations, it needs to be assumed one possible consequence is that there is an adverse impact on the root zone. Given that the labels have no value, and that the root zone is critical infrastructure, beyond routine maintenance functions – there should be an emergency revocation procedure that rapidly removes offending test labels from the root zone.
2. The emergency revocation needs to be enacted in a defined situation where the existence of the delegations compromises the effective operation of the root. (Note: the criteria is to be defined in another document)
3. IANA should document the semantic meaning of a particular label, such as what language it represents, its proper Unicode form and so forth, for public policy reasons. Therefore, this information needs to be transmitted to IANA during a registration in addition to the standard template elements.
4. For the purposes of the test, all test labels will be formally registered to IANA. This is consistent with reserved domains, infrastructure domains, and other protocol elements that do not have a clear definition of stewardship and are operated in the public interest (such as RFC 1918 address space.)
5. Each test label should be introduced into the root with a clearly defined lifespan. As these are temporary additions, they should specify termination criteria.

Procedures

Addition Procedure

1. The ICANN IDN Project Manager submits a special IDN change template after it has been approved by whatever mechanisms are required with respect to the ICANN IDN project. This change template will consist of the regular root zone change template, plus specific additional fields relating to the semantic meaning of the label, and its removal criteria.
2. IANA will process the change request through normal procedure. As routine, it will verify the contact details are correct (a formality, as these should be IANA’s addresses), perform technical verifications of the provided name servers, and so forth.
3. IANA will document a delegation request as through normal procedure, in consultation with the IDN Project Manager. This request is forwarded to the ICANN Board with accompanying descriptive documentation, pertinent standards documents, and a staff recommendation to the ICANN Board for consideration (and potential approval). Subsequent to approval, the delegation request is provided to necessary parties for information and approval in accordance with standard IANA procedures for all delegations and re-delegations. Delegation requests for multiple labels that are received together, and are justified on the same criteria, can be combined into a single Board application.
4. Upon approval, the request will be introduced into the root zone database as per regular procedure. The WHOIS records should detail this is a test domain, with reference to a web page that explains its semantic meaning, and the scope of the test. (A web page, because the current root zone management software can not easily have new fields added. A more integrated solution will be implemented in IANA’s future root zone system for production use)

Alteration Procedure

Alterations (i.e. changes to authoritative name servers) will be performed through normal procedures.

Deletion Procedure

1. IDN Project Manager will submit a delegation request to IANA Root Zone Management, not later than any expiry date given in the undertakings of the lifespan of the zone described in the initial application.
2. IANA will verify the request, and then implement a root zone change procedure as normal.

Emergency Revocation Procedure

1. IANA will be notified either by (a) The IDN Project Manager, or (b) an automated process the checks for objective criteria that have been designed to signal that a fault exists; that a fault condition exists that is eligible for emergency revocation.
2. IANA will investigate the nature of the fault to ensure root server operation deviates from accepted practices, and be satisfied that the cause is the IDN label.
3. Upon confirmation, a temporary revocation procedure will be executed whereby IANA will initiate a root zone change request that eliminates the delegation from the root zone. IANA will undertake to expedite its implementation as much as possible in consultation with the US DOC and VeriSign.
4. The delegation will remain in IANA’s root zone database (with zero listed authoritative name servers) with some indication it is in a revoked state.
5. The revocation can be annulled (and thus the delegation reimplemented into the root) without the same formal board approval required for a new delegation, provided a report is provided investigating the reason for revocation, and a satisfactory explanation on why reintroduction of the delegation will not jeopardize the safety of the root.

If the revocation appears to be permanent, or the other expiry conditions are met, then a regular deletion request must be submitted by the IDN Project Manager to move the delegation from revoked state to deleted state.