Latest news of the domain name industry

Recent Posts

Uniregistry to release 10 million domains on October 4

Kevin Murphy, September 20, 2016, Domain Registries

Uniregistry plans to release millions of registry-reserved domain names, many at standard registration fee, two weeks from now.

The company, which has about 25 new gTLDs in its stable, will release 10 million currently reserved names on October 4, CEO Frank Schilling told DI.

The revelation follows news that the company has started allowing thousands of registry-owned domains to expire and return to the available pool.

About 200,000 domains originally registered to North Sound Names, a separate Schilling-controlled company, are being made available via regular channels.

Those domains were registered (rather than reserved) so that Uniregistry could throw up landing pages inviting potential buyers to make offers. After they drop, they will no longer resolve.

But Schilling said a further 9.8 million names will also hit the market next month.

“It’s just a much better time because we have greater distribution and we are less likely to see all our names taken at land rush by one or two commercial registrants,” he said.

“We are unblocking and deleting 10 million domain names and making them available for registration through more than 200 registrars,” he said.

“Almost all will be standard reg [fee],” he said, when asked about pricing. Others will carry premium fees.

A web site publishing lists of newly released names will go live in about a week, he said.

DNW has previously reported that Uniregistry plans to release names that were initially blocked due to ICANN’s name collisions mitigation plan.

Those lists (which are usually mostly junk) are already published by ICANN and can be found accompanying the Registry Agreement for the relevant TLD linked from this page. Here’s the 35,000-name .link collisions list (.csv) for example.

Are .mail, .home and .corp safe to launch? Applicants think so

Kevin Murphy, August 28, 2016, Domain Tech

ICANN should lift the freeze on new gTLDs .mail, .home and .corp, despite fears they could cause widespread disruption, according to applicants.

Fifteen applicants for the strings wrote to ICANN last week to ask for a risk mitigation plan that would allow them to be delegated.

The three would-be gTLDs were put on hold indefinitely almost three years ago, after studies determined that they were at risk of causing far more “name collision” problems than other strings.

If they were to start resolving on the internet, the fear is they would lead to problems ranging from data leakage to systems simply stopping working properly.

Name collisions are something all new TLDs run the risk of creating, but .home, .corp and .mail are believed to be particularly risky due to the sheer number of private networks that use them as internal namespaces.

My own ISP, which has millions of subscribers, uses .home on its home hub devices, for example. Many companies use .corp and .mail on their LANs, due to longstanding advice from Microsoft and the IETF that it was safe to do so.

A 2013 study (pdf) showed that .home received almost 880 million DNS queries over a 48-hour period, while .corp received over 110 million.

That was vastly more than other non-existent TLDs.

For example, .prod (which some organizations use to mean “production”) got just 5.3 million queries over the same period, and when Google got .prod delegated two years it prompted an angry backlash from inconvenienced admins.

While .mail wasn’t quite on the same scale as the other two, third-party studies determined that it posed similar risks to .home and .corp.

All three were put on hold indefinitely. ICANN said it would ask the IETF to consider making them officially reserved strings.

Now the applicants, noting the lack of IETF movement to formally freeze the strings, want ICANN to work on a thawing plan.

“Rather than continued inaction, ICANN owes applicants for .HOME, .CORP, and .MAIL and the public a plan to mitigate any risks and a proper pathway forward for these TLDs,” the applicants told ICANN (pdf) last Wednesday.

A December 2015 study found that name collisions have occurred in new gTLDs, but that no truly serious problems have been caused.

That does not mean .home, .corp and .mail would be safe to delegate, however.

New ccTLDs may have to block name collisions

Kevin Murphy, January 26, 2015, Domain Registries

ICANN is thinking about expanding its controversial policy on name collisions from new gTLDs to new ccTLDs.

The country code Names Supporting Organization has been put on notice (pdf) that ICANN’s board of directors plans to pass a resolution on the matter shortly.

The resolution would call on the ccNSO to “undertake a study to understand the implications of name collisions associated with the launch of new ccTLDs” including internationalized domain name ccTLDs, and would “recommend” that ccTLD managers implement the same risk mitigation plan as new gTLDs.

Because ICANN does not contract with ccTLDs, a recommendation and polite pressure is about as far as it can go.

Name collisions are domains in currently undelegated TLDs that nevertheless receive DNS root traffic. In some cases, that may be because the TLDs are in use on internal networks, raising the potential of data leakage or breakages if the TLDs are then delegated.

ICANN contracts require new gTLDs to block such names or wildcard their zones for 90 days after launch.

Some new gTLD registry executives have mockingly pointed to the name collisions issue whenever a new ccTLD has been delegated over the last year or so, asking why, if collisions are so important, the mitigation plan does not apply to ccTLDs.

If the intent was to persuade ICANN that the collisions management framework was unnecessary, the opposite result has been achieved.

.top says Facebook shakedown was just a typo

Kevin Murphy, January 16, 2015, Domain Registries

Jiangsu Bangning Science & Technology, the .top registry, is blaming a typo for a Facebook executive’s claim that it wanted $30,000 or more for facebook.top.

Information provided to the ICANN GNSO Council by Facebook domain manager Susan Kawaguchi yesterday showed that .top wanted RMB 180,000 (currently $29,000) for a trademarked name that previously had been blocked due to ICANN’s name collisions policy.

But Mason Zhang, manager of the registry’s overseas channel division, told DI today that the price is actually RMB 18,000 ($2,900):

We were shocked when seeing that our register price for TMCH protected names like Facebook during Exclusive Registration Period is changed from “eighteen thousand” into what is written, the “one hundred and eighty thousand”.

I think that might be a type mistake from our side, and we checked and we are certain that the price is CNY EIGHTEEN THOUSAND.

The 18,000-yuan sunrise fee is published on the registry’s official web site, as I noted yesterday.

The registry email sent to Facebook is reproduced in this PDF.

I wondered yesterday whether a breakdown in communication may to be blame. Perhaps I was correct.

While $3,000 is still rather high for a defensive registration, it doesn’t stink of extortion quite as badly as $30,000.

Still, it’s moderately good news for Facebook and any other company worried they were going to have to shell out record-breaking prices to defensively register their brands.

Millions of new gTLD domains to be released as collision blocks end

Kevin Murphy, November 17, 2014, Domain Registries

Millions of new gTLD domain names are set to start being released, as ICANN-mandated name collision blocks start getting lifted.

Starting yesterday, domains that have been blocked from registration due to name collisions can now be released by the registries.

About 95,000 names in gTLDs such as .nyc, .tattoo, .webcam and .wang have already ended their mandatory “controlled interruption” period and hundreds of thousands more are expected to be unblocked on a weekly basis over the coming months (and years).

Want to register sex.nyc, poker.bid or garage.capetown? That may soon be possible. Those names, along with hundreds of other non-gibberish domains, are no longer subject to mandatory blocks.

Roughly 45 new gTLDs have ended their CI periods over the last two days. Here are the Latin-script ones:

.bid, .buzz, .cancerresearch, .capetown, .caravan, .cologne, .cymru, .durban, .gent, .jetzt, .joburg, .koeln, .krd, .kred, .lacaixa, .nrw, .nyc, .praxi, .qpon, .quebec, .ren, .ruhr, .saarland, .wang, .webcam, .whoswho, .wtc, .citic, .juegos, .luxury, .menu, .monash, .physio, .reise, .tattoo, .tirol, .versicherung, .vlaanderen and .voting

Another half dozen or so non-Latin script gTLDs have also finished with CI.

There are over 17,500 newly unblocked names in .nyc alone. Over the whole new gTLD program, over 9.8 million name collisions are to be temporarily blocked.

Name collisions are domains in new gTLDs that were already receiving DNS root traffic well before the gTLD was delegated, suggesting that they may be in use on internal networks.

To avoid possible harm from collisions, ICANN forced registries to make these names unavailable for registration and to resolve to the deliberately non-functional and odd-looking IP address 127.0.53.53.

Each affected name had to be treated in this way for 90 days. The first TLDs started implementing CI on August 18, so the first batch of registries ended their programs yesterday.

So, will every domain that was on a registry’s collision list be available to buy right away?

No.

ICANN hasn’t told registries that they must release names as soon as their CI period is over, so it appears to be at the registries’ discretion when the names are released. I gather some intend to do so as soon as today.

Also, any name that was blocked due to a collision and also appears in the Trademark Clearinghouse will have to remain blocked until it has been subject to a Sunrise period.

Some registries, such as Donuts, have already made their collision names available (but not activated in the DNS) under their original Sunrise periods so will be able to release unclaimed names at the same time as all the rest.

Other registries will have to talk to ICANN about a secondary sunrise period, to give trademark holders their first chance to grab the previously blocked names.

Furthermore, domains that the registry planned to reserved as “premiums” will continue to be reserved as premiums.

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.

Victims of first confirmed new gTLD collision respond: “Fuck Google”

Kevin Murphy, September 12, 2014, Domain Registries

A number of companies have experienced errors on their networks due to collisions with a newly introduced gTLD.

The initial outcry from victims can be characterized as a storm of profanity, which it could be argued is a good thing for security but not great for ICANN’s reputation.

The collisions, which I believe are the first to be publicly and widely reported, are due to Google’s new gTLD .prod, which was delegated September 1.

Google intends to use the TLD as a shorthand for “product”, but it seems some companies use it internally to mean “production”, meaning production servers rather than testing or development servers.

Issues started being reported on online fora on September 3, with Google unfairly bearing the brunt of the initial blame. Here are a few of the earliest examples from Twitter:

A day later, Reddit user “cunttard”, under a post entitled “Fuck Google”, wrote:

Google recently activated prod. TLD.

They also decided to wildcard DNS all entries to 127.0.53.53 to resolve name collisions for internal organisations. All because they wanted .prod for product? Why not fucking request .product?

The implications have been fucking horrendous. I am in the process of helping a mate unfuck his organisations DNS, which heavily relied on resolver search $FQDN to map xyz.prod to xyz.prod.$FQDN. Note this wasn’t even used as an internal TLD. Now they’re all resolving short names to 127.0.53.53. Lesson learnt; always use FQDN everywhere.
I’m just fucking sick of ICANN / Google continuing to fuck DNS.

LinuxQuestions user “fantasygoat” started a thread entitled “New tLD .prod is messing with my configs”, in which he wrote:

I used to be able to refer to just the subdomain in a DNS lookup, like “www1.prod” and it would know I meant “www1.prod.example.com”, my local domain. I’ve been using prod.example.com for decades as the production subdomain for various things.

Now it resolves to 127.0.53.53, which I believe is ICANN’s hack DNS answer for tLDs.

So, I have a bunch of config files without the domain name and it’s messing stuff up. Does anyone have a workaround so I can have my DNS respond to .prod requests as a subdomain of my domain?

I’ve found a couple of other examples on various mailing lists and web forums with systems administrators experiencing similar issues over the last week.

This, it seems to me, shows that ICANN’s hack for mitigating the risks of name collisions, developed by JAS Advisors, is working as expected.

In each reported case of a .prod collision I’ve been able to find, the admin either had already worked out that he needed to use a fully-qualified domain name (eg www.prod.example.com instead of www.prod) or was swiftly advised to do so by those responding to his post.

Most seem to have spotted that instead of returning NXDOMAIN errors, Google is returning the IP address 127.0.53.53, which was chosen because it’s an internal IP and because 53 is the TCP/IP port number for DNS.

Diverting to 127.0.53.53 is designed to catch the eye, alerting admins to the need to correctly configure their networks.

It certainly seems to be doing that, but it’s not winning ICANN or new gTLD registries any new friends.

Nobody has yet reported death or injury due to a collision.

Update: There has been one previously reported collision, concerning .guru.

Blocked trademarks still eligible for Donuts sunrises

Kevin Murphy, December 13, 2013, Domain Registries

Donuts has confirmed that it is to allow trademark owners to participate in its new gTLD Sunrise periods even if their marks appear on name collisions block-lists.

The decision means that companies will be able to choose whether to grab names matching their marks during Sunrise, or take the risk that they will be released at a later date.

Donuts, like all gTLD registries, has been given block-lists for each of its TLDs. The idea is to avoid collisions with names already in use on private name-spaces behind corporate firewalls.

Lots of these blocked names match or contain well-known trademarks.

(Trademark owners can use the DI PRO collisions search engine to figure out which gTLDs have been asked to block their marks.)

While this appears at first glance to be good news for mark owners that just want their marks blocked in as many TLDs as possible, it also poses potential risks.

Blocked names are not likely to be blocked until after the first wave of Sunrise periods are over, and ICANN’s unblocking process has not yet been written.

For a company that wants to register its brand in a new gTLD, but is on a block-list, that could cause problems.

By allowing companies to participate in Sunrise regardless, Donuts is giving them a way to mitigate the risk of somebody else grabbing their brands in future.

Donuts does not plan to allow any of these names to be activated in the DNS until the ICANN collisions mitigation plan has been finalized, however.

So companies could find themselves paying for Sunrise names but unable to use them until some unspecified future date — if at all.

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.

These are the top 50 name collisions

Kevin Murphy, November 19, 2013, Domain Tech

Having spent the last 36 hours crunching ICANN’s lists of almost 10 million new gTLD name collisions, the DI PRO collisions database is back online, and we can start reporting some interesting facts.

First, while we reported yesterday that 1,318 new gTLD applicants will be asked to block a total of 9.8 million unique domain names, the number of distinct second-level strings involved is somewhat smaller.

It’s 6,806,050, according to our calculations, still a bewilderingly high number.

The most commonly blocked string, as expected, is “www”. It’s on the block-lists for 1,195 gTLDs, over 90% of the total.

Second is “2010”. I currently have no explanation for this, but I’m wondering if it’s an artifact of the years of Day In The Life data upon which ICANN based its lists.

Protocol-related strings such as “wpad” and “isatap” also rank highly, as do strings matching popular TLDs such as “com”, “org”, “uk” and “de”. Single-character strings are also very popular.

The brand with the most blocks (free trademark protection?) is unsurprisingly Google.

The string “google” appears as an exact match on 930 gTLDs’ lists. It appears as a substring of 1,235 additional blocked strings, such as “google-toolbar” and “googlemaps”.

Facebook, Yahoo, Gmail, YouTube and Hotmail also feature in the top 100 blocked brands.

DI PRO subscribers can search for strings that interest them, discovering how many and which gTLDs they’re blocked in, using the database.

Here’s a table of the top 50 blocked strings.

StringgTLD Count
www1195
20101187
com1124
wpad1048
net1032
isatap1030
org1008
mail964
google930
ww911
uk908
info905
http901
de900
us897
co881
local872
edu865
cn839
a839
e837
ru836
m833
ca831
c826
it821
tv817
server817
in814
gov814
wwww810
f804
facebook803
br803
fr799
ftp796
au796
yahoo794
1784
w780
biz778
g776
forum776
my764
cc762
jp761
s758
images754
webmail753
p749

  • Page 1 of 2
  • 1
  • 2
  • >