Google starts supporting DNSSEC

Google has started fully supporting DNSSEC, the domain name security standard, on its Public DNS service.
According to a blog post from the company, while the free-to-use DNS resolution service has always passed on DNSSEC requests, now its resolvers will also validate DNSSEC signatures.
What does this mean?
Well, users of Public DNS will get protected from DNS cache poisoning attacks, but only for the small number of domains (such as domainincite.com) that are DNSSEC-signed.
It also means that if a company borks its DNSSEC implementation or key rollover, it’s likely to cause problems for Public DNS users. Comcast, an even earlier adopter, sees such problems pretty regularly.
But the big-picture story is that a whole bunch of new validating resolvers have been added to the internet, providing a boost to DNSSEC’s protracted global roll-out.
Google said:

Currently Google Public DNS is serving more than 130 billion DNS queries on average (peaking at 150 billion) from more than 70 million unique IP addresses each day. However, only 7% of queries from the client side are DNSSEC-enabled (about 3% requesting validation and 4% requesting DNSSEC data but no validation) and about 1% of DNS responses from the name server side are signed. Overall, DNSSEC is still at an early stage and we hope that our support will help expedite its deployment.

One has to wonder whether Google’s participation in the ICANN new gTLD program — with its mandatory DNSSEC at the registry level — encouraged the company to adopt the technology.

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

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.

Is .home back on ICANN’s new gTLD risk list?

While most new gTLD applicants were focused on delays to the program revealed during last Friday’s ICANN webinar, another bit of news may also be a cause for concern for .home applicants.
As Rubens Kuhl of Nic.br spotted, ICANN revealed that 11 applications have not yet passed their DNS Stability check.

That’s a reversal from November, when ICANN said that all new gTLD applications had passed the stability review.
As I noted at the time, that was good news for .home, which some say may cause security problems if it is delegated.
As Kuhl observed, there are exactly 11 applications for .home, the same as the number of applications that now appear to have un-passed the DNS Stability check.
So is ICANN taking a closer look at .home, or is it just a numerical coincidence?
The string is considered risky by many because .home already receives a substantial amount of DNS traffic at the root servers, which will be inherited by whichever company wins the contention set.
It’s on a list of frequently requested invalid TLDs produced by ICANN’s Security and Stability Advisory Committee which was incorporated by reference in the new gTLD Applicant Guidebook.
Some major ISPs, notably BT in the UK, use .home as a pseudo-TLD in their residential routers.

Who really uses IDNs? [Guest Post]

Are Internationalised Domain Names really useful, or just a way for an ASCII-focused internet governance community to feel better about itself?
Beyond all the hoopla about ICANN’s 2009 program to enable countries to operate their own non-Latin script internet suffixes (aka the “IDN ccTLD Fast Track”), what should really matter is the Internet user.
Yes, those sitting in ICANN meeting rooms at the time, listening to the hyperbole about how the internet was now going truly global probably felt like they were feeding the hungry and bringing peace to the world. But do people actually use IDNs?
I will admit that at the time, I was dubious. Of course, saying so in ICANN circles would have been akin to wearing a “Camembert is bad” t-shirt in the streets of Paris: poor form! But still, I couldn’t help ask myself if having a single one-language system unite the world was actually such a bad thing?
“How would you like it if the Internet had been invented in China and you had to use their alphabet,” was the usual rebuke I got if I ever dared to doubt out loud. And there really is no arguing with that. If the internet was Chinese, I’d want the Mandarin version of ICANN to roll out IDNs pretty sharpish.
Nonetheless, can the usefulness of IDNs still be questioned?
Facebook in Latin
Talking to a local internet expert whilst attending last week’s excellent Domain Forum in Sofia, Bulgaria, the answer would seem to be a surprising yes.
“Why would kids in this country use IDNs,” I was told when I suggested that, surely, Bulgaria must be excited about the prospect of natural language web addresses. “What worries the authorities here is the fact that kids are using Latin scripts so much on social media sites that they don’t even know how to write in Cyrillic anymore! So even if they could use IDN web and email addresses, why would they? They want to communicate like everyone else does on Facebook.”
In truth, Bulgaria’s view may be skewed by the horrible experience it’s had with ICANN’s IDN Fast Track. The country was refused its own IDN country code due to a perceived similarity with another TLD that no-one in Bulgaria really feels is warranted. But not all potential IDN users feel they are useless. Neighbors in Russia tell of a different IDN experience.
The Russian registry saw stunning initial take-up when it opened the IDN .РФ (.RF for Russian Federation) to general consumption on November 11, 2010. Registration volumes were explosive, with almost 600,000 names registered in the first month. Strong growth continued for a year, hitting a peak of 937,913 registered names in December 2011.
No profit
But the following month, that number fell off a cliff. Total registrations dropped to 844,153 in January 2012. “Initial registrations were driven in part by speculators,” explains ccTLD .RU’s Leonid Todorov. “But when people saw they couldn’t make huge profits on the domains, they started letting them go.”
Even so, .РФ remains a real success. Although November 2012 figures show a year on year decline of 8.63%, the TLD still sports a whopping 845,037 names.
At 66%, .РФ has a slightly lower renewal rate than ASCII Russian equivalent .ru (73%), probably because of those day-one speculators, but it remains widely used. Current delegation figures (i.e. the number of domain names that are actually used for email or websites) stand at a commendable 70% and have not stopped rising since .РФ opened in 2010 with a 45% delegation rate.
The Cyrillic Russian domain sees a vast predominance of personal use, with 77% percent of domains being registered by individuals. “Russians care deeply about their national identity,” says my Bulgarian friend when I suggest that IDNs do seem to matter in some Cyrillic-using countries. “To them, Dot RF is a matter of national pride.”
National pride
So IDNs may not really be all that different from ASCII domain names, with take-up depending on perceived use or value. Europe’s IDN experience seems to confirm this, as European registry EURid’s Giovanni Seppia explained in Sofia.
He revealed that since EURid introduced IDNs on December 11, 2009, registrations reached a peak of around 70,000 (a mere fraction of the 3.7 million names currently registered in the .eu space) before dropping off quite sharply.
Why? Well .eu IDNs may not hold much potential for real use or investment value for Europeans. Although web use is possible with IDNs, software primarily designed for an ASCII-only world does not always make it easy.
Email capability would be a real boost, but so far only the Chinese seem to have enabled it for their local script domains. The Chinese registry recently announced this, without giving details on how the use of all-Chinese character email addresses has been implemented or which email clients support IDNs.
Whatever the technology, countries which combine national pride and a character set far removed from our own probably see more desire for IDNs. With two years of hindsight, Russia obviously loves its IDN. And as other countries like China bring more elaborate IDN capabilities online, demand should grow and force even this IDN skeptic to recognize the new character(s) of the internet.
This is a guest post written by Stéphane Van Gelder, strategy director for NetNames. He has served as chair of the GNSO Council and is currently a member of ICANN’s Nominating Committee.

ICANN, Verisign and NTIA “ready for 100 new gTLDs per week”

The three main entities responsible for managing the domain name system’s root zone have confirmed that they’re ready to add 100 or more new gTLDs to the internet every week.
In a statement, (pdf), ICANN, Verisign and the US National Telecommunications & Information Administration jointly said:

Based on current staffing levels and enhancements that are currently underway to the [Root Zone Management] system, the Root Zone Partners are able to process at least 100 new TLDs per week and will commit the necessary resources to meet all root zone management volume increases associated with the new gTLD program.

The letter was sent in response to a request from ICANN’s Security and Stability Advisory Committee, which asked in July whether ICANN, Verisign and the NTIA were ready for the new gTLD load.
The three-party Root Zone Management procedure used to add TLDs or update existing ones is getting more automation, which is expected to streamline the process.

Trademark Clearinghouse “breakthrough” at private Brussels meeting

ICANN’s various stakeholder groups reached a “breakthrough” agreement on the Trademark Clearinghouse for new gTLDs, according to attendees at a closed-doors meeting last week.
The meeting in Brussels evidently saw attendance from members of the Business Constituency and Intellectual Property Constituency, in addition to the registries and registrars that have been involved in the development of the TMCH implementation model to date.
It was a discussion of nitty-gritty implementation details, according to attendees, rather than reopening the policy discussion on matters such as the mandatory Trademark Claims service period.
Crucially, ICANN appears to have dropped its strong objection to a community-developed proposal that would put the TMCH in the “critical path” for domain registrations.
The community proposal requires a centralized Clearinghouse serving Trademark Claims notices live rather than in a batch fashion, meaning up-time would be paramount.
Senior ICANN executives including chief strategy officer Kurt Pritz were adamant that this model would create an unacceptable single point of failure for the new gTLD program.
But CEO Fadi Chehade, who in Toronto last month appeared to disagree with Pritz, does not appear to have shared these concerns to the same deal-breaking extent.
In a blog post reviewing the meeting’s conclusions last night, Chehade wrote that the community has settled on a “hybrid” solution:

Participants reviewed the features of possible centralized and decentralized systems, and agreed to support a “hybrid” system for Trademark Claims. In this system, a file of domain name labels derived from the trademarks recorded in the Clearinghouse (and hence subject to a Claims Notice) would be distributed to all registries and updated on a regular basis, and a live query system would be used to retrieve the detailed data from the Clearinghouse when necessary to display the Claims Notice to a prospective registrant.

This description appears to closely match the community proposal (pdf) developed by the registries.
ARI Registry Services CTO Chris Wright, one of the key architects of the community TMCH proposal, made no mention of a “hybrid” solution in his update following the Brussels meeting.
According to Wright, “ICANN has tentatively agreed to proceed with the community-developed Trademark Clearinghouse”.
The meeting also concluded that there’s no way to provide blanket privacy protection for trademark data under Trademark Claims, something that has been worrying trademark holders for a while.
At a session in Toronto last month registries observed that the whole point of Trademark Claims is to provide information about trademarks to potential registrants.
That means it can be mined in bulk, and there’s not a heck of a lot registries can do to prevent that even with technical solutions such as throttling access.
Chehade blogged:

There was discussion on implementing an appropriate framework for access and use of the data. The group considered whether measures were necessary specifically to address potential mining of the Clearinghouse database for purposes other than to support the rights protection mechanisms. Given that the Trademark Clearinghouse is designed to provide trademark data for particular purposes, there was agreement that most controls would be ineffective in attempting to control data elements once provided to other parties.

So, how much community support do the Brussels agreements have?
The meeting was not webcast and there does not appear to be a recording or transcript, so it’s difficult to know for sure who was there, what was discussed or what conclusions were reached.
Concerns were expressed by members of the Non-Commercial Stakeholders Group, as well as the Internet Commerce Association, about the fact that ICANN did not widely publicize the meeting, which was first reported in an ICA blog post last week.
The ICA’s Phil Corwin also questioned whether key members of the IPC and BC — based on the US Eastern seaboard — would be able to attend due to Hurricane Sandy’s impact on air travel.
While there seems to be a feeling that solid progress on the Clearinghouse is definitely a positive development for the new gTLD program, the fact that the consensus was apparently reached behind closed doors does not appear to be in lockstep with Chehade’s commitment to increase transparency at ICANN.

ICANN looking for new gTLD testing provider on very tight deadline

ICANN is seeking one or more pre-delegation testing providers for its new gTLD program on a very ambitious timetable.
An RFP issued yesterday calls for a company that can scratch-build a testing suite to put new gTLD applicants through the ringer before they go live, and have it up and running by March 25, 2013.
Pre-delegation testing is the last stage of the new gTLD program’s approval process.
Some new gTLD applicants have recently called on ICANN to begin testing as soon as possible — before even Initial Evaluation has finished — in order to speed up time to market.
The Applicant Guidebook suggests that ICANN itself would be doing the testing, and some applicants had made that assumption, but that’s clearly not the case.
The RFP spells out exactly what is required of the testing providers.
First, they’re expected to build bespoke software to run the tests.
In addition to load-testing and verifying the registry’s compliance with standards such as EPP, DNSSEC and Whois, it also needs a custom-made user interface for applicants and back-end integration with ICANN’s wobbly TLD Application System.
ICANN also wants to be able to open-source the software, which seems to rule out any off-the-shelf testing suites.
RFP respondents also need to be able test 20 applicants’ back-ends per week — potentially scaling up to 100 per week — as soon as ICANN starts signing registry agreements next year.
ICANN does not expect to announce the winning provider(s) until December 5. The deadline for responses is November 20.
In short, it looks like a challenging project on a very tight deadline.
I wonder how much institutional knowledge there is out there of, say, DNSSEC, in companies that are not also involved in new gTLD applications as either applicant or back-end.
The pool of possible RFP respondents is likely very small indeed.
The ability to run tests on the testing suite itself may also be limited by the timetable and the possible shortage of guinea-pig registry back-ends.
Why ICANN has waited until this very late date to issue the RFP is a real head-scratcher.
ICANN is offering a 24-month contract with a possible 12-month extension. The RFP can be downloaded here.

Registries propose PKI-based new gTLD sunrises

Neustar and ARI Registry Services have come up with an alternative to ICANN’s proposed new gTLDs sunrise period process, based on a secure Public Key Infrastructure.
The concept was outlined in a draft paper published today, following an intensive two-day tête-à-tête between domain companies and Trademark Clearinghouse providers IBM and Deloitte last month.
It’s presented as an alternative to the implementation model proposed by ICANN, which would use unique codes and was criticized for being inflexible to the needs of new gTLD registries.
The PKI-based alternative from Neustar and ARI would remove some of the cost and complexity for registries, but may create additional file-management headaches for trademark owners.
Under the ICANN model, which IBM and Deloitte are already developing, each trademark owner would receive a unique code for each of their registered trademarks and each registry would be given the list of codes.
If a trademark owner wanted a Sunrise registration, it would submit the relevant code to their chosen registrar, which would forward it to the registry for validation against the list.
One of the drawbacks of this method is that registries don’t get to see any of the underlying trademark data, making it difficult to restrict Sunrise registrations to certain geographic regions or certain classes of trademark.
If, for example, .london wanted to restrict Sunrise eligibility to UK-registered trademarks, it would have no easy way of doing so using the proposed ICANN model.
But IP interests participating in the development of the Trademark Clearinghouse have been adamant that they don’t want registries and registrars getting bulk access to their trademark data.
They’re worried about creating new classes of scams and have competitive concerns about revealing their portfolio of trademarks.
Frankly, they don’t trust registries/rars not to misuse the data.
(The irony that some of the fiercest advocates of Whois accuracy are so concerned about corporate privacy has not been lost on many participants in the TMCH implementation process.)
The newly proposed PKI model would also protect trademark owners’ privacy, albeit to a lesser extent, while giving registries visibility into the underlying trademark data.
The PKI system is rather like SSL. It used public/private key pairs to digitally sign and verify trademark data.
Companies would submit trademark data to the Clearinghouse, which would validate it. The TMCH would then sign the data with its private key and send it back to the trademark owner.
If a company wished to participate in a Sunrise, it would have to upload the signed data — most likely, a file — to its registrar. The registrar or registry could then verify the signature using the TMCH’s public key.
Because the data would be signed, but not encrypted, registrars/ries would be able to check that the trademark is valid and also get to see the trademark data itself.
This may not present a privacy concern for trademark owners because their data is only exposed to registries and registrars for the marks they plan to register as domains, rather than in bulk.
Registries would be able to make sure the trademark fits within their Sunrise eligibility policy, and would be able to include some trademark data in the Whois, if that’s part of their model.
It would require more file management work by trademark owners, but it would not require a unique code for each gTLD that they plan to defensively register in.
The Neustar/ARI proposal suggests that brand-protection registrars may be able to streamline this for their clients by enabling the bulk upload of trademark Zip files.
The overall PKI concept strikes me as more elegant than the ICANN model, particularly because it’s real-time rather than using batch downloads, and it does not require the TMCH to have 100% availability.
ICANN is understandably worried that about the potentially disastrous consequences for the new gTLD program if it creates a TMCH that sits in the critical registration path and it goes down.
The PKI proposal for Sunrise avoids this problem, as registries and registrars only need a stored copy of the TMCH’s public key in order to do real-time validation.
Using PKI for the Trademark Claims service — the second obligatory rights protection mechanism for new gTLD launches — is a much trickier problem if ICANN is to stick to its design goals, however.
ARI and Neustar plan to publish their Trademark Claims proposal later this week. For now, you can read the Sunrise proposal in PDF format here.

Why domain names need punctuation

ICANN wants to know whether it should formally ban “dotless” domain names in the gTLDs for which it oversees policy.
While the Applicant Guidebook essentially prohibits registries using their new gTLDs without dots, there’s not yet a hard ban in the template Registry Agreement.
But that could change following a new ICANN public comment period.
A dotless domain might appear in a browser address bar as http://tld or, with more modern browsers, more likely just tld. A small number of ccTLDs already have this functionality.
To make it work, TLDs need to place an A record (or AAAA record for IPv6) in the root zone. This is known as an apex A record, which the Applicant Guidebook says ICANN will not permit.
The result, IANA root zone manager Kim Davies told us in July 2011, is a “default prohibition on dotless domains”.
Davies could not rule out apex A/AAAA records entirely, however. Specific requests for such functionality might be entertained, but would likely trigger an Extended Evaluation.
ICANN’s Security and Stability Advisory Committee is of the opinion that dotless gTLDs should not be permitted on various security grounds, including the fact that lots of software out there currently assumes a domain without a dot is a trusted host on the local network.
You can read the SSAC report here.
Dotless domains would also mess up browsers such as Chrome, which have integrated address/search bars; when you type “loreal” do you intend to search for the brand or visit its TLD’s web site?
But a far more intuitive, non-technical argument against dotless domains, as CentralNic’s Joe Alagna noted in his blog over the weekend, is that they do not pass the cocktail party test.
It’s hard enough trying to communicate the address “domainincite.com” across a noisy cocktail party as it is, but at least the dot immediately informs the listener that it’s a domain name.
Without dots, are we even talking about domain names any more?
The first phase of the new comment period runs until September 23. We understand that, depending on responses, a new ban on dotless domains could be introduced to the standard new gTLD registry agreement and possibly even added to legacy registry agreements in future.

DI PRO offers full-text new gTLD comment search

With ICANN today saying that it is “very inclined” to extend the public comment period on new gTLD applications, I thought it timely to announce a new feature for DI PRO subscribers.
If you’ve used ICANN’s web site to try to read some of the 4,000+ comments received to date, you might have noticed that it’s not always particularly easy to find what you’re looking for.
So I thought I’d write something a bit more functional.
These are some features of the new DI PRO new gTLD public comment search engine that I don’t think the ICANN site currently offers:
Search the full text of the comments. This is useful for, say, figuring out which comments discuss particular themes or issues, or are part of organized astroturf campaigns.
Search and sort by commenter affiliation. Want to see every comment filed by Tiffany or Lego or Heinz? If the commenter has disclosed his or her affiliation, you can do that.
Search by partial commenter name. There’s no need to remember the full name of the commenter you’re looking for. First name, last name, or just a few letters will suffice.
Search by alternate applicant name. The DI PRO database understands which applications originate from the likes of Google and Donuts and Famous Four Media, even if the application has been filed by a subsidiary with a different name.
The database is updated at least twice daily, rather than in real-time, so users may find a small delay between the time a comment appears on the ICANN site and the time it is indexed by DI.
Subscribers can start searching here.