This is by no means a new issue. It first appeared with the introduction of the .info TLD. Before that TLDs were only two or three letters long, and many validation routines could not cope with the 4 letters of .info. At the time, ICANN had developed a testing tool which allowed developers to test if their code took into account the requirement for 4 letters. Still, you find today on the Internet tons of library routines that do not support 4 or more letter TLDs.

Some of these routines also rely on a hard-coded list of TLDs. Even today, I sometimes find that some web sites cannot deal with my .eu domain, which was introduced 4 years ago.There are hundreds of thousands of these routines written in Javascript, PHP, Perl, ColdFusion, ASP and just about any programming or scripting language you can think of.

In the Draft Applicant’s Guidebook to new gTLDs, ICANN has clearly indicated that it does not guarantee universal acceptance of the new TLD, and rather place the burden on the registry operator to educate its customers. This made sense during the previous new TLD rounds, where there were only a few added, one at a time and with long intervals between them.

With the new gTLD round, ICANN plans to add a lot of TLDs, potentially at very close intervals, if not at the same time. The figure most often heard is 500. That is a quantum leap forward. All those hard-coded lists deeply buried in software will need to be updated. It will not happen overnight. It may take years. This time also, we are throwing into the mix TLDs which could be long strings, like .coca-cola. We are also adding IDN (internationalized Domain Names) in non-ASCII characters, which will be a real issue with all environments that do not process double-byte strings. There are tons of legacy applications that do not support that, and some never will.

The good news is that programmers do not need to worry about their job. There is plenty of work ahead. The bad news is that most of them are not aware of these upcoming TLDs, let alone the implications it will have on the code they wrote, or the code they use and written by someone else.

So, it does not make sense now for ICANN  just to say it is someone else’s problem. If the new gTLDs cannot be processed on the client platforms, this will mean their acceptance by the user community will be low. This means less revenue for registries, registrars and finally ICANN. This would also mean a partial failure of the whole new gTLD program, for which ICANN will be accountable for. It could cost ICANN much of its credibility, because it would not be the failure of one specific TLD for which the registry could be blamed, it would mean the failure of several, all for the same reasons.

Hence, I suggested today to ICANN to plan a workshop at the Seoul meeting to help identify these issues, so that clear guildelines can be given to the software community and an awareness campaign can be launched. It is absolutely crucial to identify the issues, the amount of work they represent and the time it will take to fix the code before the introduction of these new top level domains.

Unfortunately, this second draft version of the applicant’s guide does not yet address major concerns in the process.

As stated in the previous comments round, it is fundamentally wrong to assume that all new gTLD applicants will use the .com model of mass market approach for domain names. Both the amount of the application fee and the yearly registry fee imply that the registry will need to sell as many domain names as possible, favouring numbers over quality. This is the wrong approach with regard to community-based TLDs.

The amount of the application fee should be reduced, as it may discriminate against less financially resourceful applicants, such as communities. While I understand ICANN may want to prevent frivolous applications with a high application fee, it nevertheless excludes from the process a lot of potential serious applications targeting a limited community.

It is unfair that only the applicants of the first round would have to cover the past costs of the new gTLD development program. On the other hand, it is difficult to guess how many applications will be submitted on each round. Because these costs have already been expended and that ICANN clearly states that whatever is recovered will be transferred to a reserve fund, it is therefore suggested to simply drop the $26,000 that represents the incidence of gTLD development program cost on each application.

Note that this request for a large up-front investment in the application process is orthogonal to the expectation of ICANN for the applicants to demonstrate the availability of continuation funding. Whatever capital will be invested in submitting the application will not be available in the future. Hence, ICANN’s financial expectations at the application stage may plant the seed of future registry failure.

Further, payment of the application fees in several installments should be offered to TLD applicants. For those applicants that need to submit a strong business plan to their investors, having a pay-as-you-go fee through the application process will make it easier to convince investors.

ICANN should also consider postponing for two or three years the collection of the annual registry fee, to allow new gTLD operators to start operating in a financially sound context, with no loans and other debts that may compromise the start-up of their activities. On the short and medium term, this help new registries to become more solid and will be beneficial for the the long term stability of the DNS space.

The fact that ICANN only allows for payments to be made in USD places a high risk on the business plans of those applicants that work in other currencies. As suggested elsewhere, ICANN should accept payments in other
currencies, at a rate fixed at the time the applicant’s guidebook is published.

There is still a fundamental contradiction in using an auction model as a last resort for community-based applications. By definition, community-based applications will target smaller communities and use a cost-recovery model, rather than a purely commercial one. For the winner of the auction, this will mean recovering its costs through increasing the gross price of registrations. As a consequence, the number of domain names sold may be reduced and the newly launched registry may not meet its business plan. Ultimately, auctions may also be a cause of registry failure.

On a similar note, I had the pleasure to co-chair the At-Large working group on DNS security issues, with came up with a statement we were reasonably happy with.  The best part was actually today, where we received kudos from other parts of the community, which tend to view the At-Large more as a political obligation of ICANN that a really useful component.

I hope this will both help the recognition of the At-Large as serious players in the ICANN context, but also motivate the At-Large members, who are often depicted as jerks and end up believing they are.

He spent a lot of his time to inform utility companies, banks, insurance companies, administrations, etc of his address change, BUT he did  not tell his registrar.

You see, his registrar sends him every two or three years an e-mail asking to pay for the renewal. He then gets the invoice through e-mail. No postal mail is sent at all. That is all he knows about the domain name he uses. Other than that, it just works. E-mail to his domain gets delivered,  his web site is reachable. What else should he care about ?

As it stands, he should really care about updating his records with his registrar. A whois query on his domain name now returns a false postal address. This honest citizen now has the crowds of those hideous people who leave false information in the whois. Surely, law enforcement authorities may think of him as a terrorist covering his tracks. Intellectual property lawyers may think he is stealing somebody’s trade mark. According to term 3.7.7.2 of the ICANN Registrar Accreditation Agreement, he risks seeing his domain cancelled.

The sad truth is that this nice guy actually does not even know his $10/year domain is at risk. In the unlikely event his domain name gets cancelled, pleading the good faith will not help a lot. He may not notice it until he gets a phoen call telling himl the e-mails to him are undelivered.  It will be too late to react, because human errors by uninformed customers are not taken into account in ICANN policies. So, before he says  “I should have known” maybe I should tell him.

There are a few lessons to be learned from this experience. First and foremost, the tools are now not yet ready for a general audience. If the dnssec-signzone man page is your favourite late night reading and if you like Unix shell scripting, you will have plenty of fun. On the other hand, if you are an overworked system administrator being told by the boss to ‘By the way, please switch on DNSSEC before your leave this afternoon’ , you are out of luck.  The best tool I found to make it a bit easier is ZKT.  However, this is not the friendly Graphical User Interface you would expect.

Lesson 2 is ‘check you secondaries’. I had secondaries with Xname.org. Although these nice folks provide good and free DNS service, their machines do not answer DNSSEC queries. Hence, I had to switch to new secondaries.

Lesson 3 is that few DNS resolvers currently support DLV. Bind does. Unbound will in the next release (the current development code already does).

Lesson 4 is that the current system to register a domain in the DLV does not seem to scale and looks more like a proof of concept. It would need to be seriously industrialized to be helpful for a bigger deployment.

Lesson 5 stems from 4 above. The whole thing would be a bit easier to deploy if the root zone was signed. But this is another debate.

Many thanks to the folks at NLNet Labs and the RESTENA Foundation for providing DNS secondary service, and ISC for running the DLV registry.

One possible issue may be with vanity gTLDs like apple, ebay etc. Some expect that every Fortune 1.000.000 company will apply for its own TLD.  My guess is rather the Fortune 1.000 for a start, but this does not change the nature of the issue, ie. those companies may want to use email addresses like user@tld.

The current standard is defined in RFC 2821 as such:

2.3.5 Domain

A domain (or domain name) consists of one or more dot-separated components.
[...]
The domain name, as described in this document and in [22], is the entire, fully-qualified name (often referred to as an “FQDN”). A domain name that is not in FQDN form is no more than a local alias. Local aliases MUST NOT appear in any SMTP transaction.

Hence, if either the mail client or the MTA expect to see a dot in the domain name and there is none, its behaviour may be unpredictable. The new gTLD context is addressed in the draft RFC2821bis, which states:

2.3.5. Domain Names

A domain name (or often just a “domain”) consists of one or more components, separated by dots if more than one appears.

Unfortunately, the current software implementations are based on the original RFC2821, not the revised draft, which is currently put on hold by the IESG.

There may be a lot of software out there that would treat user@tld as a local e-mail address (i.e. not a Fully Qualified Domain Name). It is not unusual to still find inside company data centers old internal SMTP gateways which have been quietly doing their job for a long time and were not updated for years.

Some pointed out on the IETF list and elsewhere that we have had for 10 years a ccTLD that accepts e-mail in the form of user@ai.  It is one thing that the behaviour of a small ccTLD apparently generated no complaints. It is another that a large number of companies may want to force the Internet to adapt to their advertsing strategy.  At this stage, we have no meaningful statistical evidence that the currently deployed software is able successfully deal with e-mail addresses that are directly under a TLD.  I am not aware of any study by ICANN’s SSAC on that matter.

In any case, when ICANN will go into an agreement with the registries operating the new gTLDs, it has to be very clear that compliance with existing technical standards is a must, and not respecting them would be a breach of contract.

It would be problematic for the end users/customers/consumers if companies started advertsing e-mail addresses like support@mycompany , if the delivery of the e-mail depends on the ability of some software to be non-standards compliant.

On a related note, my colleague Franck Martin pointed out to me last Friday that browsers usually append “.com” to any domain name they consider incomplete. Again, this is going to break a lot of software that have hard-coded lists of TLDs.  Similarly, there are also millions of web forms out there that check for malformed e-mail addresses based on the presence of a dot and/or hard-coded lists of TLDs.

There is still a long way to go in terms of getting the proposal ready, but I this this one is a winner. First of all, sport is one of the most popular human activities. It transcends cultures. The.SPORT community is large and diverse, from small clubs to large international federations. There is also a large industry for which.SPORT is an essential element of its communication strategy. Think about the media. Television networks may be interested to have dedicated web sites about.SPORT.

Unlike existing sponsored and unsponsored TLDs, .sport is also meaningful in languages other than English. The word “sport” originates from the ancient French verb “desporter” and was later adopted by many European languages and others. “Sport” just means.SPORT, whether in English, French, German, Dutch, Afrikaans or many others languages.

There is a provisional web site at http://www.dotsport.info, developing some of the ideas above.

If you like the idea, I would of course most welcome your partnership. Let’s talk about it at ICANN Paris.

Released to open source developers by NLnet Labs, Verisign, Inc. (NASDAQ: VRSN), Nominet, and Kirei, Unbound is a validating, recursive, and caching DNS server designed as a high performance alternative for BIND (Berkeley Internet Name Domain). Unbound will be supported by NLnet Labs.

It is good news for the Internet as a whole there is another alternative to the venerable Bind. With a 75% market share, this means an exploit in Bind might cause serious trouble for a lot of people. With more alternatives, we mitigate the risk.

I have not tried it yet and certainly my experience on this small site will certainly not be representative. If you want to give it a try, download the source from http://unbound.net

I built RPMs for RHEL5 / CentOS 5 (WARNING Totally untested ! use at your own risk)

unbound-1.0.0-1.i386.rpm
unbound-1.0.0-1.src.rpm

See also the static page with more details for geeks.

Update: I have been using this RPM over the last two hours in lieu of Bind for local resolving and can report it works as intended

The web interface my registrar (Gandi) uses does not allow IPv6 addresses. Their support desk informed me that they do not yet handle IPv6 addresses in their web forms.

There is obvious workarounds, of course. One is to assign both a IPv4 and a IPv6 address to the DNS server, as long as it is in under another domain. However, if the DNS server is under the same domain, a glue record would need to be inserted in the TLD zone file. This is currently not possible, at least with the tools provided to the average domain name user.

I am really looking forward to the IPv6 workshop that ALAC is planning at the Paris meeting of ICANN next June and see with other constituencies how these showstoppers can be addressed.