Latest news of the domain name industry

Recent Posts

Apple, Google and Microsoft still don’t understand new TLDs

Kevin Murphy, January 22, 2013, 13:56:03 (UTC), Domain Tech

The world’s most-popular web browsers are still failing to recognize new top-level domains, many months after they go live on the internet.
The version of the Safari browser that ships with the Mountain Lion iteration of Apple’s OS X appears to have even gone backwards, removing support for at least one TLD.
The most recent versions of Google’s Chrome and Microsoft’s Internet Explorer also both fail to recognize at least two of the internet’s most recently added TLDs.
According to informal tests on multiple computers this week, Safari 6 on Mountain Lion and the Windows 7 versions of Internet Explorer 9 and Chrome v24 all don’t understand .post and .cw addresses.
Remarkably, it appears that Safari 6 also no longer supports .sx domains, despite the fact that version 5 does.
Typing affected domain names into the address bars of these browsers will result in surfers being taken to a search page (usually Google) instead of their intended destination.
If you want to test your own browser, registry.sx, una.cw and ems.post are all valid, resolving domain names you can try.
The gTLD .post was entered into the DNS root last August and the first second-level domain names went live in October.
The ccTLDs .sx and .cw are for Sint Maarten (Dutch part) and Curacao respectively, two of three countries formed by the breakup of the Netherlands Antilles in 2010.
ICANN approved the delegation of .cw in October 2011 and second-level domains there have been live since at least July 2012 (that’s when the registry’s site, una.cw, went live).
SX Registry’s .sx was delegated in December 2011 and sites there have been live since early 2012. It went into general availability in November.
Safari v5 on Windows and OS X recognizes .sx as a TLD, but v6 on Mountain Lion does not.
The problems faced by .post and .cw on Chrome appear to be mostly due to the fact that neither TLD is included on the Public Suffix List, which Google uses to figure out what a TLD looks like.
A few days after we reported last May that .sx didn’t work on Chrome, SX Registry submitted its details to the PSL, which appears to have solved its problems with that browser.
It’s not at all clear to me why .sx is borked on newer versions of Safari but not the older ones.
If the problem sounds trivial, believe me: it’s not.
The blurring of the lines between search and direct navigation is one of the biggest threats to the long-term relevance of domain names, so it’s vital to the industry’s interests that the problem of universal acceptance is sorted out sooner rather than later.

Tagged: , , , , , , , , , , ,

Comments (12)

  1. Andrew says:
    January 22, 2013 at 2:11 pm

    Your last paragraph is the key. Google would rather have you show up in its search engine than go directly to the web site. It can’t do that for all TLDs or people would switch browsers, but missing some of them is beneficial to its business model

    Reply
  2. Ed says:
    January 22, 2013 at 4:38 pm

    Strangely, any mention of Firefox (since when is IE more popular than FF?) is missing in the article, as well as the info that PSL is run by Mozilla.
    Biased, eh?

    Reply
    • Kevin Murphy says:
      January 22, 2013 at 4:50 pm

      I didn’t mention Firefox because Firefox doesn’t have any problems. I could do a paragraph listing all the software that isn’t affected by the problem but it would be a bloody big paragraph.

      Reply
  3. Kal says:
    January 22, 2013 at 11:04 pm

    una.cw is mis-configured. The apex A record points to its DNS server instead of the web forwarding service that http://www.una.cw points to. IE and chrome work with http://www.una.cw.

    Reply
  4. Nigel Roberts says:
    January 23, 2013 at 6:29 pm

    .GG and .JE still occasionally see these sorts of problems even though we started resolving in the root in 1996.
    It’s caused by incompetent coders. Instead of prejudging and hardcoding what a valid TLD MIGHT be, how about checking to see if the DNS resolves instead.
    If later generations of mechanical engineers didn’t take on board what previous generations learned the hard way, buildings and bridges would keep falling down.
    So why can’t software engineers do the same?

    Reply
  5. Tobias Sattler says:
    January 25, 2013 at 2:53 pm

    I think the problem is the Public Suffix List, because browsers like Chrome and Safari only have a combined navigation and search bar. Therefore they need a hint if it is a domain name or a search string. So I checked the Public Suffix List and saw that there were missing .cw and also many second level domain names. I created a diff file for them. Today I got respone: “Thank you for your patch! This is a long list for changes, we’ll need a little bit of time to go through all of them and apply those applicable. I’ll keep you posted.”. Let’s see what’s going to happen. I hope they are not going to reject it because of: “Please note that all emails must come from an address in your registry’s official domain, otherwise they will be rejected.”

    Reply
    • Kevin Murphy says:
      January 25, 2013 at 2:59 pm

      Wow. Good work.
      I think the PSL requires “official” emails because it doesn’t just list the fact that the TLD exists, but also the levels at which domains are registerable (eg, co.uk) . They would need official confirmation from the registry in order to provide authoritative information.

      Reply
      • Tobias Sattler says:
        January 25, 2013 at 4:02 pm

        Well, I think so too. Still, I hope they will at least look through the changes I made. I was also thinking about parsing the IANA registry contacts to send the technical contacts an email with a diff file of their TLD and a short explanation what to do, but I canceled it. It would have been a pain to keep track of the changes.

        Reply
  6. Tin says:
    March 19, 2013 at 4:36 am

    This problem is one of 2 reasons why I refuse to use Chrome. Sure it might be faster at rendering, but that’s somewhat negated by the time it takes me to retype the address with “http://” on front if it decides it’s not real.
    Clue for browser developers – If the text looks like “nnn.nnn.nnn.nnn” it’s an IP address. If it looks like “xxxxx.yyyyy” then it MIGHT be a DNS hostname and should be resolved before trying a search.

    Reply
  7. Tobias Sattler says:
    June 7, 2013 at 9:32 am

    After almost 6 month Mozilla is considering my update to the public suffix list. Let’s see how it will turn out.
    https://bugzilla.mozilla.org/show_bug.cgi?id=880625

    Reply

Leave a Reply to Nigel Roberts

Click here to cancel reply.