Archive for the 'idn' Category

Domain Tool for iPhone — whois on the move

Friday, October 3rd, 2008

Introducing DomainTool — an iPhone application for querying domain name whois information. I wrote this to learn iPhone programming (with a certain killer app in mind) as well as to scratch my own itch.

Occasionally, I find myself needing to think of a product name or domain name for a web site. Ideas can knock on my head at any time: at lunch, in the toilet or waiting in the queue. I could note it down on a generic note taker on the phone, or jot it down on a piece of paper, but nothing beats being able to instantly find out if the domain is available and keep track of it in a dedicated app. Hence, DomainTool was born.

As with any great app, it should be simple to use, and addresses a focused need. Thus, you’ll find the following grand feature list:

  • Query WHOIS servers to find out if a domain name is taken. Similar to the command line whois tool
  • Bookmark a domain name, and query it again anytime
  • Supports all TLD that has a published WHOIS server: COM, NET, ORG, BIZ, INFO, CC, JP, CN, TW, KR, MY, SG, PR, DE, EU, and many more!
  • Supports Internationalized Domain Names (IDN)

Some screenshots:

By now, I suppose you’re dying to try it out on your iPhone, and I can certainly sympathize with that. It can be yours for USD0.99 (or the equivalent in your currency) — 70% of which goes to my coffee bank, and the rest goes to Mr. Jobs.

Get it here!

More Languages in .BIZ

Wednesday, January 23rd, 2008

We launched another round of 6 languages in .BIZ on January 16th, 2008: Finnish, Hungarian, Latvian, Lithuanian, Polish and Portuguese (press release).

While NeuStar already has many Latin-based IDN languages in its portfolio, one may wonder why we would bother making the Venn diagram so complicated. Just define a Latin script-based table and be done with it! Well, since we tend to take a more conservative approach with IDN, it is safer to have each language table contain only the characters used by that language proper and nothing else1. After all, we’re here to provide value and not to make a quick buck (at least that’s how I see it.)

1 Language is constantly evolving. Often, it is not easy trying to determine if a character used in borrowed words is well-assimilated in the culture to be considered part of the language. There are no clear rules, do we follow the guidelines from the trademark offices’ of the countries in which the language is used? Or do we follow the ccTLD registry (if we do, does it make sense for a gTLD?) Or language institutions? Thankfully, there are many great resources to draw from.

.test IDN TLD (For Real!)

Tuesday, August 28th, 2007

Tina Dam and I caught up during ICANN San Juan on the current state of IDN TLD work within ICANN and that was when I first found out that she was putting together a live IDN TLD test bed which includes translations of the string .test into eleven written languages (Arabic, Chinese-simplified, Chinese-traditional, Greek, Hindi, Japanese, Korean, Persian, Russian, Tamil and Yiddish) and ten scripts (Arabic, Cyrillic, Devanagari, Greek, Han, Hangul, Hebrew, Hiragana, Katakana, Tamil).

I was very excited to hear that and wanted to blog about it but there was much to catch up at work so I let it slide.

Two days ago, an update from ICANN on this project:

ICANN today finalized the IDN .test Evaluation Plan and continued taking steps toward insertion of IDN strings in the root zone. Recent changes to the plan are based on comments received on the IDN public forum and also from consultations with ICANN Technical Advisory Committees. This last version was approved by the ICANN Board at their 14 August 2007 meeting. The resolution directs ICANN Staff to implement the IDN .test Evaluation Plan, and report back to the ICANN Board following the conclusion of the evaluation.

Specifically, the Board approved the delegation of eleven evaluative top-level domains representing the term ‘test’ translated into: Arabic, Persian, Chinese (simplified and traditional), Russian, Hindi, Greek, Korean, Yiddish, Japanese and Tamil. Following this ICANN Board approval, the delegation request will now go through standard IANA procedures for insertion of top-level domains into the root zone. The technical evaluations of IDN TLDs and their usability in various applications will proceed following their delegation.

This is a major milestone in the IDN Program Plan and signals a significant step forward towards Internationalization of the DNS. It is currently anticipated that delegation of these TLDs and the evaluations, as described in the plan, will commence in September 2007.

I would like to applaud ICANN (specifically Tina) on bringing the project this far. This is a major undertaking, and an important one too, for the following reasons:

  1. It works across the Internet — not just an isolated test that involved a couple of PCs running in a lab environment; they are going to insert these labels into the root zone! This is the only way to involve the most diverse mix of participants in the test bed. The fact that it requires no special setup (like tweaking of hint files) may lower the barrier for entities such as ISP’s, who are traditionally seldom interested in the development of IDN, to participate.
  2. As a result, it allows the most diverse array of test cases possible. Just imagine how an innocent domain name gets passed around applications, resolvers, recursive and authoritative DNS servers through a myriad of functions, API calls and networking protocols. It’s supposed to work but who knows for sure?
  3. It tests major scripts used by regions with an immediate need for IDN-TLDs (Latin would have induced yawns)

I’m sure there are skeptics and ICANN-haters out there who will dismiss this for time-wasting activity, etc. The truth is, no one has actually tested IDN TLD’s on Internet-wide scale before. And no, country-wide deployments will not suffice because the diversity of software environments and cultures simply isn’t there.

And if you’re a proponent of the Just-do-it school of thought, this should be seen as a move in the right direction. If no major problem was found during the live test, it will shut the mouths of those who are doubtful.

We should take advantage of this test to file bugs for your favourite software vendors and get them to support IDNs! When was the last time IANA inserted a test TLD to the root? Tell them that if IANA agreed to put these test strings in the freakin’ root, this is not a default ignorable technology alright!

So, help spread the word and test the Internationalized Internet!


.BIZ Korean IDNs Just Launched

Monday, August 20th, 2007

The second piece of news following the localization of EchIDNA into Korean is that we have just launched Korean IDN registration in .BIZ three hours ago. I won’t divulge the numbers here but let’s just say that it far exceeded my expectations.

You may be wondering if there is any connection between our Korean launch and the localization of EchIDNA. Aside from yours truly being involved in both projects, it is purely coincidental. We have been preparing for the Korean launch for a few months, and in doing so have consulted with NIDA (National Internet Development Agency in Korea) and have adopted their language table (with 2,350 KS X 1001 Hangeul characters). The table is available here: and will be posted to the IANA Repository of TLD IDN Practices soon.

If you have a .BIZ Korean IDN and would like some free links, submit it to!

EchIDNA Speaks Korean

Monday, August 20th, 2007

안녕하세요! There are two pieces of great news I’d like to report, both of which relate to the Korean Internet users community.

First of all, EchIDNA is now localized to Korean thanks to Jaeyoun Kim (www.김재연.kr) who took the initiative that triggered a collaboration between us where he translated the EchIDNA user interface into Korean and I added localization support to the code. While I have long been thinking about localizing EchIDNA, I never did get around to doing it so I’m really glad that it’s finally out.

Here’s a screenshot of it in action:

EchIDNA Korean UI screenshot

This move was largely motivated by the disheartening news that Verisign discontinued its IDN Web Navigation system on July 25th 2007. A bit of explanation of the so-called IDN Web Navigation System is in order. Basically, every IDN registered in the com and net TLD gets one or more A records inserted into the zone that points to a Verisign web server(s). These are not punycode domain names but binary representation of the IDN in local code pages where it is likely used, plus maybe some IE-specific behavior. The latter refers to an IE5/6 quirk that will encode the individual bytes of the domain name in the system code page to UTF-8 by treating them as ISO8859-1 characters. By doing so, users who are using non-IDN aware browsers will be redirected to Verisign’s web service which will then offer them the ability to download its i-Nav plug-in, and at the same time select the correct IDN domain to navigate to. Since the A records are binary representations, there is a possibility of collision which explains why the users have to select. It’s not hard to imagine that the general Internet users may mistake i-Nav to be the Web Navigation system that they were using, and since it works why bother downloading anything? So my guess is that many users simply ignored the i-Nav download part and click through to the site they wanted to go to. When the service was discontinued these users were lost. It didn’t take long for the domain owners to notice and complaints started flooding into the registrars and hosting providers. Some of these complaints also made it to NIDA which had an agreement with Verisign to distribute the i-Nav plug-in (and since users confuse i-Nav with the IDN web navigation system, it just looked like “i-Nav stopped working”.)

While I agree that this is really a hack and that the service cannot run forever, it is simply too soon as IE7 is not even one year old in Korea. Even though there is technically nothing wrong with discontinuing a hack, I can’t help but question the ethical validity of the decision, given the obscene amount of cash made from these TLDs. I wonder if the transition could be made smoother by first disabling the navigation feature and explaining to the users that they really need to be using an IDN-aware browser or download a plug-in.

Many ccTLD registries (CN, DK, JP, KR, TW to name a few) that offer IDN registration also run a similar web navigation system for their TLD, and AFAIK are still running it.

So, back to EchIDNA. The localized version was released on August 15th, 2007 and is available on

Chinese and Japanese IDN in .BIZ

Tuesday, April 24th, 2007

I just got back this morning from attending the OASIS XRI TC face-to-face meeting in San Diego with Bill Barnhill, Drummond Reed, Laurie Rae, Les Chasen, Markus Sabadello, and Marty Schleiff. A number of good things came out of the meeting, which I’ll leave for another blog because this post is about Internationalized Domain Names, not XRI.

So we just opened the flood gates for Chinese and Japanese IDNs for .BIZ. This has been my brainchild for the past half a year or so, and represents a significant step forward for our registry in terms of internationalization. As one might expect, no support for Chinese IDN is complete without bundling as specified in the JET guidelines and RFC4713.

The tricky part to supporting both Chinese and Japanese IDN within a single registry is that the two languages share a large repertoire of Han characters. While the concept of Simplified and Traditional Chinese is well-understood within the Chinese communities, Japanese generally do not use variants the same way. Two characters that may be considered variants by a Chinese user may be seen as distinct characters with different semantics from the Japanese’ point of view. To implement a registry that respects the culture and expectations of both language communities while offering a high degree of protection against homographic attack is a juggling act in itself. I dare say that NeuStar is the first unsponsored gTLD registry that Got It Right ™.

So, how does it work? Well, suppose you registered 電車.biz with the Chinese language tag, you will automatically get the simplified version of the domain, 电车.biz, placed into the DNS for you. No one can register any combination of variants of the domain, e.g. 电車.biz and 電车.biz.

What if you registered a mixed version 電车.biz, also with the Chinese tag? Well, you get that PLUS 電車.biz (traditional) and 电车.biz (simplified) giving you 3 domains in total! That is because we respect the registrant’s request, even if it looks like a mixed- traditional and simplified string. Whatever you asked for, if it doesn’t clash with another registered domain, will always be given to you.

If, however, the Japanese tag was used to register 電車.biz, that would be the only domain that you’d get. Once that is registered, other variations of the domain name in Chinese will not be allowed to register. This is a slight deviation from JPRS‘s appraoch, which treats them as distinct domains. We feel that this conservative approach offers better protection for the registrant.

So that was the skinny on our Chinese and Japanese Internationalized Domain Names offering. Is it me or do Han characters look very good with .BIZ? =)

Usual disclaimer about this being my personal opinion applies.

Security Restricted Domains Database

Monday, January 22nd, 2007

This was going to be a “Dear LazyWeb” request, but after some research I found what I wanted.

Recent discussions about security and phishing on the OpenID list got me thinking about the problem space.

DNS plays a critical role in the security of OpenID because

  1. URL is the identifier type used
  2. User should only trust the OP with which he/she has an account with.

The “Phishing and OpenID” discussions on the OpenID list actually hinges on point #2 above. Ben Laurie wrote about it here. In short, OpenID opens the door for a malicious RP to send a user to a spoofed OP-lookalike and collect his/her password.

Back to DNS. I have, on numerous occasions in the past, tried to look for a list of domains where registrations are open for public. This varies from TLD to TLD, e.g. .biz accepts registration directly on the second level, .us also does but delegates two-letter subdomains to US states, and .uk only accepts registrations on the third level after,, etc.

Well, it turns out that the Mozilla folks needed this list in order to disallow web sites setting cookies for the entire or similar domains. Currently, they block just the TLDs so cannot set a cookie for .com, but 2nd level onwards domain cookies are allowed. This could easily cause cookies to be stolen by any site rooted in the same domain.

So, this advisory started this bugzilla entry at Mozilla and it eventually led to the creation of this API and this list (see attachment). They call it the “Effective TLD” list, which is really a misnomer because they are not necessary just TLDs. It was decided in the bug discussions that the term “effective TLD” is easier to digest that anything else, though I’d prefer to call it “Security Restricted Domains”. Whatever, as long as it gives me the content I want.

Many will probably criticize Mozilla for creating yet another list that gets stale the moment it is created. Indeed, TLDs get created and 2LDs within TLDs are introduced and deprecated so often that such a list will be hard to maintain. Moreover, many organizations assign names to registrants at a level that doesn’t involve the TLD registry. Examples include CentralNIC’s .<country-code>.com and *, and countless others. Add to it the introduction of IDN TLD may well be in less than 2 years. Keeping a definitive list is not feasible. Nevertheless, I would argue that depending on your needs, this list could still be very valuable, as is the case with the cookie problem that they are trying to solve.

So, what has this got to do with OpenID? I shall leave that to a different post.

NeuStar Launches 5 New Languages for .BIZ

Thursday, November 2nd, 2006

We launched 5 new languages for IDN in .BIZ today. They are Danish (da), Icelandic (is), Norwegian (no), Spanish (es) and Swedish (sv). Prior to this, the only language available in .BIZ was German (de), launched in October 2004.

I’d like to take this opportunity to thank DK-Hostmaster, ISNIC, NORID, NIC-SE and Cary Karp of MuseDoma for their help and advice on these tables. The work on these tables really started 2 years ago when we first had the intention to launch additional languages, so I am very proud and relieved that they made it out!

Here’s a summary of the non-ASCII characters available for registration:

Code Point Character Language Codes
U+00E0 à no
U+00E1 á is,no,es
U+00E4 ä de,da,sv,no
U+00E5 å da,sv,no
U+00E6 æ da,is,no
U+00E7 ç no
U+00E8 è no
U+00E9 é da,sv,is,no,es
U+00EA ê no
U+00ED í is,es
U+00F0 ð is
U+00F1 ñ no,es
U+00F2 ò no
U+00F3 ó is,no,es
U+00F4 ô no
U+00F6 ö de,da,sv,is,no
U+00F8 ø da,no
U+00FA ú is,es
U+00FC ü de,da,sv,no,es
U+00FD ý is
U+00FE þ is
U+010D č no
U+0111 đ no
U+0144 ń no
U+014B ŋ no
U+0161 š no
U+0167 ŧ no
U+017E ž no

If you’re looking to register a Scandinavian or Spanish domain name, visit your favourite domain registrar to get yourself one.
When you’re done and made a web site out of it, don’t forget to submit it to IDNSearch.NET!

IDN in the News

Wednesday, October 25th, 2006

In the past week or so, we have seen a few pieces of news worth mentioning here:

September 30RFC4690Review and Recommendations for Internationalized Domain Names was published. Here’s the abstract from the document:

This note describes issues raised by the deployment and use of Internationalized Domain Names. It describes problems both at the time of registration and for use of those names in the DNS. It recommends that IETF should update the RFCs relating to IDNs and a framework to be followed in doing so, as well as summarizing and identifying some work that is required outside the IETF. In particular, it proposes that some changes be investigated for the Internationalizing Domain Names in Applications (IDNA) standard and its supporting tables, based on experience gained since those standards were completed.

Yes, you heard right – it is a proposal to update the IDNA standard. The story is this: IDNA is based on Unicode version 3.2 which means that many newly added characters (especially many African scripts) will not be usable as domain names. Unicode is at version 5.0 now and is continually being updated. The fact that IDNA has no versioning feature is a massive headaches for the standards bodies and implementors alike.

October 18 – The much anticipated IE7 was officially released. Internet Explorer is the last but largest major browser to support IDN, making this the most important event for the world of IDN.

October 23 – Afilias announces new scripts (Polish, Swedish, Danish, Hungarian, Icelandic, Latvian, Lithuanian and Korean) for IDN in .INFO (Press Release).

More IDN news to follow, stay tuned.

IE7 with IDN support

Tuesday, October 17th, 2006

From the official IEBlog posting entitled “IE7 Is Coming This Month…Are you Ready?”:

The final release of IE7 is fast approaching … and I mean really fast … and will be delivered to customers via Automatic Updates a few weeks after it’s available for download.

The #1 feature in IE7 that interests me greatly is its support for IDN. Yes, it’s a little late (3.5 years after the IDNA standard was published and more than 4 years after Mozilla implemented it in the browser.) Still, being the most popular browser on the planet this marks a very important milestone in the history of IDN. In fact, JPRS saw the IDN registration numbers soar after Microsoft announced that IE7 will support IDN. I’m sure many other IDN-enabled registries experienced similar surges too.

I’ve been using the RC1 version of IE7 for about a month now, and have been using to find example IDN URLs. So, if have IE7 installed and want to see a real-life IDN in action, head over to

If you’re an IE6 user, I would encourage you to upgrade.

Download IE7 here:
Find IDN examples here: