Skip to main content

Internationalized Domain Name -- URL in any Language

From whichever part of the world you belong, no matter what is your mother tongue, if you are reading this post, this means you understands English.
Nearly half of the world doesn't know English But still accessing Internet was not very much friendly  for those non-English speaking community to an extent due to the limitation of only having ASCII characters in domain names until few years back.
In simple term, before 2011 domains was restricted to be in English language only.

In 2011, ICANN approved addition of  IDN gTLDs (Internationalized Domain Name generic Top-Level Domain)in the root zone. And this gives the luxury to the internet community to have a domain url in any language.

ICANN has delegated IDN in seven languages to NIXI. Details of those are as follows:

Internationalized Domain Name (IDN)Language
.भारत.Bharat in Devanagari
.ভারত.Bharat in Bangla
.భారత్.Bharat in Telugu
.ભારત.Bharat in Gujarati
. بھارت.Bharat in Urdu
.இந்தியா.Bharat in Tamil
.ਭਾਰਤ.Bharat in Gurumukhi (Punjabi)

From 15th August 2014 onwards, NIXI will accept registration for .भारत IDN.

This means india.gov.in will have a corresponding भारतसरकार.भारत domain in Devanagari script. And any user across the world can also access india.gov.in website by typing भारतसरकार.भारत in the browser URL.
This will increase the penetration of the Internet through the use of local languages and help penetrate local content.


IDN Mapping with existing DNS Setup

IDN provide us the freedom to have a domain in any language. But existing DNS infrastructure doesn't support language other than English. And it is not easy to change/upgrade whole DNS infrastructure across the internet community.
For sorting out this issue, punycode comes into the picture.
Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications (IDNA). It uniquely and reversibly transforms a Unicode string into an ASCII string. ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are allowed in host name labels (letters, digits, and hyphens).


Internationalized Domain Name (IDN)Corresponding punycode
.भारतxn--h2brj9c
सरकार.भारतxn--11b7cb3a6a.xn--h2brj9c
рф (Cyrillic abbreviation of Russian Federation)  xn--p1ai
मेरीसरकार.भारतxn--11b3cgab9b4bm5d.xn--h2brj9c 




For running a authoritative DNS for .भारत IDN, you will have to make a zone in your server with 'xn--h2brj9c' name. (Obviously you are not going to do this as this will only be done by DNS Servers which ar actually authoritative for the same).
When you type सरकार.भारत in the url, your browser will automatically convert IDN domain in punycode format and do the DNS Query (of course browser needs to be intelligent enough for doing this).



DNS Query for an IDN domain






Popular posts from this blog

Identity PSK ( iPSK)

With the evolution of IoT (Internet of Things), devices that connect wirelessly have increased many folds. From webcams, Smartwatches, fitness bands, firestick, Alexa, Google Home, and many more.., everything is going wireless for connectivity and so does the security threat. The main concern with IoT devices is the unavailability of the full wireless protocol stack (and in the majority of devices, support of 802.1x is not available). So, previously we only have the WPA-PSK option for connecting the IoT devices.  In WPA*-PSK (WPA or WPA2) WLAN, a Pre-Shared Key (PSK) is configured and distributed to all the clients that connect to the WLAN. This leads to PSK leakage, and it can be accessible to unauthorized users (due to the nature of common PSK across all the devices).  Therefore, there was a need to provision unique PSK or Multiple PSK per SSID. Identity-PSKs are unique pre-shared keys created for clients/groups on the same WLAN. Features of iPSK:-   1.Unique PSK for individual Cli

Flaw in ServerKeyExchange messages of TLS Protocol

Here we will discuss the flaw in the ServerKeyExchange messages of the TLS protocol which caused the Logjam attack over TLS while using Diffie-Hellman Key Exchange. Before SSLv3, we don't use to authenticate the ServerKeyExchange messages where server negotiates with client regarding usage of cipersuite and parameters. From onwards SSLv3, TLS send the signed message where it mention about parameters it will use but remain silent over ciphersuite. Or in other words, signed portion contains parameters but not contain information about ciphersuite the server will going to use. Now just to remind you, the difference between DH and DH-EXPORT is the size of parameters only. So how to use this flaw - If the server supports DH-EXPORT, an attacker (Men-in-the-Middle) can edit the negotiation sent by the client (even if client doesn't support DH-EXPORT), and replace the list of client supported ciphersuite with DH-EXPORT only. The server will in turn send back a