Click the comments link on any story to see comments or add your own.
Subscribe to this blog
21 Apr 2019
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.
comments... (Jump to the end to add your own comment)
Add your comment...
Note: all comments require an email address to send a confirmation to verify that it was posted by a person and not a spambot. The comment won't be visible until you click the link in the confirmation. Unless you check the box below, which almost nobody does, your email won't be displayed, and I won't use it for other purposes.
My other sites
A keen grasp of the obvious
Coalition Against Unsolicited Commercial E-mail
© 2005-2020 John R. Levine.
CAN SPAM address harvesting notice: the operator of this website will not give, sell, or otherwise transfer addresses maintained by this website to any other party for the purposes of initiating, or enabling others to initiate, electronic mail messages.