How to add internationalized ccTLDs to the root zone?

The APTLD (Asia Pacific Top Level Domain Association) this week released a statement on how introduction of internationalized top level domain could be initiated. You can find the paper here.

This document got a lot of traction at the ICANN meeting, but it has a few flaws that are very unfortunate. For example, if one look at the first bullet: Allow each existing ccTLD to manage one additional country or territory specific ccTLD in a recognised non-ASCII script of their country or territory.

You will see a few problems:

  1. It only gives one domain per existing registry, and this has as an implication that the ones that need two or more will not get what they need.
  2. It gives the existing registry a ccTLD, and that have impact on competition.
  3. It only gives a domain to registries that want a domain using non-ASCII script, and that has impact on the internationalized ccTLDs that do not have any non-ASCII codepoints in them.

There are many reasons for needing more than one domain:

  1. If the ccTLD represents a territory that have more than one language.
  2. If the internationalized ccTLD chosen can be written in more than one script.
  3. If the internationalized ccTLD chosen can be written in more than one way using the Unicode Character set where the local community decide the different versions are to be treated as equal.

Giving the domain to the existing registry of course have impact on competition. I guess that do not have to be explained. Example of a ccTLD that might want an internationalized ccTLD that is in ASCII include Germany and Canada.

Many of my issues are adressed with comments like we need to start sooner rather than later, we solve the 80/20 problem, the rule only has impact on few ccTLDs.

What to do?

I have advocated a completely different solution. This suggestion also addresses some issues not mentioned in the paper.

  1. Issue an RFI where existing TLD registries and Governments can request their non-binding interest in certain strings for internationalized TLDs. The RFI response have to include some mandatory information, including explanation why that string was chosen, what support exists in the Internet Community etc, part from the technical information what label is needed, whether an alias is requested (and to what) or a full delegation and why. What is important is that the statement of interest include description of what cooperation exists in the IDN area with other ccTLDs using same language(s) and/or same script(s).
  2. In the first round, only add internationalized ccTLDs that are aliases to existing ccTLDs. Exactly how this alias is to be implemented in DNS is up to the technical community and specifically RSAC and SSAC. Alternatives include direct insertion of DNAME records (RFC 2672, updated by RFC 4592) in the root zone and delegations to zones that include only one record, the DNAME with the same owner as the SOA for the zone. The latter so that root servers do not have to synthesize responses (when needed).
  3. When a label is to be added, use a special review committee similar to the ICANN RSTEP process. The sole purpose of this review is to verify that the set of codepoints chosen is sound.
  4. Not until all aliases are added to the root zone delegation requests are accepted.

The reasoning behind this is to still have a slow start similar to what is proposed in the APTLD paper, but with different barrier(s). By adding aliases, there is no need to appoint a registry (explicitly or implicitly), there is no discussion in the registry on dispute resolution process between registrants in the ccTLD and internationalized ccTLD, and no need for a sunrise period when the domain is added (among other things). One still have the problems of finding what strings to add for what ccTLD, but by starting the process with an RFI, one can gather data on what interest exists, and for what, and the result of the RFI should be possible to make changes to the actual assignment of labels.

**Updated:**A comment point out this is only an interim step. Yes, absolutely. I understand that. But the problems with all interim solutions is that you have to have some rule that say no to some of them that want to have an internationalized TLD now. I think an interim step might be needed, but, my point is that (a) we do not know that unless we do an RFI, and (b) a better interim step is to first only create aliases, not do delegations.

Updated: Many people ask me what I mean by “alias”. It can be interpreted differently depending on whether you know DNS terminology or not, and this is exactly why I choose this term instead of talking explicitly about how to actually implement it. But, as you can see above, I managed to start talking about implementation anyway.

The intention of talking about alias in this context is that I wanted just to point to a solution where resolution of foo.bar will give exactly the same result as resolving foo.baz if bar is an alias for baz.

A normal alias in DNS is implemented via the CNAME RRType, but it can only be an alias for a lead node in the namespace. For an alias higher up the hierarchy we have the DNAME RRType. There are though many bad things and risks related to the DNAME record. The two more important ones are:

  • That one can not control how the pointers in the namespace that are created are pointing, i.e. the namespace might end up being corrupt.
  • For backward compatibility the DNS server might have to synthesize responses.

I am not worried if the DNAME refer between names in the same level in the namespace. That for example we have the following (in any zone): foo. IN DNAME bar. The second issue is bad for the root servers. One do not want them to synthesize responses. To get around that one can have the following in the root zone (SOA and other RR missing): $ORIGIN . foo. IN NS a.dname.root-servers.net. foo. IN NS b.dname.root-servers.net. foo. IN NS c.dname.root-servers.net. foo. IN NS d.dname.root-servers.net. foo. IN NS e.dname.root-servers.net. foo. IN NS f.dname.root-servers.net. foo. IN NS g.dname.root-servers.net. foo. IN NS h.dname.root-servers.net. foo. IN NS i.dname.root-servers.net. foo. IN NS j.dname.root-servers.net. foo. IN NS k.dname.root-servers.net. foo. IN NS l.dname.root-servers.net. foo. IN NS m.dname.root-servers.net. And in the zone foo.: $ORIGIN foo. foo. IN DNAME bar. The idea though is that with an alias, one do not have to do a delegation with whatever that implies. Not appointing a registry, not forcing domain name holders to (re-)register in this new domain, not invent a dispute resolution process for the new domain (specifically between the two domains) etc.

Adding new strings to the root zone include enough policy decisions anyway (what string(s) to choose), so removing some of them is I think a good thing. Specifically if it completely remove the ability to register new domain names. That should kill much of the interest in internationalized TLDs that come from the same part of the domain name business that like tasting.