Latest news of the domain name industry

Recent Posts

Comcast users report name collision bugs

Kevin Murphy, September 23, 2014, Domain Tech

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.

New gTLD registries given way to free up millions of blocked names

Kevin Murphy, February 27, 2014, Domain Tech

Up to 9.8 million new gTLD domain names are to get a get-out-of-jail card, with the publication yesterday of ICANN’s plan to mitigate the risk of damaging name collisions.

As a loyal DI reader, the details of the plan will not come as a great surprise. It was developed by JAS Global Advisors and previewed in a guest post by CEO Jeff Schmidt in January

Name collisions are scenarios where a TLD delegated by ICANN to the public DNS matches a TLD that one or more organizations already uses on their internal networks.

Verisign, in what many view as protectionist propaganda, has been arguing that name collisions could cause widespread technical and economic damage and even a risk to life.

Things might stop working and secret data might leak out of corporate networks, Verisign warns.

JAS’ proposed solution, which ICANN has opened for public comment, is quite clever, I think.

Called “controlled interruption”, it will see new gTLD registries being asked to wildcard their entire second level of their TLDs to point to the IP address 127.0.53.53.

If there’s a name collision on example.corp the company using that TLD on its network will notice unusual behavior and will have an opportunity to fix the problem.

Importantly, no data apart from the DNS look-up will leak out of their networks — the 127/8 IP address block is reserved by various standards for local uses only.

The registry will essentially bounce the DNS request back to the network making the request. If that behavior causes problems, the network administrator will presumably check her logs, notice the odd IP address, and Google it for further information.

Today, she’ll find a Slashdot article about the name collisions plan, which should put the admin on the road to figuring out the problem and fixing her network. In future, maybe ICANN will rank for the term.

Registries would be able to choose whether to wildcard their whole TLD or to only point to 127.0.53.53 those second-level names currently on their collisions block lists.

In either case, the redirection would only last for the first 120 days after delegation. That’s the same duration as the quiet period ICANN already imposes on new delegations, during which only “nic.” may resolve.

After the 120 days are up, the name collisions issue would be considered permanently closed for that TLD.

If this goes ahead, the plan will allow registries to unblock as many as 9.8 million domain names representing 6.8 million unique second-level labels, according to DI PRO collisions database.

It could also put an end to the argument about whether name collisions really were a significant problem (160,000 new gTLD names are already live and we haven’t heard any reports of collisions yet).

Pointing to the fact that new TLDs, some of which showed evidence of collisions, were getting delegated rather regularly before the current new gTLD round, JAS said in its report:

We do not find that the addition of new Top Level Domains (TLDs) fundamentally or significantly increases or changes the risks associated with DNS namespace collisions. The modalities, risks, and etiologies of the inevitable DNS namespace collisions in new TLD namespaces will resemble the collisions that already occur routinely in the other parts of the DNS.

However…

Collisions in all TLDs and at all levels within the global Internet DNS namespace have the ability to expose potentially serious security and availability problems and deserve serious attention.

JAS calls its plan “a conservative buffer between potential legacy usage of a TLD and the new usage”.

As wildcarding is currently prohibited by ICANN’s standard Registry Agreement (ironically, to prevent a repeat of Verisign’s Site Finder) an amendment is going to be needed, as the JAS plan acknowledges.

The drawback of the plan is that if an organization is relying on a colliding internal TLD, whatever systems use that TLD could break under the plan. The 127/8 redirection is a way to help them resolve the breakage, not always to prevent it happening at all.

For new gTLD registries it’s pretty good news, however. There are many thousands of potentially valuable premium names blocked under the current regime that would be made available for sale.

If you’re an applicant for .mail, however, it’s a different story. The JAS report says .mail should be reserved forever, putting it in the same category as .home and .corp:

the use of .corp and .home for internal namespaces/networks is so overwhelming that the inertia created by such a large “installed base” and prevalent use is not likely reversible. We also note that RFC 6762 suggests that .corp and .home are safe for use on internal networks.

Like .corp and .home, the TLD .mail also exhibits prevalent, widespread use at a level materially greater than all other applied-for TLDs. Our research found that .mail has been hardcoded into a number of installations, provided in a number of example configuration scripts/defaults, and has a large global “installed base” that is likely to have significant inertia comparable to .corp and .home. As such, we believe .mail’s prevalent internal use is also likely irreversible and recommend reservation similar to .corp and .home.

In other words, .mail is dead and the five remaining applicants for the string are probably going to be forced to withdraw through no fault of their own. Should these companies get a full refund from ICANN?

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

Jeff Schmidt, January 8, 2014, Domain Tech

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!

DNS Namespace Collisions: Detection and Response [Guest Post]

Jeff Schmidt, November 28, 2013, Domain Tech

Those tracking the namespace collision issue in Buenos Aries heard a lot regarding the potential response scenarios and capabilities. Because this is an important, deep, and potentially controversial topic, we wanted to get some ideas out early on potential solutions to start the conversation.

Since risk can almost never be driven to zero, a comprehensive approach to risk management contains some level of a priori risk mitigation combined with investment in detection and response capabilities.

In my city of Chicago, we tend to be particularly sensitive about fires. In Chicago, like in most cities, we have a priori protection in the form of building codes, detection in the form of smoke/fire alarms, and response in the form of 9-1-1, sprinklers, and the very capable Chicago Fire Department.

Let’s think a little about what the detection and response capabilities might look like for DNS namespace collisions.

Detection: How do we know there is a problem?

Rapid detection and diagnosis of problems helps to both reduce damage and reduce the time to recovery. Physical security practitioners invest considerably in detection, typically in the form of guards and sensors.

Most meteorological events are detected (with some advance warning) through the use of radars and predictive modeling. Information security practitioners are notoriously light with respect to systematic detection, but we’re getting better!

If there are problematic DNS namespace collisions, the initial symptoms will almost certainly appear through various IT support mechanisms, namely corporate IT departments and the support channels offered by hardware/software/service vendors and Internet Service Providers.

When presented with a new and non-obvious problem, professional and non-professional IT practitioners alike will turn to Internet search engines for answers. This suggests that a good detection/response investment would be to “seed” support vendors/fora with information/documentation about this issue in advance and in a way that will surface when IT folks begin troubleshooting.

We collectively refer to such documentation as “self-help” information. ICANN has already begun developing documentation designed to assist IT support professionals with namespace-related issues.

In the same way that radar gives us some idea where a meteorological storm might hit, we can make reasonable predictions about where issues related to DNS namespace collisions are most likely to first appear.

While problems could appear anywhere, we believe it is most likely that scenarios involving remote (“road warrior”) use cases, branch offices/locations, and Virtual Private Networks are the best places to focus advance preparation.

This educated guess is based on the observation that DNS configurations in these use cases are often brittle due to complexities associated with dynamic and/or location-dependent parameters. Issues may also appear in Small and Medium-sized Enterprises (SMEs) with limited IT sophistication.

This suggests that proactively reaching out to vendors and support mechanisms with a footprint in those areas would also be a wise investment.

Response: Options, Roles, and Responsibilities

In the vast majority of expected cases, the IT professional “detectors” will also be the “responders” and the issue will be resolved without involving other parties. However, let’s consider the situations where other parties may be expected to have a role in response.

For the sake of this discussion, let’s assume that an Internet user is experiencing a problem related to a DNS namespace collision. I use the term “Internet user” broadly as any “consumer” of the global Internet DNS.

At this point in the thought experiment, let’s disregard the severity of the problem. The affected party (or parties) will likely exercise the full range of typical IT support options available to them – vendors, professional support, IT savvy friends and family, and Internet search.

If any of these support vectors are aware of ICANN, they may choose to contact ICANN at any point. Let’s further assume the affected party is unable and/or unwilling to correct the technical problem themselves and ICANN is contacted – directly or indirectly.

There is a critical fork in the road here: Is the expectation that ICANN provide technical “self-help” information or that ICANN will go further and “do something” to technically remedy the issue for the user? The scope of both paths needs substantial consideration.

For the rest of this blog, I want to focus on the various “do something” options. I see a few options; they aren’t mutually exclusive (one could imagine an escalation through these and potentially other options). The options are enumerated for discussion only and order is not meaningful.

  • Option 1: ICANN provides technical support above and beyond “self-help” information to the impacted parties directly, including the provision of services/experts. Stated differently, ICANN becomes an extension of the impacted party’s IT support structure and provides customized/specific troubleshooting and assistance.
  • Option 2: The Registry provides technical support above and beyond “self-help” information to the impacted parties directly, including the provision of services/experts. Stated differently, the Registry becomes an extension of the impacted party’s IT support structure and provides customized/specific troubleshooting and assistance.
  • Option 3: ICANN forwards the issue to the Registry with a specific request to remedy. In this option, assuming all attempts to provide “self-help” are not successful, ICANN would request that the Registry make changes to their zone to technically remedy the issue. This could include temporary or permanent removal of second level names and/or other technical measures that constitute a “registry-level rollback” to a “last known good” configuration.
  • Option 4: ICANN initiates a “root-level rollback” procedure to revert the state of the root zone to a “last known good” configuration, thus (presumably) de-delegating the impacted TLD. In this case, ICANN would attempt – on an emergency basis – to revert the root zone to a state that is not causing harm to the impacted party/parties. Root-level rollback is an impactful and potentially controversial topic and will be the subject of a follow-up blog.

One could imagine all sorts of variations on these options, but I think these are the basic high-level degrees of freedom. We note that ICANN’s New gTLD Collision Occurrence Management Plan and SAC062 contemplate some of these options in a broad sense.

Some key considerations:

  • In the broader sense, what are the appropriate roles and responsibilities for all parties?
  • What are the likely sources to receive complaints when a collision has a deleterious effect?
  • What might the Service Level Agreements look like in the above options? How are they monitored and enforced?
  • How do we avoid the “cure is worse than the disease” problem – limiting the harm without increasing risk of creating new harms and unintended consequences?
  • How do we craft the triggering criteria for each of the above options?
  • How are the “last known good” configurations determined quickly, deterministically, and with low risk?
  • Do we give equal consideration to actors that are following the technical standards vs. those depending on technical happenstance for proper functionality?
  • Are there other options we’re missing?

On Severity of the Harm

Obviously, the severity of the harm can’t be ignored. Short of situations where there is a clear and present danger of bodily harm, severity will almost certainly be measured economically and from multiple points of view. Any party expected to “do something” will be forced to choose between two or more economically motivated actors: users, Registrants, Registrars, and/or Registries experiencing harm.

We must also consider that just as there may be users negatively impacted by new DNS behavior, there may also be users that are depending on the new DNS behavior. A fair and deterministic way to factor severity into the response equation is needed, and the mechanism must be compatible with emergency invocation and the need for rapid action.

Request for Feedback

There is a lot here, which is why we’ve published this early in the process. We eagerly await your ideas, feedback, pushback, corrections, and augmentations.

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.

.wow has more collisions than any other new gTLD

Kevin Murphy, November 18, 2013, Domain Registries

Amazon, Google or Demand Media are going to have to block over 200,000 strings in .wow, which all three have applied for, due to the risk of name collisions.

That’s tens of thousands of names greater than any other applied-for gTLD string.

Here’s the top 20 gTLDs, ranked by the number of collisions:

wow205447
dell121824
host118517
gold108328
hotel108223
house107365
telefonica106624
computer98569
maison96325
movistar96241
cam95422
auto89966
abc85260
samsung84630
red76573
ads73783
sky72861
inc69558
ibm68843
unicorn68805

The average new gTLD string has 7,346 potential collisions, according to our preliminary analysis of the lists ICANN published for 1,318 strings this morning.

As blogged earlier, 9.8 million unique domain names are to be blocked in total.

Seventeen gTLDs seem to have been provided with empty lists, so will not have to block any domains in order to proceed to delegation with ICANN.

Over 87,000 new gTLD domains now blocked

Kevin Murphy, November 12, 2013, Domain Registries

The total number of domain names to be blocked due to the risk of name collisions has topped 87,000 with the latest batch of block-lists from ICANN, published yesterday.

According to our database, 87,670 domain names, representing 75,208 unique second-level strings, are to be blocked in the 37 new gTLDs that have published collisions lists.

The string “www” is on all 37 lists, followed closely by “com”, “org” and “net”.

The most commonly blocked names include large numbers of single characters and large numbers of two-character strings matching ccTLDs (which were already banned in new gTLDs anyway).

Lots of protocol-related strings, such as “http”, “ftp”, “isatap” and “wpad” can also be found in the top 100 strings.

Gambling-related strings are also hugely, and so far inexplicably, popular blocking candidates.

Google, Yahoo, Facebook and Apple are the most frequently seen brands.

The full consolidated list of blocked strings can be searched at the DI PRO name collisions database.

The gTLD with the biggest block-list so far is .kitchen, with 13,061 strings, over half as big again as the next-longest list, which is .uno’s 8,187 names.

.sexy and .uno raise the average collisions list size

Kevin Murphy, November 6, 2013, Domain Registries

The third batch of new gTLD collisions lists has been released by ICANN, raising the average number of domains that registries are being told to block on extremely cautious security grounds.

The average number of second-level domains to be blocked per gTLD is now 1,904, largely due to the impact of very large lists for .uno (which has 8,187) and .sexy (6,560), which were published yesterday.

This number is only going to get bigger as more cool-sounding Latin-script gTLDs raise the average.

It will be tempered somewhat by the IDN gTLDs, however. The average list for IDNs has only 253 names on it, based on the five published so far.

The most popular strings, ranked by the number of gTLDs’ lists in which they show up (out of a possible 18), are:

www18
com16
org15
net14
casino13
isatap13
m13
wpad13
uk13
info13

There are 30,581 unique second-level strings in total, all of which are fully cross-referenced and searchable at DI PRO.

The most-blocked exact-match brands so far are Yahoo and Google, which both appear on 10 lists. Apple, Facebook and YouTube appear as exact matches on eight.

Is ICANN ready to start rejecting some new gTLDs?

Kevin Murphy, November 4, 2013, Domain Policy

Is ICANN getting ready to give marching orders to new gTLD applicants? It seems likely given recent hints out of LA.

Currently, of the original 1,930 new gTLD applications, 125 have been withdrawn but only two or three have been rejected.

GCC’s .gcc and DotConnectAfrica’s .africa are both “Not Approved” while Nameshop’s .idn failed to pass its applicant support program tests and seems to have been put aside for this round.

But there are at least 22 active applications that are due to be hit with the ban hammer, by my reckoning. That’s not including those that may be killed off by Governmental Advisory Committee advice.

First, there are seven bids (so far) that have failed Community Objections or Legal Rights Objections filed against them, or have lost String Confusion Objections filed by existing TLD operators.

Applications such as Ralph Lauren’s .polo, Dish DBS’ .direct and Demand Media’s .cam have fallen foul of these three objection types, respectively.

Under the Applicant Guidebook rules, these applications are not allowed to proceed.

There are also 10 active applications for .home and five for .corp, two gTLD strings ICANN has said it will not approve due to their substantially higher risk of causing name collisions.

(Personally, I think these applicants should get full refunds — ICANN screwed up by not doing its homework on name collisions before opening the application window last year).

So far, ICANN seems to have been waiting for applicants to withdraw, rather than initiating a formal rejection.

But none of them actually have withdrawn.

The International Union of Architects, which won a Community Objection against Donuts over .architect in September, has noticed this too, and recently wrote to ICANN to find out what was going on.

Responding October 31, Generic Domains Division president Akram Atallah wrote (with my emphasis):

as a result of the objection determination, we have updated the status of the objection on the .ARCHITECT application to “Objector Prevailed” on the Objection Determinations page (http://newgtlds.icann.org/en/program-­‐status/odr/determination) of the New gTLD microsite. Additionally, we will be updating the overall status of this application on the New gTLD microsite (https://gtldresult.icann.org/application-­‐result/applicationstatus) pursuant to Section 1.1.2.9 of the Applicant Guidebook in the near future.

This suggests either a “Not Approved” status for .architect, or a new status we haven’t seen before, such as “Lost Objection”.

So could, for example, Demand Media’s .cam application be rejected? Demand lost a SCO filed by Verisign, but its two competitors for the string prevailed in virtually identical cases.

Would it be fair to reject one but not the others, without any kind of ICANN review or oversight?

Last week at the newdomains.org conference in Munich, I asked Atallah a question during a panel discussion about consistency in the new gTLD program, with reference to objections.

I was on stage and not taking notes, but my recollection is that he offered a not at all reluctant defense of subjectivity in panelists’ decision-making.

It was certainly my impression that ICANN is less troubled by inconsistent rulings than the applicants are.

In the .architect case, Atallah told the UIA that ICANN intends to implement objection rulings, writing:

ICANN will, of course, honor all panel decisions regarding objection determinations, unless directed to do otherwise by some action, for example, by virtue of Reconsideration Requests or other accountability mechanisms or action of the ICANN Board of Directors. To our knowledge, Spring Frostbite [Donuts] has not filed a Reconsideration Request or invoked an Independent Review Process with respect to this objection determination regarding the .ARCHITECT string.

Search all new gTLD collision block lists

Kevin Murphy, October 31, 2013, Domain Services

DI PRO subscribers can now see which strings appear most often in new gTLD registries’ block-lists and search for strings — such as trademarks or premium strings — that interest them.

We’ve just launched the New gTLD Collisions Database.

Currently, it indexes all 14,493 unique strings that ICANN has told the first 13 new gTLD registries to block — due to the risk of collisions with internal networks — when they launch.

By default the strings are ranked by how many gTLDs have been told to block them.

You’ll see immediately that “www” is currently blocked in all 13 registries, suggesting that it’s likely to be blocked in the vast majority of new gTLDs.

Users can also search for a string in order to see how many, and which, new gTLDs are going to have to block it.

We’re hoping that the service will prove useful to trademark owners that want to see which “freebie” blocked strings they stand to benefit from, and in which gTLDs.

For example, we can already see that 10 meaningful strings containing “nike” are to be blocked. For “facebook”, it’s four registries. For “google”, it’s currently three strings across six gTLDs.

The service will also hopefully be useful to registries that want to predict which strings ICANN may tell them to block. We’re seeing a lot of gambling terms showing up in non-gambling TLDs, for example.

Here’s a screenshot of sample output for the search “cars”.

DI PRO

As ICANN publishes lists for more gTLDs, the database will grow and become more useful and time-saving.

Comments, suggestions and bug reports as always to kevin@domainincite.com

First collision block-lists out now. How painful will they be for new gTLDs?

Kevin Murphy, October 19, 2013, Domain Registries

ICANN has published the name collision block-lists for the first four new gTLDs, and they making pretty interesting reading.

The four registries in question will be required to block between 104 and 680 unique second-level domains from their gTLDs if they want to use the fastest path to delegation on offer.

The four gTLDs with lists published this morning are: .сайт (Russian “.site”), .онлайн (Russian “.online”), شبكة. (Arabic “.web”) and .游戏 (Chinese “.games”).

These were the first four new gTLDs with signed Registry Agreements. ICANN seems to be following the order contracts were signed, rather than the official prioritization number.

So what’s on the lists?

Gibberish

The first thing to note is that, as expected, ICANN has helpfully removed invalid strings (such as those with underscores) and gibberish Google Chrome strings from the lists, greatly reducing their size.

The block-lists are based on Day In The Life Of The Internet data, which recorded DNS root queries for applied-for gTLDs over 48-hour periods between 2006 and 2013.

According to ICANN, “a significant proportion” of the DITL queries were for the nonsense 10-character strings that Chrome generates and sometimes accidentally sends to the public DNS.

Because these “appear to present minimal risk if filtered from the block lists”, ICANN has made an effort to automatically remove as many as possible, while acknowledging it may not have caught them all. The human eye is good at spotting meaningless strings, software is not so adept.

All four lists still contain plenty of gibberish strings, according to this human eye, but mostly they’re not of 10 characters in length.

IDNs

All four lists published today are for non-Latin domain names and are presumably expecting their registries to be mostly populated with IDN.IDN domain names.

As such, the impact of their mostly Latin block-lists may be even smaller than it first appears.

For example, if we look at the list for .сайт, which has 680 strings to block, we discover that only 80 of them are IDNs (beginning with xn--). I assume they’re all, like the gTLD, in Cyrillic script.

I haven’t decoded all of these strings from Punycode and translated them from Russian, but the fact is there’s only 80 of them, which may not be unduly punitive on CORE Association’s launch plan.

At the other end of the spectrum, Donuts will only have to block 13 IDN strings from its .游戏 (Chinese .games) gTLD, and the ASCII strings on its list are mostly numeric or gibberish.

There’s very probably some potentially valuable generic strings on these lists, of course, which could impact the landrush purse, but it’s beyond this monoglot’s expertise to pick them out.

Trademarks

A small number of Latin-script brands appear on all four lists.

Donuts will have to block nokia.游戏, htc.游戏 and ipad.游戏 in its Chinese “.games”, for example. CORE will have to block iphone.сайт and brazzersnetwork.онлайн. DotShabaka Registry will have to block شبكة.redbull.

The impact of this on the registries could be minimal — a few fewer sunrise sales, assuming the brand owner intended to defensively register.

If the blocked brand was a potential launch partner it could be much more annoying and even a launch-delaying factor. It’s not yet clear how registries and brand owners will be able to get these names unblocked.

Bear in mind that registries are not allowed to activate these domains in any sense for any use — they must continue to return NXDOMAIN error responses as they do today.

I’m sure ipad.游戏 (“ipad.games”) could have some value to Apple — and to Donuts, in the unlikely event it managed to persuade Apple to be an anchor tenant — but it’s no longer available.

ICANN will deliver full mitigation plans for each gTLD, which may often include releasing blocked names to their ‘rightful’ owner, but that’s not expected for some months.

Generic terms

A number of generic dictionary terms are getting blocked, which may prove irksome for those registries with long lists. For example, CORE will have to block photo.сайт and forum.сайт.

So far, .онлайн has by far the longest list of ASCII generics to block — stuff like “football”, “drinks”, “poker” and “sex”. Even weirdness like “herpesdating” and “musclefood”.

As it’s an IDN, this might not be too painful, but once ICANN starts publishing lists for Latin gTLDs we might start seeing some serious impact on registries’ ability to sell and market premium domains.

Shurely shome mishtake

There are a few strings on these lists that are just weird, or are likely to prove annoying to registries.

All four of these gTLDs are going to have to block “www” at the second level, for example, which could impact their registry marketing — www.tld is regularly used by TLD registries.

It is going to be really problematic if “www” shows up on the block-lists for dot-brand registries — many applicants say “www.” is likely to be the default landing page for their dot-brand.

The only string that ICANN says it won’t put on any block-list is “nic”, which was once the standard second-level for every TLD’s registry web site but doesn’t really have mass recognition nowadays.

The block-lists also include two-letter strings, most of which correspond to ccTLDs and all of which are already banned by the base Registry Agreement for precisely that reason.

There’s no reason for these two-letter names to be on the lists, but I don’t see their presence causing any major additional heartaches for registries.

So is this good news or what?

As the four block-lists to be released so far are for IDN gTLDs, and because I don’t speak Chinese, Arabic or Russian, it’s a difficult call today to say how painful this is going to be.

There are plenty of reasons to be worried if you’re a new gTLD applicant, certainly.

Premium names will be taken out of play.

You may lose possible anchor tenants.

Your planned registry-use domain names may be banned.

If you’re a dot-brand, you’d better start thinking of alternatives to “www.”.

But the block-lists are expected to be temporary, pending permanent mitigation, and they’re so far quite small in terms of meaningful strings, so on balance I’d say so far it’s not looking too bad.

On the other hand, nothing on the published lists jumps out at me like a massive security risk, so the whole exercise might be completely pointless and futile anyway.