Internationalized domain names: Noble ambitions deterred by system limitations

Internet is often described as the breakthrough technical invention of the 20th century and rightly so. When we talk about the popular internet format, i.e., World Wide Web, it started developing in the earlier half of the 1990s and within a short span of just 3 decades, it has achieved such wide popularity that it is not possible to think of the modern world without internet. Arguably, very few, if any, technical innovations have achieved such worldwide popularity across different sectors, locations, and demographics in such a short period. However, this breakthrough invention still has yet to overcome some challenges to create a seamless global connection that rises above all limitations. One such challenge is universally acceptable domain names.

The present domain names are restricted to English characters only which means that a Dubai based company can’t create domain names with Arabic script or a Korean company cannot create a domain name in the Korean language. While we have the provisions for internationalized domain names (IDN), there are still several hurdles to overcome to make IDN a seamless part of online access and communication system. 

What is internationalized domain name? – (A simple definition)

In simple words, the IDN allows for creating domain names in diverse scripts like- Hindi, Bengali, Arabic, Korean, Chinese, Japanese, etc. Hitherto, it was very difficult, almost impossible to create domain names in non-English characters but with the efforts of some progressive tech leaders and visionaries it has now become possible to create domain names in various non-English characters and the list is growing constantly.

The present issues for internationalized domain names

The issues associated with internationalizing a domain name go beyond just changing the script. There are diverse operational standards to be streamlined at par with conventional English-script domain names. We thus need a critical review of operational limitations for non-English domain names.

It lacks universal deployment of standards

Universal being the keyword in Universal acceptance the first and foremost need is to universalize the domain names regardless of scripts. The key challenge here is to provide universal deployment of standards instead of deploying fragmented updates across specific locations or demographics as this (latter) approach creates isolated silos of operations and development that act as barriers in global connection.

To be frank, in this era of fast globalization and agile work culture, very fewer people have the time and patience to iron out the technical creases and it makes more sense for them to employ convenient options (in this case- English script domain names). 

Email communication issues related to IDNs

Email is the fundamental application for online communication and in that capacity; it is the key foundation stone of the internet. It is the major source for connecting people and universally accepted tool for all official and formal communications. However, the architecture of standard user protocols for emails like MIME and SMTP doesn’t allow the use of specific characters in the domain portion of email addresses. It creates a communication barrier for non-English script domains.

Specific mailers have been purpose-crafted to overcome this challenge but their real-life performance still needs improvement to offer failsafe and seamless operations as no one would prefer using the mailers that may damage or misroute their messages. The most practical solution is upgrading the worldwide data servers to facilitate global communication on international domain names in the non-English script.

Issues related to Routing Policy Specification Language

 The RPLS or Routing Policy Specification Language still follows the conventional version of named objects which makes it technically impossible to fetch network description through IDN. So updating the routing registries and their respective protocols is a prerequisite for smooth IDN functionality.

Network Management Issues

 The SNMP does have a provision for UTF-8 characters in theory but when observed in the practical sphere the underlying software libraries- the key building component for SNMP-friendly software revealed that almost none of them implement it and the adoption rate is next to nil.

 This technical limitation acts as a deterrent for feeding or showing accurate data in network management tools for the IDNs.

Security issues for domain names

 Server and user identification is the key prerequisite for the smooth working of critical internet public key technologies like PKIXX and IKE. However, these protocols also lack the provision for allowing the entire range of characters. It invariably affects the underlying security components like IPsec and TLS.

 In TLS the server fetches a certificate showing its domain name and the client matches it the desired domain name he intended to reach.

 For that, we need clear and precise guidelines for domain names comparison that will facilitate the accurate matching of the server domain name and establish the authenticity of the domain name and avoid man in the middle attacks.


IDN is not an impossible feat to achieve but what’s more important- and ironically, more challenging- is to assure an entire range of smoothly functioning networking tools that seamlessly support IDN with zero restrictions. Until or unless, the entire domain and hosting ecosystem is not upgraded to be compatible with IDN, it would be challenging to achieve the target of universal acceptance.

Author BioJitendra Bhojwani (Jatin) is a versatile creative/tech writer and regular blogger and he loves sharing the latest news and information on WordPress and Blogging. He is a keen advocate of Open Source Technology and considers and respects writing as a meditative technique to get rid of negative thoughts and stress.

Leave a Reply

Your email address will not be published. Required fields are marked *