You snooze, you lose new gTLD sunrise coming soon

Trademark attorneys and brand management executives take note: January 21 will see the launch of the first first-come, first-served sunrise period we’ve seen in a new TLD in a long time.
FCFS means that domain names will be allocated to participants immediately, rather than at the end of the sunrise period.
For those responsible for acquiring domain names for mark owners — many of whom are accustomed to waiting to the last minute before submitting sunrise applications — this is a change of pace.
You snooze, you lose.
To date only Regiodot’s German geographic gTLD, .ruhr, has officially confirmed (pdf) that it intends to use a FCFS policy during its mandatory sunrise period.
That’s due to kick off on January 21.
The precise time that the sunrise will begin — important when you’re looking at a FCFS policy — does not appear to have been published yet.
UPDATE: the time has been published (see comments below this post) and it’s 1000 UTC.
Under ICANN rules, to use FCFS registries need a “Start Date” sunrise, which runs for 30 days but requires a 30-day notice period before it begins. Regiodot told ICANN about its sunrise dates December 18.
The alternative “End Date” sunrises run for 60 days, have no notice period, and domains are only allocated to mark owners — usually using auctions to settle contention — after the 60 days are over.
Other than .ruhr, only PeopleBrowsr’s .ceo has said it wants to run a Start Date sunrise. However, PeopleBrowsr will not run its sunrise on a FCFS basis, preferring the end-date allocation/auction method instead.

Controlled interruption as a means to prevent name collisions [Guest Post]

This is a guest post written by Jeff Schmidt, CEO of JAS Global Advisors LLC. JAS is currently authoring a “Name Collision Occurrence Management Framework” for the new gTLD program under contract with ICANN.
One of JAS’ commitments during this process was to “float” ideas and solicit feedback. This set of thoughts poses an alternative to the “trial delegation” proposals in SAC062. The idea springs from past DNS-related experiences and has an effect we have named “controlled interruption.”
Learning from the Expired Registration Recovery Policy
Many are familiar with the infamous Microsoft Hotmail domain expiration in 1999. In short, a Microsoft registration for passport.com (Microsoft’s then-unified identity service) expired Christmas Eve 1999, denying millions of users access to the Hotmail email service (and several other Microsoft services) for roughly 20 hours.
Fortunately, a well-intended technology consultant recognized the problem and renewed the registration on Microsoft’s behalf, yielding a nice “thank you” from Microsoft and Network Solutions. Had a bad actor realized the situation, the outcome could have been far different.
The Microsoft Hotmail case and others like it lead to the current Expired Registration Recovery Policy.
More recently, Regions Bank made news when its domains expired, and countless others go unreported. In the case of Regions Bank, the Expired Registration Recovery Policy seemed to work exactly as intended – the interruption inspired immediate action and the problem was solved, resulting in only a bit of embarrassment.
Importantly, there was no opportunity for malicious activity.
For the most part, the Expired Registration Recovery Policy is effective at preventing unintended expirations. Why? We call it the application of “controlled interruption.”
The Expired Registration Recovery Policy calls for extensive notification before the expiration, then a period when “the existing DNS resolution path specified by the Registrant at Expiration (“RAE”) must be interrupted” – as a last-ditch effort to inspire the registrant to take action.
Nothing inspires urgent action more effectively than service interruption.
But critically, in the case of the Expired Registration Recovery Policy, the interruption is immediately corrected if the registrant takes the required action — renewing the registration.
It’s nothing more than another notification attempt – just a more aggressive round after all of the passive notifications failed. In the case of a registration in active use, the interruption will be recognized immediately, inspiring urgent action. Problem solved.
What does this have to do with collisions?
A Trial Delegation Implementing Controlled Interruption
There has been a lot of talk about various “trial delegations” as a technical mechanism to gather additional data regarding collisions and/or attempt to notify offending parties and provide self-help information. SAC062 touched on the technical models for trial delegations and the related issues.
Ideally, the approach should achieve these objectives:

• Notifies systems administrators of possible improper use of the global DNS;
• Protects these systems from malicious actors during a “cure period”;
• Doesn’t direct potentially sensitive traffic to Registries, Registrars, or other third parties;
• Inspires urgent remediation action; and
• Is easy to implement and deterministic for all parties.

Like unintended expirations, collisions are largely a notification problem. The offending system administrator must be notified and take action to preserve the security and stability of their system.
One approach to consider as an alternative trial delegation concept would be an application of controlled interruption to help solve this notification problem. The approach draws on the effectiveness of the Expired Registration Recovery Policy with the implementation looking like a modified “Application and Service Testing and Notification (Type II)” trial delegation as proposed in SAC62.
But instead of responding with pointers to application layer listeners, the authoritative nameserver would respond with an address inside 127/8 — the range reserved for localhost. This approach could be applied to A queries directly and MX queries via an intermediary A record (the vast majority of collision behavior observed in DITL data stems from A and MX queries).
Responding with an address inside 127/8 will likely break any application depending on a NXDOMAIN or some other response, but importantly also prevents traffic from leaving the requestor’s network and blocks a malicious actor’s ability to intercede.
In the same way as the Expired Registration Recovery Policy calls for “the existing DNS resolution path specified by the RAE [to] be interrupted”, responding with localhost will hopefully inspire immediate action by the offending party while not exposing them to new malicious activity.
If legacy/unintended use of a DNS name is present, one could think of controlled interruption as a “buffer” prior to use by a legitimate new registrant. This is similar to the CA Revocation Period as proposed in the New gTLD Collision Occurrence Management Plan which “buffers” the legacy use of certificates in internal namespaces from new use in the global DNS. Like the CA Revocation Period approach, a set period of controlled interruption is deterministic for all parties.
Moreover, instead of using the typical 127.0.0.1 address for localhost, we could use a “flag” IP like 127.0.53.53.
Why? While troubleshooting the problem, the administrator will likely at some point notice the strange IP address and search the Internet for assistance. Making it known that new TLDs may behave in this fashion and publicizing the “flag” IP (along with self-help materials) may help administrators isolate the problem more quickly than just using the common 127.0.0.1.
We could also suggest that systems administrators proactively search their logs for this flag IP as a possible indicator of problems.
Why the repeated 53? Preserving the 127.0/16 seems prudent to make sure the IP is treated as localhost by a wide range of systems; the repeated 53 will hopefully draw attention to the IP and provide another hint that the issue is DNS related.
Two controlled interruption periods could even be used — one phase returning 127.0.53.53 for some period of time, and a second slightly more aggressive phase returning 127.0.0.1. Such an approach may cover more failure modes of a wide variety of requestors while still providing helpful hints for troubleshooting.
A period of controlled interruption could be implemented before individual registrations are activated, or for an entire TLD zone using a wildcard. In the case of the latter, this could occur simultaneously with the CA Revocation Period as described in the New gTLD Collision Occurrence Management Plan.
The ability to “schedule” the controlled interruption would further mitigate possible effects.
One concern in dealing with collisions is the reality that a potentially harmful collision may not be identified until months or years after a TLD goes live — when a particular second level string is registered.
A key advantage to applying controlled interruption to all second level strings in a given TLD in advance and at once via wildcard is that most failure modes will be identified during a scheduled time and before a registration takes place.
This has many positive features, including easier troubleshooting and the ability to execute a far less intrusive rollback if a problem does occur. From a practical perspective, avoiding a complex string-by-string approach is also valuable.
If there were to be a catastrophic impact, a rollback could be implemented relatively quickly, easily, and with low risk while the impacted parties worked on a long-term solution. A new registrant and associated new dependencies would likely not be adding complexity at this point.
Request for Feedback
As stated above, one of JAS’ commitments during this process was to “float” ideas and solicit feedback early in the process. Please consider these questions:

• What unintended consequences may surface if localhost IPs are served in this fashion?
• Will serving localhost IPs cause the kind of visibility required to inspire action?
• What are the pros and cons of a “TLD-at-once” wildcard approach running simultaneously with the CA Revocation Period?
• Is there a better IP (or set of IPs) to use?
• Should the controlled interruption plan described here be included as part of the mitigation plan? Why or why not?
• To what extent would this methodology effectively address the perceived problem?
• Other feedback?

We anxiously await your feedback — in comments to this blog, on the DNS-OARC Collisions list, or directly. Thank you and Happy New Year!

New gTLD launches: registrar coverage at less than 40% of the market

Registrars representing less than 40% of the gTLD market are ready to offer new gTLDs during their launch phases, according to the latest stats from ICANN.
ICANN released yesterday a list (pdf) of the just 21 registrars that have signed the 2013 Registrar Accreditation Agreement and have been certified by IBM to use the Trademark Clearinghouse database.
Signing the 2013 RAA is a requirement for registrars that want to sell new gTLDs. Almost 150 registrars are currently on the new contract.
But being certified for the TMCH is also a requirement to sell names during the first 90 days of each new gTLD’s general availability, when the Trademark Claims service is running.
Together, the 21 registrars that have done both accounted for 59 million registered gTLD domain names (using August’s official numbers), which translated to 39.5% of the gTLD market.
It’s a high percentage due to the presence of Go Daddy, with its 48.2 million gTLD names. The only other top-10 registrar on the list is 1&1.
Twelve of the 21 registrars on the list had fewer than 40,000 names under management. A couple have fewer than 100.
Only one new gTLD, dotShabaka Registry’s شبكة., is currently in its Trademark Claims period.
The second batch, comprising Donuts’ first seven launches, isn’t due to hit until January 27, giving just a few weeks for the certified list to swell.
There’ll be 33 new gTLD in Claims by the end of February.
The rate at which new registrars are being certified by IBM is not especially encouraging either. Only four have been added in the last month.
Some registrars may of course choose to work via other registrars, as a reseller, rather than getting certified and doing the TMCH integration work themselves.

Latest Go Daddy phishing attack unrelated to 2013 RAA

Fears that the 2013 Registrar Accreditation Agreement would lead to new phishing attacks appear to be unfounded, at least so far.
The 2013 RAA, which came into force at most of the big registrars on January 1, requires registrars to verify the registrant’s email address or phone number whenever a new name is registered.
It was long predicted that this new provision — demanded by law enforcement — would lead to phishers exploiting registrant confusion, obtaining login credentials, and stealing valuable domain names.
Over the weekend, it looked like this prediction had come true, with posts over at DNForum saying that a new Go Daddy scam was doing the rounds and reports that it was related to the 2013 RAA changes.
I disagree. Shane Cultra posted a screenshot of the latest scam on his blog, alongside a screenshot of Go Daddy’s actual verification email, and the two are completely dissimilar.
The big giveaways are the “Whois Data Reminder” banner and “Reminder to verify the accuracy of Whois data” subject line.
The new attack is not exploiting the new 2013 RAA Whois verification requirements, it’s exploiting the 10-year-old Whois Data Reminder Policy, which requires registrars annually to remind their customers to keep their contact details accurate.
In fact, the language of the new scam has been used in phishing attacks against registrants since at least 2010.
That’s not to say the attack is harmless, of course — the attacker is still going to steal the contents of your Go Daddy account if you fall for it.
We probably will see attacks specifically targeting confusion about the new address verification policy in future, but it seems to me that the confusion we’re seeing with the latest scam may be coincidental.
Go Daddy told DI yesterday that the scam site in question had already been shut down. It’s not clear if anyone fell for it while it was live.

Vienna is the first city with its own TLD

The world’s first city gTLD, .wien, went live on the internet this morning.
It’s the TLD for what the English-speaking world calls Vienna, the Austrian capital.
While its nic.wien starter page doesn’t seem to be resolving yet, .wien itself is in the DNS root zone file.
punkt.wien, the new registry, said in its application that .wien names will be restricted to anyone who “can demonstrate that they have an economic, cultural, historical, social or any other connection” to Vienna.
The same test will apply to the use of .wien names — the registry plans to review the content of sites under the gTLD from time to time to ensure compliance.
The policy appears to be modeled somewhat on the .cat geo-gTLD.
According to the .wien application, about a quarter of the Austrian population lives in its environs, giving the gTLD a market of about 1.7 million people.
The registry is planning to launch properly in March, according to its web site.
While it’s the first city gTLD to go live, it isn’t the first geo to hit the root in this round — that honor belongs to .ruhr, which represents a German state.
(Note: Laos’ ccTLD, .la, is often marketed as a city TLD for Los Angeles, but it’s not quite the same thing.)

.email and two other new gTLDs go live

Three more new gTLDs were delegated this afternoon, including the potentially interesting .email.
The other two were TLD Registry’s .在线 (Chinese for ‘.online’) and United TLD/Rightside’s .immobilien (German for ‘.realestate’).
The reason I think .email could be interesting is that it’s very close to “.mail”, which has been highlighted in several analyses as a potentially dangerous due to the risk of name collisions.
It’s also, I think, one of the highlights of Donuts’ portfolio, despite the fact that the company was the only applicant.
.immobilien is the third delegated gTLD for United TLD. It’s going to be competing against the arguably more attractive .immo — a well-known abbreviation — which is currently contested by four applicants.
For TLD Registry, .在线 is the first delegation. It’s planning to take both .在线 and its companion .中文网 (“Chinese website”) to Sunrise on January 17, so we might expect another delegation soon.

.ninja springs to life as a squirrel as 19 new gTLDs get delegated

ICANN may be taking Christmas week off, but Verisign apparently isn’t — another 19 new gTLDs were delegated to the DNS root system last night.
Most belong to Donuts: .training, .builders, .coffee, .codes, .education, .florist, .farm, .glass, .house, .holiday, .international, .institute, .solar, .repair and .solutions.
United TLD, the Demand Media/Rightside business that is also providing Donuts’ back-end, had .ninja and .kaufen (German for “buy”) delegated.
PeopleBrowsr’s .ceo also went live, as did I-REGISTRY’s .onl (for “online”).
Donuts is already redirecting its latest batch of nic.[tld] domains to donuts.co.
The web site at nic.ninja currently shows this image as part of a placeholder page:

UPDATE: It occurs to me that this might actually be a prairie dog or something, rather than a squirrel.

ICANN has spent $120 million on new gTLDs

The new gTLD program has cost ICANN almost $120 million so far, according to a quarterly financial report published earlier this week.
It’s the first time ICANN has published a quarterly statement. Normally it only files a formal report annually.
According to the report, ICANN has spent $119.2 million of its original £344.9 million program budget (which comprises application fees net of refunds).
As of September 30, it still had $225.7 million in cash dedicated to the program, which is accounted for separate to ICANN’s regular operating budget.
ICANN estimates its total spend will be $204.3 million. If you factor in the $108.9 million “risk reserve”, that would put the program $3 million over budget by the time it concludes.
None of this includes the likely proceeds of contention set auctions, which are expected to amount to many millions. This cash will also be accounted for separately, but the community discussion on how to spend it is only just beginning.

Uniregistry plans “dot-spanning” Sunrise periods and anti-gaming protection

Uniregistry is to offer a second Sunrise period in its new gTLDs, going over and above what is required by ICANN, aimed at companies with trademarks that “span the dot”.
Say you run a tattoo parlor and have a trademark on “Joe’s Tattoo”. The ICANN-mandated Sunrise would only allow you to register joestattoo.tattoo, but Uniregistry will allow you to buy joes.tattoo as well.
It would also allow “plurals and conjugations”, so a company with a trademark on “Joe’s Tattoos” would presumably also be eligible for joes.tattoo, even though they’re not an exact match.
This Sunrise B plan appears to apply to all of Uniregistry’s forthcoming gTLDs and was approved by ICANN recently (pdf).
The additional service would be invitation-only, restricted to companies that have participated in the regular Sunrise period, which Uniregistry is calling Sunrise A.
For Sunrise A, Uniregistry plans to allow mark owners to register regular resolving domain names or purchase “blocking” registrations, where the domain resolves to a non-monetized Uniregistry placeholder.
Sunrise B participants would not be able to purchase blocking registrations; for “dot-spanning” trademarks the name must resolve.
Uniregistry also plans to implement an “anti-hijack” measure to help prevent — or at least add friction to — .eu-style gaming by domain speculators during its launch periods.
If you participate in either Sunrise period, you won’t be able to later transfer your name to a third party without providing the registry with proof that you’ve also transferred the corresponding trademark registration.

Applicant says .islam ban would damage ICANN

If ICANN decides to reject Asia Green IT’s applications for .islam and .halal it would “be dealing a blow to the new gTLD program’s credibility”, according to AGIT.
The two potential new gTLDs are currently in limbo, awaiting a decision by the ICANN’s board of directors’ New gTLD Program Committee, following stalemate within the Governmental Advisory Committee.
The Organization for Islamic Cooperation has objected to the applications, saying it represents 1.6 billion Muslims and that it’s “concerned” about the potential “misuse” of the names.
Mehdi Abbasnia, managing director of the Turkey-based company, recently wrote to ICANN too (pdf) to ask that ICANN speedily approve its applications, given that two formal OIC-backed Community Objections have already failed.
Abbasnia also wrote to DI on Friday (pdf) to reiterate many of the same points.
The two gTLDs are among only a handful originating it the Muslim world, he said, and the idea is to spur adoption of domain names among all Muslims.

Muslim communities the world over have a lot to gain from seeing their members empowered through namespaces that are better suited to their specific needs, easier for them to relate to and use and respectful of their culture and laws.
As Muslims ourselves, this is what we felt we could bring to our community when we first heard of the new gTLD program: our expertise as a technical enabler of TLDs by Muslims, for Muslims. We are looking to fuel the engine, not drive the car.

He added that AGIT prevailed in the objections filed against it, and the GAC failed to reach a consensus to object.

Some in ICANN circles have used the phrase “taking a second bite at the apple” to characterize attempts to overturn decisions and derail processes. In the case of our applications for .Halal and .Islam, the apple’s been eaten to the core!
…
The ball is now in the ICANN Board’s court. If it bows to the OIC’s pressure and blocks our TLD applications, not only will Muslims the world over be prevented from claiming their very own space on the Internet, but I believe it will also be dealing a blow to the new gTLD program’s credibility, and to the credibility of ICANN as a multi-stakeholder governance organization.

While I have no opinion on whether the two applications should be approved or not, I disagree with the apple metaphor.
AGIT is in receipt of formal “GAC Advice on New gTLDs” explaining a non-consensus objection. That’s clearly envisaged by the Applicant Guidebook, and there a process for dealing with it: ICANN’s board talks to the GAC to understand the extent of its members’ concerns and then explains itself after it makes a decision one way or the other.
There doesn’t seem to be an abuse of process by the OIC or GAC here, just a very tricky question for the ICANN board to answer.