Home / Blogs

Innovating with New gTLDs

One of the primary purposes of the ICANN New generic Top-Level Domain (gTLD) program is to foster innovation in the DNS industry and the wider Internet. While having a desirable TLD string that users can relate to is a good starting point, gTLD applicants may want to bolster their value propositions by offering innovative services and differentiate their TLDs from others.

Defining the services to be offered is so central to a gTLD that it should be part of the initial strategy of any prospective applicant. When contemplating an idea, applicants should be mindful of the balance to be struck between innovation and the following factors:

  • Security and stability: ICANN’s foremost core value is to preserve and enhance the operational stability, reliability, security, and global interoperability of the Internet. A proposed service that may sound an alarm in this department will have to be accompanied by a very well thought-out technical plan and justified with facts and thorough analyses.
  • Ease-of-integration with registrars: registrars are not going to invest resources to integrate with a TLD’s special rules, however trivial it may seem, without just business incentives. Yes, a TLD’s primary sales channel is about to become ever more constricted.
  • Ease-of-use: if a service involves the registrant dealing with a party other than the registrar or performing additional steps during the lifecycle of the domain name, there will be plenty of room for confusion, which in turn has implications for security, TLD uptake as well as support overhead. This could also be a positive where a proposed service aims to make the DNS easier to use.
  • Resource demands: it’s common for businesses to experiment and take some risks, which are elements that go hand-in-hand with innovation. However, bear in mind that answers to the applicant guidebook questions will have to be coherent, and has appropriate resource allocation that caters for redundancy and contingency, in line with the technical, operational and financial approach of the proposed TLD. It could have an effect on the dollar amount of the “continued operations instrument”. While ICANN wants to foster innovation, it’s not so keen on seeing a TLD fail due to lack of resources.

Having looked at some of the constraints, let’s now explore some ideas that may serve as a starting point for applicants to establish a set of innovative services that fit their model.

Re-think DNS

Thick Zones

By provisioning a “domain name”, the registry is typically making (what we DNS geeks call) a “zone cut” to delegate that name to another set of name servers identified by NS records. However, that’s not the only way to register a name. Nothing stops the registry’s authoritative name servers from hosting the leaf records themselves instead of delegating. In fact, that is what DENIC does; it supports up to five A and MX records directly served by the .de authoritative name servers.

Doing this would attract a Registry Services Extended Evaluation (gTLD Applicant Guidebook section says so) because it’s not a common practice to host these records directly in the TLD’s zone and that it could potentially affect the security and stability of the DNS. It would also most certainly require an EPP extension in order to support the management of resource records. Nevertheless, if done properly, it provides compelling value for the registrants:

  • Performance - by not delegating, queries can be answered much faster in some cases (cold resolver cache) by saving one level of name servers to consult. TLD name servers are typically well-cached and have much better geographic placement network topology-wise;
  • Ease-of-use - they do not need to understand what a name server is, and can almost be oblivious to the technical details of the DNS; less things can go wrong;
  • Cost savings - save on DNS hosting.

Make Use of Uncommon Records

DNS is typically explained to the layperson as a system to help translate a human-friendly name to an IP address that computers can use to find each other. While that’s certainly the modal use case, it bears remembering that DNS is a hierarchical directory system. It is capable of storing just about any structured (and even unstructured) bite-sized information. Information in the DNS is stored in resource records, and there are resource record types for a wide variety of data, with more being invented from time to time.

A prominent example of this is .tel, which encodes directory-like data into appropriate types of resource records in the DNS. One could conceivably apply for an integrated e-commerce TLD that has DNS-based Authentication of Named Entities (DANE) built into its policies and implementation. Obviously, the DANE protocol is far from being standardized let alone ubiquitous, so a traditional CA-based fallback will always be needed. Nevertheless, it is an innovative use of the DNS and solves a real need. The registry could also invest resources to advance the DANE standardization efforts, and promote interoperability.

Multi-level Registry

In the ccTLD world, it is common for a ccTLD registry to be responsible for its country code as well as a handful of second level zones such as .com.xx, .net.xx. This is less common with gTLDs as most gTLD registries only accept registrations at the top level. Notable exceptions are .pro and .name. There are many use cases for this:

  • A brand TLD could delegate different subdomains to the relevant departments or geographic regions, and reap the benefits of a centralized domain management registry.
  • Like .name’s original idea, a gTLD could offer 3rd level domain names only, with the second level namespace springing into existence when a 3rd level domain is registered.
  • Have a clear map of the TLD namespace, codifying the policies and governance models of each second (or lower) level domain.

Enhance Security

Any sensible proposal that tries to improve the security of status quo domain registration practices will likely be met with open arms. On the flip side, it will also invite more scrutiny since a flawed proposal that has the potential to be gamed will produce a false sense of security and is arguably less secure than a simpler system with well-understood threats.

In question 28 of the applicant guidebook, “Abuse Prevention and Mitigation”, ICANN has a few suggestions:

  • registrants authentication methods
  • multi-factor authentication
  • multi-party change authorisation

Bundle Services

This is probably the most obvious one. Essentially, the goal is to make it painfully easy to register and start using a domain. Most Internet users are confused by how the DNS works, and have no idea where to look when something doesn’t work. All they want is a web site, and an email address. The problem is especially acute in certain industry verticals where the Internet is simply not its bread-and-butter. A registry-led effort to provide a consistent and integrated user experience from the registration of a domain to the activation of services will most definitely help with TLD adoption.

Marketing Techniques

Invitation-only Launch

This may sound gimmicky, but if executed properly it could provide limited beta testing and create a healthy iterative feedback loop that is at the heart of innovation. In addition, it’s also a great way to involve early adopters and build a strong community around your TLD!

The idea is to launch the TLD in phases, and introduce social and gaming elements with a strong marketing strategy associated with each phase.

Parting Thoughts

ICANN wants to enhance competition and the only way for new gTLDs to compete in a COM-dominant world is to innovate. Innovation is limitless; it just takes a bit of research and creative thinking to arrive at a set of services that complements the TLD’s market. Every new gTLD is effectively a startup, and Steve Job’s message couldn’t be more apt: “Stay hungry, stay foolish.”

By Wil Tan, CTO, Cloud Registry -- innovative TLD registry back-end provider

Filed Under


Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



Threat Intelligence

Sponsored byWhoisXML API


Sponsored byVerisign

Brand Protection

Sponsored byCSC

Domain Names

Sponsored byVerisign

IPv4 Markets

Sponsored byIPv4.Global

New TLDs

Sponsored byRadix