Summary

  • The IDN Fast Track review approved the Urdu-script string in January 2011; it did not itself place an operational zone in the DNS root.
  • Pakistan selected NTC in 2015, reopened the delegation request in 2016, and completed root-zone nameserver changes in 2017.

Analysis

The label looks like a country name. In DNS operations it also had to become a specific, testable delegation. Pakistan’s .پاکستان—the Urdu-language word for Pakistan written in Arabic script—shows why those are separate acts. The string could pass a review for stability and confusion risk before a registry operator had been approved and its nameservers entered into root-zone records.

The work began locally with language and implementation questions. Pakistan’s Ministry of Information Technology held an April 2008 workshop on character-set choices for local languages, then a May 2009 workshop on language tables and implementation. A committee of local Internet-community participants met in October 2009; subcommittees later addressed technical, language-table and policy matters. These were not cosmetic preparations. IDNA rules make a Unicode label usable through DNS-compatible forms, but they do not choose a country’s preferred spelling, keyboard policy or registry manager.

Pakistan submitted .پاکستان to ICANN’s IDN Fast Track on 25 October 2010. The DNS Stability Panel’s 7 January 2011 review found no stability or security threat identified by the applicable plan and judged the risk of user confusion acceptably low. The string was then approved as a representation of Pakistan. That decision answered a bounded question about the label. It did not assign the operator responsible for the zone or publish its delegation in the root.

The script/wire distinction is easy to miss. IANA records the Unicode form as پاکستان and the ASCII-compatible form as xn--mgbai9azgqp6j. RFC 5890 calls these presentation and DNS-compatible forms a U-label and an A-label. RFC 5891 describes IDNA as application processing that allows internationalized names without changing DNS itself; DNS queries and responses use A-labels. Punycode is therefore a reversible encoding step, not an English translation and not evidence that the Unicode form is a second domain.

The next stage took a different route. After further work on local content, keyboard design and draft policy, Pakistan’s Main Technical Committee selected the National Telecommunication Corporation as manager on 3 June 2015. The Ministry started a root delegation request that July. IANA’s report says the request was temporarily closed while deficiencies were remedied; NTC submitted a new ticket on 22 April 2016. The December 2016 root-zone audit still listed the request as pending.

On 3 February 2017, ICANN’s Board reviewed whether PTI had followed the required evaluation procedure and approved creating .پاکستان with NTC as manager. The record describes government support, local consultation, technical competence and DNS configuration checks. It also says no significant community concern was known and no notable stability risk had been identified. The Board action was about the delegation and accountable operation, not a second judgment about whether the Urdu string represented Pakistan.

The implementation trail continues beyond the vote. IANA’s March 2017 root-zone audit records a completed nameserver transaction for .پاکستان on 30 March. That confirms a root-zone change during 2017; the audit does not say it was the first insertion. IANA’s current delegation record lists NTC and its nameservers. Its metadata also shows a “Registration date” in 2011, which should not be confused with the dated 2017 Board and root-zone records: the sources assign those fields to different milestones.

The distinction matters because a written name does not operate itself. A locally selected label needs a stable encoding, an accountable manager, technically responsive nameservers and a root-zone delegation. Conversely, a root-zone entry does not prove that websites adopted the script, that every keyboard can enter it, or that users found localized content. The record establishes a sequence of decisions and infrastructure changes, not adoption or user outcomes.

Sources