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 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.
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.
A couple of weeks back, I emailed PR folk at Microsoft, Mozilla, Google and Opera, asking if they had any plans to provide native support for DNSSEC in their browsers.
As DNS uber-hacker Dan Kaminsky and ICANN president Rod Beckstrom have been proselytizing this week at the Black Hat conference, support at the application layer is the next step if DNSSEC is to quickly gain widespread traction.
The idea is that one day the ability to validate DNSSEC messages will be supported by browsers in much the same way as SSL certificates are today, maybe by showing the user a green address bar.
CZ.NIC has already created a DNSSEC validator plugin for Firefox that does precisely that, but as far as I can tell there’s no native support for the standard in any browser.
These are the responses I received:
Mozilla: “Our team is heads down right now with Firefox 4 beta releases so unfortunately, I am not going to be able to get you an answer.”
Microsoft: “At this stage, we’re focusing on the Internet Explorer 9 Platform Preview releases. The platform preview is a developer and designer scoped release of Internet Explorer 9, and is not feature complete, we will have more to share about Internet Explorer 9 in the future.”
Google: No reply.
Opera: No reply.
In 11 years of journalism, Apple’s PR team has never replied to any request for information or comment from me, so I didn’t bother even trying this time around.
But the responses from the other four tell us one of two things:
- Browser makers haven’t started thinking about DNSSEC yet.
- Their PR people were just trying to brush me off.
I sincerely hope it’s the former, otherwise this blog post has no value whatsoever.