Verisign offers free public DNS

Verisign has launched a free recursive DNS service aimed at the consumer market.
Public DNS, as the service is called, is being positioned as a way to avoid having your browsing history collated and sold for marketing purposes by your ISP.
There’s no charge, and the company is promising not to sell your data. It also does not plan to monetize NXDOMAIN traffic.
So what’s in it for Verisign? According to a FAQ:

One of Verisign’s core operating principles is to be a good steward of the Internet. Providing the Verisign Public DNS service supports the overall ecosystem of DNS and solidifies end-user trust in the critical navigation that they have come to depend upon for their everyday interactions.

Verisign also offers paid-for recursive DNS services to enterprises, so there may be an up-sell opportunity here.
The market for free public DNS currently has big players including Cisco’s OpenDNS and Google.
If you want to use the Verisign service, the IP addresses to switch to are 64.6.64.6 and 64.6.65.6.

.sexy may be blocked in Iran

Some networks in Iran appear to be systematically blocking Uniregistry’s .sexy gTLD.
That’s one of the conclusions of a slightly odd experiment commissioned by ICANN.
The newly published An Analysis of New gTLD Universal Acceptance was conducted by APNIC Labs. The idea was to figure out whether there are any issues with new gTLDs on the internet’s DNS infrastructure.
It concluded that there is not — new gTLDs work just fine on the internet’s plumbing.
However, the survey — which comprised over 100 million DNS resolution attempts — showed “One country, Iran, shows some evidence of a piecemeal block of Web names within the .sexy gTLD.”
The sample size for Iranian attempts to access .sexy was just 30 attempts. In most cases, users were able to resolve the names with DNS, but HTTP responses appeared to be blocked.
The survey did not test .porn or .adult names, but it might be safe to assume similar behavior in those gTLDs.
APNIC also concluded that Israel’s .il ccTLD, included in the report as a known example of TLD blocking at the national level, is indeed blocked in Iran and Syria.
The study also found that there may be issues with Adobe’s Flash software, when used in Internet Explorer, when it comes to resolving internationalized domain names.
That conclusion seems to have been reached largely because the test’s methodology saw a Flash advertisement discretely fetching URLs in the background of web pages using Google Ads.
When the experimenters used HTML 5 to run their scripts instead, there was no problem resolving the names.
The study did not look at some of the perhaps more pressing UA issues, such as the ability for registrants and others to use new gTLD domain names in web applications.

Blue Coat explains .zip screw-up

Security vendor Blue Coat apparently doesn’t check whether domains are actually domains before it advises customers to block them.
The company yesterday published a blog post that sought to explain why it denounced Google’s unlaunched .zip gTLD as “100% shady” even though the only .zip domain in existence leads to google.com.
Unrepentant, Blue Coat continued to insist that businesses should consider blocking .zip domains, while acknowledging there aren’t any.
It said that its censorware treats anything entered into a browser’s address bar as a URL, so it has been treating file names that end in .zip — the common format for compressed archive files — as if they are .zip domain names. The blog states:

when one of those URLs shows up out on the public Internet, as a real Web request, we in turn treat it as a URL. Funny-looking URLs that don’t resolve tend to get treated as Suspicious — after all, we don’t see any counter-balancing legitimate traffic there.
Further, if a legal domain name gets enough shady-looking traffic — with no counter-evidence of legitimate Web traffic — it’s possible for one of our AI systems to conclude that the behavior isn’t changing, and that it deserves a Suspicious rating in the database. So it gets one.

In other words, Blue Coat has been categorizing Zip file names that somehow find their way into a browser address bar as .zip domain names.
That may sound like a software bug that Blue Coat needs to fix, but it’s still telling people to block Google’s gTLD anyway, writing:

In conclusion, none of the .zip “domains” we see in our traffic logs are requests to registered sites. Nevertheless, we recommend that people block these requests, until valid .zip domains start showing up.

That’s a slight change of position from its original “Businesses should consider blocking traffic that leads to the riskiest TLDs”, but it still strikes me as irresponsible.
The company has still not disclosed the real numbers behind any of the percentages in its report, so we still have no idea whether it was fair to label, for example, Famous Four’s .review as “100% shady”.

Concern over mystery TMCH outage

The Trademark Clearinghouse is investigating the causes and impact of an outage that is believed to have hit its primary database for 10 hours last Friday.
Some in the intellectual property community are concerned that the downtime may have allowed people to register domain names without receiving Trademark Claims notices.
The downtime was confirmed as unscheduled by the TMCH on a mailing list, but requests for more information sent its way today were deflected to ICANN.
An ICANN spokesperson said that the outage is being analyzed right now, which will take a couple of days.
The problem affected the IBM-administered Trademark Database, which registrars query to determine whether they need to serve up a Claims notice when a customer tries to register a domain that matches a trademark.
I gather that registries are supposed to reject registration attempts if they cannot get a definitive answer from the TMDB, but some are concerned that that may not have been the case during the downtime.
Over 145,000 Claims notices have been sent to trademark owners since the TMCH came online over a year ago.
(UPDATE: This story was edited May 21 to clarify that it is the TMCH conducting the investigation, rather than ICANN.)

Site names and shames shoddy TLD support

A self-professed geek from Australia is running a campaign to raise awareness of new gTLDs by naming and shaming big companies that don’t provide comprehensive TLD support on their web sites.
SupportTheNew.domains, run by university coder Stuart Ryan, has been around since last June and currently indexes support problems at dozens of web sites.
The likes of Facebook, Amazon, Adobe and Apple are among those whose sites are said to offer incomplete support for new gTLDs.
It’s the first attempt I’m aware of to list “universal acceptance” failures in any kind of structured way.
Ryan says on the site that he set up the campaign after running into problems signing up for services using his new .email email address.
The site relies on submissions from users and seems to be updated whenever named companies respond to support tickets.
Universal acceptance is a hot topic in the new gTLD space, with ICANN recently creating a steering group to promote blanket TLD support across the internet.
Often, sites rely on outdated lists of TLDs or regular expressions that think TLDs are limited to three characters when they attempt to verify domains in email addresses or URLs.

Google eliminating domains from search results

Google has made another move to make domain names less relevant to internet users.
The company will no longer display URLs in search results pages for any web site that adopts a certain technical standard.
Instead, the name of the web site will be given. So instead of a DI post showing up with “domainincite.com” in results, it would be “Domain Incite”.
Google explained the change in a blog post incorrectly titled “Better presentation of URLs in search results”.
Webmasters wishing to present a company name or brand instead of a domain name need to publish metadata on their home pages. It’s just a few lines of code.
Google will make a determination whether to make the change based on whether the name meets these criteria:

Be reasonbly [sic] similar to your domain name
Be a natural name used to refer to the site, such as “Google,” rather than “Google, Inc.”
Be unique to your site—not used by some other site
Not be a misleading description of your site

Code samples and the rules are published here.
It strikes me that Google, by demanding naming uniqueness, is opening itself up for a world of hurt.
Could there be a landrush among non-unique brands? How will disputes be handled?
Right now the change has been made only to mobile search results and only in the US, but Google hinted that it could roll out elsewhere too.

More security issues prang ICANN site

ICANN has revealed details of a security problem on its web site that could have allowed new gTLD registries to view data belonging to their competitors.
The bug affected its Global Domains Division customer relationship management portal, which registries use to communicate with ICANN on issues related to delegation and launch.
ICANN took GDD down for three days, from when it was reported February 27 until last night, while it closed the hole.
The vulnerability would have enabled authenticated users to see information from other users’ accounts.
ICANN tells me the issue was caused because it had misconfigured some third-party software — I’m guessing the Salesforce.com platform upon which GDD runs.
A spokesperson said that the bug was reported by a user.
No third parties would have been able to exploit it, but ICANN has been coy about whether any it believes any registries used the bug to access their competitors’ accounts.
ICANN has ‘fessed up to about half a dozen crippling security problems in its systems since the launch of the new gTLD program.
Just in the last year, several systems have seen downtime due to vulnerabilities or attacks.
A similar kind of privilege escalation bug took down the Centralized Zone Data Service last April.
The RADAR service for registrars was offline for two weeks after being hacked last May.
A phishing attack against ICANN staff in December enabled hackers to view information not normally available to the public.

Why you can’t register emojis in gTLDs

The popular “emoji” smiley faces are banned as gTLD domain names for technical reasons, according to ICANN.
Emojis are a form of emoticon that originated on Japanese mobile networks but are now used by 12-year-old girls worldwide due to their support on Android and iPhone operating systems.
It emerged last week that Coca-Cola has registered a bunch of smiley-face domain names under .ws, the Samoan ccTLD, for use in an billboard advertising campaign in Puerto Rico.
.ws was selected because it’s one of only a few TLDs that allow emojis to be registered. Coke is spinning its choice of TLD as an abbreviation for “We Smile”.
This got me thinking: would emojis be something new gTLD registries could start to offer in order to differentiate themselves?
Coke’s emoji domains, it turns out, are just a form of internationalized domain name, like Chinese or Arabic or Greek.
Emoji symbols are in the Unicode standard and could therefore be converted to the ASCII-based, DNS-compatible Punycode under the hood in web browsers and other software.
One of Coke’s (smiley-face).ws domain names is represented as xn--h28h.ws in the DNS.
Unfortunately for gTLD registries, ICANN told DI last night that emojis are not permitted in gTLDs.
“Emoticons cannot be used as IDNs as these code points are DISALLOWED under IDNA2008 protocol,” ICANN said in a statement.
IDNA2008 is the latest version of the IETF standard used to define what Unicode characters can and cannot appear in IDNs.
RFC 5892 specifies what can be included in an IDNA2008 domain name, eliminating thousands of letters and symbols that were permissible under the old IDNA2003 standard.
These characters were ostensibly banned due to the possibility of IDN homograph attacks — when bad guys set up spoof web sites on IDNs that look almost indistinguishable from a domain used by, for example, a bank or e-commerce site.
But Unicode, citing Google data, reckons symbols could only ever be responsible for 0.000016% of such attacks. Most homograph attacks are much simpler, relying on for example the visual similarity of I and l.
Regardless, because IDNA2008 only allows Unicode characters that are actually used in spoken human languages, and because gTLD registries are contractually obliged to adhere to the IDNA2008 technical standards, emojis are not permitted in gTLDs.
All new gTLDs have to provide ICANN with a list of the Unicode code points they plan to support as IDNs when they undergo pre-delegation testing. Asking to support characters incompatible with IDNA2008 would result in a failed test, ICANN tells us.
ICANN does not regulate ccTLDs, of course, so the .ws registry is free to offer whatever domains it wants.
However, ICANN said that emoji domains are only currently supported by software that has not implemented the newer IDN protocol:

Emoticon domains only work in software that has not implemented the latest IDNA standard. Only the older, deprecated version of the IDNA standard allowed emoticons, more or less by accident. Over time, these domains will increasingly not work correctly as software vendors update their implementations.

So Coke, while winning brownie points for novelty, may have registered a bunch of damp squibs.
ICANN also told us that, regardless of what the technical standards say, you’d never be able to apply for an emoticon as a gTLD due to the “letters only” principle, which already bans numbers in top-level strings.

Group forms to stop new gTLDs breaking stuff

A little over a year into the live phase of the new gTLD program, a group of domain industry companies are getting together to make sure the expansion is supported across the whole internet.
A new Universal Acceptance Steering Group has formed, with the support of ICANN and the Domain Name Association, to help fix many of the compatibility problems facing new gTLD registrants today.
“The basic problem is that these new types of domains and email addresses just break stuff,” Google’s Brent London said during a UASG meeting at the ICANN meeting in Singapore last week.
“You try to use an internationalized domain or a long new gTLD, or even a short new gTLD, or certainly an internationalized email address and you’re likely to run into problems,” he said. “What we’re doing is going around asking developers to make their products work.”
Universal acceptance is a long-understood problem. Even 15 years after the approval of .info there are still web sites that validate email addresses by ensuring the TLD is no longer than three characters in length.
But the 2012 new gTLD round has brought the issue into sharper focus, particularly given the introduction of internationalized domain names, IDNs, which use non-Latin scripts.
Over the last year we’ve seen scattered examples of popular software — including browsers, instant messaging and social media apps — not recognizing new gTLD domains as domains. The problems I’ve seen are usually fixed quite quickly.
While I’ve not seen any deal-breakers that would prevent me registering a new gTLD domain, I gather that IDN email addresses are often basically unusable, due to the chain of dependencies involved in sending an email.
In my experience as a programmer, supporting all TLDs is not a particularly challenging problem when you’re coding something afresh.
However, when bad practices have been coded in to large, sprawling, interdependent systems over decades, it could be likened to the Y2K problem — the so-called Millennium Bug that caused developer headaches worldwide at the end of the last century.
There’s also a tonne of bad advice on the web, with coders telling other coders to validate domains in ways that do not support an expanding root.
UASG members think the problem is large-scale and that it’s a long-term project — 10 years or more — to fix it satisfactorily.
Members include Donuts, Google, Microsoft, Go Daddy and Afilias.
The DNA has started creating a repository of information for developers, with the aim of describing the problem in plain English and providing code samples. Along with other UASG members, there’s a plan to conduct outreach to make more people aware of the acceptance issue.
You can check out the repository in its unfinished state here.
ICANN is getting involved in a coordination role. After the UASG’s inaugural meeting in Washington DC a few weeks ago, ICANN hosted a session during ICANN 52.
It’s also hosting a mailing list and the group’s first conference call, which will take place tomorrow at 1600 UTC.

Comcast users report name collision bugs

US cable ISP Comcast has become the latest company to experience problems caused by name collisions with new gTLDs.
In this case the gTLD in question is .network, which Donuts had delegated at the end of August.
Users of Comcast’s Xfinity service have been complaining about various issues linked to collisions ever since.
It turns out some Xfinity hubs use the domain home.network on residential networks and that this default configuration choice was not corrected by Comcast before .network went live.
The collision doesn’t appear to be causing widespread internet access issues — Xfinity has close to 20 million users so we’d have heard about it if the problems were ubiquitous — some things appear to be failing.
I’ve seen multiple reports of users unable to access storage devices on their local networks, of being unable to run the popular TeamSpeak conferencing software used by gamers, problems with installing RubyGems, and errors when attempting to use remote desktop tools.
Judging by logs published by affected users, Donuts has been returning the domain “your-dns-needs-immediate-attention.network” and the IP address 127.0.53.53.
Anyone Googling for 127.0.53.53 — the IP address selected to ICANN’s “controlled interruption” name collision management plan — will currently find this ad:

Cyrus Namazi, vice president of DNS industry engagement at ICANN, confirmed to DI that ICANN has received multiple reports of issues on Comcast residential networks and that ICANN has been in touch with the ISP.
Comcast is working on a permanent fix, he said.
Namazi said that ICANN has not received any complaints from users of other ISPs. Most collision-related complaints have been filed by residential users rather than companies, he said.