ICANN has spent years trying to figure out what to do with domain name variants, strings that look different but mean the same thing, for some definition of “the same.” They’ve been trying to deal with them in second level domains for a decade, and are now working on rules to allow variant top-level domains.

Unfortunately, variants don’t work. The problem isn’t putting them in the DNS; it’s that once they’re in the DNS, they don’t work anywhere else.

Let’s pretend for a moment that upper and lower case letters are traditional and simplified Chinese characters. If I had a domain name abc, then ABC and AbC would be variants of it. Nobody expects mixed variants to work in a single label, so if I registered abc.def, then likely variants would be ABC.DEF and maybe abc.DEF and ABC.def.

What do we have to configure to make this work? The first and most obvious place is the DNS for all the names, abc.def and ABC.DEF. There’s no way in the DNS to say that this set of names is the same as that set, so if you’re lucky your DNS provisioning system has some way to tell it to put the same records in the variant name’s zone that it puts in the main name’s zone, or more likely you have to cut and paste. But wait, you probably don’t want exactly the same records in both zones. If under the main name abc.def you have a web server named www.abc.def, in the variant do you want it called www.ABC.DEF or WWW.ABC.DEF? Probably the latter. Now either you have to put both www.abc.def and WWW.abc.def in the main zone so both www.ABC.DEF and WWW.ABC.DEF are in the variant zone, or you now need rules that say if names within the zone have variants, rather than copying them, use the variant instead. There are even more complex special cases, but you get the idea.

Now let us turn our attention to web servers. In most cases, a web server needs to know all of the names that refer to it, with configuration info for each name. (Unknown names tend to show up as either an error page or “coming soon.”) This means that every name defined for the server in the previous step has to be configured into the web server along with where to find pages under that name. Depending on the application, all of the names might show the same web site or they might differ depending on the name, e.g., make the pages match the simplified or traditional name. This generally has to be done by hand, or maybe with ad-hoc scripts that pull the names out of the DNS zone files if the person configuring the web server has access to the name servers in the step.

If the web server supports HTTPS, as most do now, there’s an additional step: all of the variant DNS names need to be in a signed TLS certificate, either one certificate with all the names as alternate names or one certificate per name. There’s no tooling for this, either.

For mail servers, the configuration is similar but a little easier, since all of the variant DNS names can have MX records pointing at a single name for a single mail server. But that server again needs to know what all the variant names are that it’s expected to handle, and what to do with them, probably deliver to the same mailboxes as the main domain.

At this point the reader may be thinking, this seems awfully complicated, and it is. It’s tedious and difficult to do by hand, and hard to get all the details right. (I’ve messed up the simpler problem of configuring a few of my customers’ vanity domains just to use the exact same web and mail configuration.)

We can easily think of ways to automate most of the work. One would be standard file formats to describe a registered domain name, its variants, set of DNS names under the registered name, and the web and mail services it supports. Tools could translate that description into the configurations for DNS servers, web servers, mail servers, and so forth. Another approach would be to augment the DNS so a DNS server can answer “what are all the variant names for this main name”, which web and mail servers could use to automatically provision the variants for each main name.

The key point, though, is that none of these tools exist. It’s not for lack of awareness of the problem. People have been pointing it out for years, such as last September in the ICANN Business Constituency’s comment on IDN Variant TLDs.

Given that we’ve known about the configuration problem for a long time, we know how to build tools to address it, and after a decade the tools don’t exist, the obvious conclusion is that nobody cares.

It’s quite reasonable to worry about confusion among variants, and it could be unfortunate if different variants of a single DNS name were controlled by different entities. Blocking variants solves that, delegate one version of a name and none of the rest. But having multiple variants active simultaneously, either at the second level as we have now or as TLDs as ICANN’s proposing? Forget it. The users don’t care, because we’ve seen that nobody wants them enough to make them work.