Latest news of the domain name industry

Recent Posts

Here’s how to display new IDN gTLDs in Chrome

Kevin Murphy, October 24, 2013, 14:50:27 (UTC), Domain Tech

A lot of people have noticed since the first four new gTLDs were delegated yesterday that Google’s Chrome browser doesn’t seem to handle internationalized domain names.
In fact it does, but if you’re an English-speaking user you’ll probably need to make a few small configuration changes, which should take less than a minute, to make it work.
If you’re using Chrome and you click this link http://nic.сайт chances are your address bar is going to automatically translate it and display it as http://nic.xn--80aswg/.
As far as the DNS is concerned, these are the same URLs. They’re just displayed differently by Chrome, depending on your browser’s display languages settings.
If you want to see the Cyrillic version in your address bar, simply:

  • Go to the Chrome Settings menu via the toolbar menu or by typing chrome://settings into the address bar.
  • Click the “Language and input settings” button. It’s in the Advanced options bit, which may be hidden at first. Scroll all the way down to unhide.
  • Click the Add button to add the languages you want to support in the address bar.

Right now, you can see all three active IDN gTLDs in their intended scripts by adding Arabic, Chinese (Simplified Han) and Russian. As gTLDs in other scripts are added, you’ll need to add those too.
Simple.
Thanks to DNS jack o’ all trades Jothan Frakes for telling me how to do this.

Tagged: , , ,

Comments (12)

  1. Acro says:
    October 24, 2013 at 2:54 pm

    How about just using Firefox, it handles them just fine without any manual intervention?
    Sorry google, you failed this one.

    Reply
    • Kevin Murphy says:
      October 24, 2013 at 2:56 pm

      I value performance, and Firefox failed me on that count many years ago.

      Reply
    • Jothan Frakes says:
      October 25, 2013 at 6:47 am

      Hey Acro, glad it works…
      This was changed recently from a community driven whitelist of what would and would not expose the xn-- (a-label) vs. display the Unicode in the location.
      Mozilla volunteers from all over the world like myself (and I am a small part of the overall effort) put a lot of energy, time, and work into your experience.
      When I see a post like this, it is a reminder of why it is worth investing time in the Mozilla project.
      Thanks for the kind words.

      Reply
  2. Gary says:
    October 24, 2013 at 3:19 pm

    There’s a good reason why (most) browsers show the xn— format only, and it’s to do with anti-phishing.
    The logic is, that only if you have that language installed anyway will you see the IDN format. If you don’t have that language installed in your browser, then in all likelihood you probably didn’t mean to navigate to that location as you couldn’t read the content anyway.

    Reply
    • Kevin Murphy says:
      October 24, 2013 at 3:33 pm

      That’s my understanding Gary.
      I have’t looked at it recently, but I think I remember prohibitions on mixing scripts that would help prevent the vast majority of phishing attacks in new gTLDs.
      It’s quite difficult to spell out a Latin word fully using characters from another script alone.

      Reply
      • Drewbert says:
        October 25, 2013 at 11:45 am

        Security-wise, the obvious thing to do would be to enforce same-script in the 2LD as whichever script is in the TLD. This would necessitate Verisign and PIR force-upgrading the current IDN.CNO domains to their transliterated IDNgTLD equivalents when they finally get delegated.
        ICANN doesn’t seem to agree, and SSAC has been deathly quiet about it. Allowing mixed scripts across the 2LD/TLD just seems bizarre, now that IDN gTLD’s are finally happening.

        Reply
    • Reg says:
      October 25, 2013 at 12:28 pm

      That’s a good theory, but at the end of the day, even though I can technically read ASCII, “nic.xn--80aswg” is likely to be just as incomprehensible than “nic.xn--8Oazwig”. See this article about the confusing similarity of “facebok” to “facebook”.

      Reply
      • Kevin Murphy says:
        October 25, 2013 at 12:34 pm

        I think Gary’s referring to the problem of a domain containing an IDN character that looks like an ASCII character.
        eg, pаypаl.tld (the things that look like A’s there are both Cyrillic characters)
        If the browser shows you an xn-- domain in the address bar, you’ll know you’re not really at paypal.tld.

        Reply
  3. Chris LaHatte says:
    October 25, 2013 at 9:30 am

    Now try putting an IDN on a whois query

    Reply
    • Drewbert says:
      October 25, 2013 at 12:32 pm

      whois version 5.0.26 running on Debian here – works perfectly well with unicode input for an IDN.com
      ALso, “whois рф.рф” produces the expected result, as does “whois ไทย.ไทย”
      The new gTLD’s don’t work. Probably need to wait for whois 5.0.27
      I could add them to /etc/whois.conf if I could figure out which database at iana.org tells you the WHOIS server for each TLD.

      Reply

Leave a Reply to Chris LaHatte

Click here to cancel reply.