Starting in January 2012, ICANN — whose role is to oversee the huge and complex interconnected network of unique identifiers that allow computers on the Internet to find one another, including the Domain Name System (DNS) — will allow applications from any company, city or organization in the world to manage their own generic top-level domain (gTLD). This new gTLD program will enable an unprecedented level of competition, and potential innovation, in the domain name market. But will this expansion cause security “mayhem” on the Internet, as some onlookers have predicted? Does ICANN’s decision open the door to new attacks against corporate networks?
No.
Recent news reports and commentary have suggested that criminals could take control of certain gTLDs to execute widespread DNS-based attacks. “What would happen,” some commentators asked, “if a bad guy were delegated a numeric gTLD?” Or “How would software applications be able to tell the difference between a domain name and an IP address? If criminals successfully obtained the gTLD ‘1’, would they be able to set up 127.0.0.1 as a domain name and steal traffic destined for local resources?”
These commentators also speculate that ICANN will start to delegate “dotless” domain names, such as branded gTLDs that lack a second level. Imagine simply typing “coke” or “.coke” into a browser address bar and being taken directly to Coca-Cola’s website. It could be convenient, but, due to the way browsers handle domains without dots, some have suggested that there could be a security risk if a criminal were to receive the delegation for .localhost or .lan, for example.
Fortunately, these suggestions are largely FUD — fear, uncertainty, doubt — based on a misunderstanding of the processes in place to successfully apply for a new gTLD.
This is perhaps understandable. The ICANN Applicant Guidebook, which sets out the rules for applying for a new gTLD, is more than 350 pages long, and has been revised at least seven times over the last few years. Not many people outside of the domain name industry have read it enough times to fully comprehend all of its subtleties. So while the confusion may be understandable, it does not give the FUD merit.
First, it’s not correct to state that ICANN has no rules prohibiting the delegation of top-level domains on security and stability grounds. On the contrary, ICANN has refused to delegate top-level domains on security grounds more than once, and will continue to do so in future. One of the organization’s fundamental mandates is to ensure the continued secure and stable operation of the Internet’s addressing systems.
Every new gTLD application — and every applicant’s background — will also be extensively vetted to ensure it does not pose a risk to the Internet. The whole process, which takes months, will be buttressed by a period of public comment that interested parties should be able to use to highlight any security concerns they have identified with such a gTLD application. Further, gTLD applicants might benefit from the prior experience existing registry providers have in working with the ICANN application processes, especially during the technical vetting segment of the evaluation process. New providers and new competition are emerging in this market at a rapid pace, as well.
The Applicant Guidebook contains a list of strictly prohibited gTLDs, which includes strings such as “local,” “localhost” and “test.” New gTLDs that pose a risk to local networks will not be approved. ICANN’s Security and Stability Advisory Committee (SSAC), which consists of internationally renowned security and network experts, will have an opportunity, if it chooses, to comment on each gTLD application, prior to approval.
Neither has ICANN ignored the potential problem of confusing domain names with IP addresses. The Applicant Guidebook specifically disallows numeric-only strings and strings of fewer than three characters. There is no danger of a “.1” gTLD being approved, so there is no danger of somebody registering the domain name 127.0.0.1 or similar and using it for nefarious purposes.
Problems that could arise due to “dotless” domains have also been addressed by ICANN. To have a gTLD resolve on the Web without a second level domain, a registry would need what is sometimes known as an apex A record — an A or AAAA record registered in the TLD for its entire zone. By default, ICANN does not allow A or AAAA records in the root or TLD zones, other than the glue records necessary for the DNS to function.
One valid concern which recent discussions about dotless domain names have highlighted — and which ICANN has long acknowledged — is that applications from different vendors lack consistency in how they recognize and process top-level domains. For example, today there are a small number of country-code TLDs with apex A records, but whether you are able to resolve them without a second level or not depends very much on which browser and operating system you use.
There’s a pressing need for developers of all Internet applications, not just Web browsers, to wake up to the expansion of the gTLD space. With potentially hundreds of new TLDs going live, some as early as the end of 2012, lack of support in applications could result in a degraded user experience. If an email address or URL is rejected by a validation algorithm because the TLD is not recognized, that’s bad for the Internet’s end-to-end interoperability. Even relatively small, user-friendly software features, such as automatically rendering a URL clickable in a chat window, will need to take into account the introduction of new gTLDs.
Adding foolproof TLD verification is a trivial matter for developers. Every day, an authoritative, machine-readable list of all live, delegated TLD is published, which can easily be incorporated into software. ICANN has also made several reference implementations for TLD acceptance available for free on its website. If your software requires a more granular view, Mozilla maintains the longer Public Suffix List, which also includes a breakdown of all TLDs into their publicly available second-level domains, such as .co.uk and .co.in, where applicable. Bluntly, if your application is hard-coded today to only recognize certain well-known strings as TLDs or if it uses best-guess heuristics, you’re probably doing it wrong.
The new gTLD round requires all new domain name registries to be standards-compliant, implementing newer security protocols such as DNSSEC, as well as financially and technologically stable. Applicants must undergo a criminal background check. While not everyone may be happy about the expansion of the domain name space, it is nevertheless prudent to note that security and stability is not an afterthought in this process.