Latest news of the domain name industry

Recent Posts

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?

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.

Today’s new gTLDs decisions in full

Kevin Murphy, October 28, 2011, Domain Policy

ICANN’s board of directors passed two resolutions relating to new generic top-level domains at is meeting in Dakar, Senegal today.

While neither is particularly Earth-shattering, they are notable and therefore reproduced here in full.

The first relates to financial support for new gTLD applicants from developing nations.

ICANN has not figured out how to implement the recommendations of the JAS working group yet, but it hopes to do so before the end of the year.

Joint Applicant Support

Whereas, the Board has received the Final Report of the Joint Applicant Support Working Group (JAS WG), appreciates the work of the JAS WG created in April 2010 by the ALAC and GNSO, and thanks the entire ICANN community for the constructive dialogue leading up to and during this week in Dakar.

Whereas, the Board expresses its appreciation to the GAC and ALAC for their joint statement on the JAS WG report.

Whereas, the Board is committed to ensuring that the implementation of a support program for deserving applicants will be done in a manner to enable those applicants to effectively participate in and benefit from the first round of the New gTLD Program.

Resolved (2011.10.28.21), the Board takes the JAS WG Final Report seriously, and a working group of Board members has been convened to oversee the scoping and implementation of the recommendations arising out of that Report, as feasible.

Resolved (2011.10.28.22), the President and CEO is expected to commence work immediately and provide a detailed plan for consideration. If the plan is complete sufficiently in advance of its next scheduled Board Meeting set for 8 December 2011, the Board will seek to add a special meeting to its schedule prior to that date.

Rationale for Resolutions 2011.10.28.21 – 2011.10.28.22

In Singapore, the Board resolved that it would consider the report and recommendations of the Joint Applicant Support Working Group. The Board takes seriously the assertions of the ICANN community that applicant support will encourage diverse participation in the New gTLD Program and promote ICANN’s goal of broadening the scope of the multi-stakeholder model. In its deliberations, the Board is balancing its fiscal responsibility in launching the New gTLD Program, the desire to provide a support program in the first round, and the time required to obtain additional funding. While the Board solution is not complete, there is a vision for accomplishing each of those three goals.  As required for assessment within the Affirmation of Commitments, there is no security and stability impact on the DNS. Part of the further work required through this resolution will assess the affect of this work; however there is no affect on ICANN’s fiscal resources as a result of this immediate action.

The second resolution, which caused considerable debate among board members, relates to funding of the much-criticized new gTLDs communications campaign.

The board approved an additional $900,000 for outreach, much of which will apparently go into the pockets of newly hired PR firm Burson-Marsteller.

Budget Request – New gTLD Communications Plan

Whereas, at the Paris ICANN meeting in 2008, the Board adopted the GNSO policy recommendations to introduce new Generic Top-Level Domains (new gTLDs), including at least a four-month communications period to raise global awareness.

Whereas, the Draft New gTLD Communications Plan (link) describes the global outreach and education activities that will be conducted in each of the ICANN geographic regions.

Whereas, the FY 12 budget allocates US $805,000 to fund this effort.

Whereas, planning and subsequent execution of the Communications Plan has indicated the need for a full service global public relations firm to ensure ICANN effectiveness in this effort.

Whereas, funds can be re-allocated in the adopted ICANN Budget to support the augmented communications effort without materially affecting performance in other areas.

Whereas, at its 22 October 2011 meeting the Board Finance Committee approved a recommendation that the Board approve an additional expenditure of US$900,000 for the execution of the Communications Plan.

Resolved (2011.10.28.23), the Board approves an additional expenditure of up to US $900,000 for the remaining three months of the Communications Plan, to be used for the retention of Burson-Marsteller, a global public relations firm, to work towards the goal of raising global awareness of new Generic Top Levels Domains consistent with the terms of the Communications Plan.

Resolved (2011.10.28.24), the Board authorizes the President and CEO to enter into any contracts necessary to fulfill the objectives of the New gTLD Communications Plan to the extent those contracts do not exceed the budget for the Communications Plan.

Rationale for Resolution 2011.10.28.23 – 2011.10.28.24

The budget for the Board-mandated new gTLD communications program is currently US $805,000. That figure was based on an earlier draft communications plan.

The current plan is more expansive and ambitious. It is based on the premise that every potential applicant should be aware of the program’s opportunities and risks, and thus it is aimed at building maximum awareness through multiple communications channels. It also focuses more strongly on developing countries.

The Plan is built on four principal efforts:

1. Regional “road shows” and public events;
2. Earned media – broadcast, online and print;
3. Social media; and
4. Global information through paid advertising, and multiplying these efforts through the community.

The New gTLD Communications Plan is neutral in its presentation. ICANN is not promoting applications for new gTLDs or advocating that any organization apply for one. Rather, ICANN is providing essential information and raising awareness of the New gTLD Program.

The current efforts limited in scope. ICANN has determined that retaining a full-service worldwide public relations firm to further coordinate ICANN’s efforts will assure that ICANN is able to attain the goal of the New gTLD Communications Plan.

ICANN has identified a well-respected global public relations firm, Burson-Marsteller, that can provide a broad range of awareness-raising services. ICANN will have access to the firm’s extensive network with an established presence in 91 countries, over 40 of them developing nations. These local and regional assets are invaluable. ICANN also will benefit from the firm’s expertise in digital and social media. ICANN will retain editorial control over all implementation aspects of the New gTLD Communications Plan.

Securing a global public relations firm of this caliber will contribute greatly toward ensuring success of the New gTLD Communications Plan. And as the first deliverable of the New gTLD Program, success of the New gTLD Communications Plan is critical.

Approval of this resolution will positively affect ICANN’s accountability and transparency by globally maximizing the spread of information about ICANN itself. This action will have no effect on the security, stability and resiliency of the domain name system.

The New gTLD Communications Plan will be conducted within the existing ICANN budget. This effort will be funded out of contingency funds, so the expenditure will not affect ICANN’s ability to perform and accomplish its other goals and objectives.

More later.

Will ICANN approve cheap gTLDs for poor applicants?

Kevin Murphy, October 21, 2011, Domain Policy

One of the big questions at ICANN’s 42nd public meeting in Dakar next week is whether the board of directors plans to approve subsidized new gTLD application fees for worthy applicants.

A volunteer working group known as JAS came up with a set of recommendations last month that would lower the $185,000 fee for applicants from developing nations with public benefit missions.

It was a wide-ranging set of proposals that would stretch beyond the scope of the $1 million to $2 million ICANN approved for applicant support initiatives at its last meeting in June.

Chiefly, JAS wants the application fee reduced to $45,000 for qualified developing-world applicants, meaning ICANN would have to find the funds to cover the $140,000 shortfall elsewhere.

In addition, JAS wants ICANN to set up a fund to loan money to these same applicants. It also wants these applicants to be able to pay fees on a staggered schedule.

Whether it was deliberate or not (I suspect it was semi-deliberate), the JAS wish-list seems to me to go above and beyond the support the ICANN board said it was prepared to offer in June.

I don’t think the board will grant those wishes when it meets next Friday, and here’s a few reasons why.

First, CEO Rod Beckstrom has already basically ruled out blanket fee reductions, even for poorer applicants, and he did so after the board had already discussed them.

At an ICANN panel on new gTLDs in London last month, Beckstrom was asked by an audience member if the application fee could be reduced before January.

At roughly 32 minutes into the embedded video, this is what he said:

There’s no plans to reduce the fee and I could not contemplate that happening before the program opens. The fees have been determined and there’s no process to review them, and there would be no basis at the present time because the costing estimates in the program appear to be reasonably accurate.

He went on to say that economies of scale may lead to a reduction in fees in future rounds, but did not mention the JAS recommendations at all.

As I was also on the panel, I called him on the omission later in the discussion, roughly 45 minutes into the video above. He said:

The board of directors did make a directional indication in Singapore to set aside up to a million to two million dollars for financial support for applicants…

However, it’s not a repricing of the fees, it would be some type of support for those applicants. A reduction in the application fee or effectively subsidizing the application fee is one possible concept, but what I can tell you as the CEO and as a board member is that board’s indication is one to two million dollars, not an unlimited number, so can do math and figure out what might be possible and what might not.

We’re not going to change the program fees, it just means there might be some benefit to or some support for some applicants, but it may not come in the form of that subsidy for the fee.

What we have here is JAS asking for a fundamental restructuring of the application fee in certain circumstances, and ICANN’s CEO saying that’s not likely to happen.

At that time, the JAS report had not been formally submitted to the board, but it had nevertheless been seen and discussed by the board at its two-day retreat in mid-September.

The GNSO, which had been frustrated with the cross-constituency structure of the JAS for some time, didn’t even formally approve the report before forwarding it to the board, due to time constraints.

Another indication of the board’s thinking on the JAS recommendations comes from the minutes of its Finance Committee meeting, September 15. Here’s an extract:

Staff has initiated efforts to be ready for implementation if and when approved. Establishment of a fund – a short-term mechanism for earmarking funds for applicant support, and a long-term formal mechanism for several purposes. Meeting community expectations: Board had approved US $2mm, while the JAS/GAC-ALAC recommendations would be more costly. Four tasks: developing criteria based on the JAS report plus practical concerns, developing procedures, entity for considering applications, and mechanism for holding the funds. Discussed the need to stay within the mission and purpose of ICANN and the ability to set-up special funds.

There’s no mention of application fees, but there is an acknowledgment that the JAS recommendations would be more expensive to implement than just the $2 million ICANN has already set aside.

There’s also talk of “practical concerns” and the “need to stay within the mission and purpose of ICANN”, all of which says to me that there’s a worry JAS asked for too much.

We’ll have to wait until next Friday to find out for sure, but my guess is that the board will likely side with ICANN’s bean-counters and that the JAS will not get much of what it asked for.

With 86 days to go, the cost of new gTLDs is still unknown

Kevin Murphy, October 18, 2011, Domain Policy

If you’re planning to apply for a new generic top-level domain or two, wouldn’t it be nice to know how much it’s going to cost you?

It’s less than three months before ICANN opens the floodgates to new gTLD applicants, but you’re probably not going to find out how big your bank account needs to be until the last minute.

With 86 days on the clock until the application window opens, and 177 until it closes, there are still at least two huge pricing policies that have yet to be finalized by ICANN.

The first relates to reduced application fees and/or financial support handouts for worthy applicants from developing nations. I’ll get to that in a separate piece before Dakar.

The second is the controversial Continued Operations Instrument, a cash reserve designed to ensure that new gTLDs continue to operate even if the registry manager goes out of business.

In the current Applicant Guidebook, prospective registries are told to prove that they have enough money – either with a letter of credit or in a cash escrow – to keep their gTLD alive for three years.

To be clear, the COI money doesn’t go into ICANN’s coffers; applicants just need to show that the cash exists, somewhere.

The funds would be used to pay the Emergency Back-End Registry Operator (whichever company that turns out to be) in the event of a catastrophic gTLD business failure.

With hundreds of new gTLDs predicted, many of them likely to be laughably naive, we’re likely to see plenty of such failures.

With that in mind, ICANN wants to make sure that registrants and end users are not impacted by too much downtime if they put their faith in incompetent or unlucky registries.

It is estimated that the COI will amount to a six-figure sum for almost all commercial registries. For generics with a higher projected registration volume it could easily run into the millions.

It’s controversial for a number of reasons.

First, it raises the financial bar to applying considerably.

Forget the $185,000 application fee. Under the COI provision, applicants need to be flush enough to be able to leave millions of dollars dormant in escrow for at least five years.

It’s been sensibly argued that this money would be better devoted to making sure the registry doesn’t fail in the first place.

Second, even though the Guidebook gives .brand applicants the ability to shut down their gTLDs without the risk of another provider taking them over, it also expects them to create a COI.

This appears to be an unnecessary waste of cash. If a single-registrant .brand gTLD fails, the registry itself is the only registrant affected and the COI is essentially redundant.

Third, some applicants are thinking about low-balling their business model projections in order to keep their COI to a manageable amount.

This, as the better new gTLD consultants will tell you, could be a bad idea. When applications are reviewed the evaluators will be looking for discrepancies like this.

If you’re making one set of financial projections to investors and another to ICANN, you risk losing points on and possibly failing the evaluation.

Anyway, with all this in mind (and with apologies for burying the lead) ICANN has just said that it’s thinking about completely revamping the COI policy before applications are accepted.

Seriously.

ICANN’s Registry Stakeholder Group community has made a proposal – which appears to be utterly sensible on the face of it – that would reduce costs by pooling the risk among successful applicants.

The RySG said it that the COI “should not be so burdensome as to actually become a roadblock to the success of new registries by causing capital to be tied up unduly.”

Rather than putting up enough cash to cover its own failure, each successful applicant would pay $50,000 up-front into a Continued Operations Fund that would cover all potential registry failures.

The COF would be administered by ICANN (or possibly a third party), and would be capped at $20 million. In a round of 400 new gTLDs, that target would be reached immediately.

If the COF fell short of $20 million, each registry would have to pay $0.05 per domain name per year into the fund until the cap was reached.

It’s a shared-risk insurance model, essentially.

While ICANN’s COI policy is ultra-cautious, implicitly assuming that ALL new gTLDs could simultaneously fail, the COF proposal assumes that only a small subset will.

Reverse-engineering the RySG’s numbers, the COF appears to cover the risk of failure for registries representing some 10 million domain-years.

ICANN has opened up the proposal to public comments until December 2.

This means we’re unlikely to see any concrete action to approve or reject the COF alternative until, at the earliest, about a month before the first round application window opens.

ICANN likes cutting things fine, doesn’t it?