The DNS resolvers used by default by Belgacom’s Internet customers lack EDNS support, according  to the test performed from OARC’s DNS Reply Size Test Server

hiram$ dig +short rs.dns-oarc.net txt @195.238.2.21
rst.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net.
"195.238.24.113 DNS reply size limit is at least 490"
"195.238.24.113 lacks EDNS, defaults to 512"
"Tested at 2010-08-15 11:00:01 UTC"

hiram$ dig +short rs.dns-oarc.net txt @195.238.2.22
rst.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net.
"195.238.25.113 DNS reply size limit is at least 490"
"195.238.25.113 lacks EDNS, defaults to 512"
"Tested at 2010-08-15 11:00:11 UTC

Hence, if you expect correct DNSSEC or IPv6 responses, you would be better off using alternative DNS resolvers, like OARC . Obviously, the Belgacom DNS resolvers do not return RRSIG records and do not set the AD bit. This is very disappointing, given that the DNS root is now cryptographically signed and so are several top level domains also. It is difficult to believe, a company claiming to be the number one ISP in Belgium is unable to implement a 11 year old standard defined in RFC2671, and a standard feature in all DNS resolver software since then.

The good news is that their BBOX-2 modem can proxy a EDNS query and response, when used with correctly configured DNS resolvers. As demonstrated below, the AD bit is set, meaning the DNSSEC response is valid.

; <<>> DiG 9.6.0-APPLE-P2 <<>> +dnssec +multiline -t ns gov. @XXX.XXX.XXX.XXX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46617
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096

Many software applications rely on validation routines to check the validity of domain names. By validation, I mean here to test the string submitted by the user and see if it matches a pre-defined pattern. A typical example are web forms that need to validate e-mail addresses.

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.

These are the comments I sent today to ICANN

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.

I was appointed to the ICANN’s Security and Stability Advisory Committee recently and I am very proud of that. This group of esteemed security experts are a crucial element of the ICANN community, because their task is to identify threats to the good working fo the Internet and suggest possible remedies. This is not a glamourous position, but rather behind the scenes work in the interest of the Internet user community at large.

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.

One of my relatives moved into a new house the other day. No big news, except he is a registrant of a generic domain name.

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.

Last year, I started signing the DNS records for this domain (and ISOC.lu). At the time, it was what is called an ‘island of trust’ in DNSSEC-speak. Being a firm believer that one should eat his own dogfood, I took this now one step further. Both domains vande-walle.eu and ISOC.lu are now added to ISC’s DLV registry. In addition, they are also in UCLA’s Secspider DLV repository. DLV stands for Domain Lookaside Validation, it “is a mechanism for publishing DNS Security (DNSSEC) trust anchors outside of the DNS delegation chain”, according to RFC 5074.

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.

The recent decision by ICANN to start a  new round of applications for new generic Top Level Domains is launching a round of questions on the IETF side about its consequences.

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.

The annual EGENI event in Paris will take place on the 20th June 2008, right before the ICANN meeting, at the same venue.  This is always a very interesting event.

OK. Now my lawyer has given me the green light, I can officially announce I am working on a proposal for a .sport TLD, to be submitted to ICANN for consideration as a new TLD next year.

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.

From the press release: Unbound – a new open source alternative to the BIND domain name system (DNS) server– makes its worldwide debut today with the worldwide public release of Unbound 1.0 at http://unbound.net.

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

Now that ICANN has added IPv6 name servers for the root zone, and that many registries have enabled IPv6 on their DNS servers, I thought it would have been easy to update the DNS records pointing to my domain to mention a IPv6-only DNS server. This way, we could have native name resolution end-to-end in IPv6. We are not there yet, it seems.

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.

EuroDNS, the Luxembourg registrar, used its well attended New Year party last Wednesday to invite the Minister of Telecoms, Jean-Louis Schiltz to talk about a law voted at the end of December 2007. According to the Finance and Budget Commission Report on Draft Law 5801, «Revenues generated from use of, or license to use, a Domain Name are exempted from Luxembourg corporate taxes up to 80% ».

This is of course excellent news for EuroDNS, but also for domain name investors, both in Luxembourg and worldwide. ICANN will probably launch a RFP for new TLDs next June in Paris. As such, someone took the opportunity to mention that Luxembourg would be an ideal place to launch a new gTLD. The proposed gTLD floating around seems so obvious it is surprising no-one though about it before. At this stage, I cannot expand any further until this proposal is formalized, but stay tuned for more news.

Netchoice, a lobbying group for the e-commerce industry had a strange reaction on the failure of the GNSO working group on whois to reach a consensus.

After all, they say, “Privacy concerns with Whois that were identified years ago have already been addressed by in the marketplace“. In other words, if you want privacy for your domain name registration, you need to pay extra for proxy services.

I understand that the industry wants to always sell more services. That means money for them. However, those proxy services were developed as a workaround to the current whois system, which does not protect privacy, and in wait for a more global solution.

But of course, the main question is that privacy is a fundamental human right under article 12 of the Universal Declaration of Human rights. As far as I know, human rights are for everyone, not just for those who can pay for it. What is next ? Will we need to buy the right for freedom of expression or to organize in trade unions ?

As I am not able to attend the Los Angeles meeting of ICANN, I sent the following comment to the GtLD workshop:

There have been numerous comments periods over this report in the past and what I want to state is not new, but it seems it has not been addressed in the report.

Basically, the report is based on the assumption that the current model for gTLDs is the only possible one. It assumes that domain names will be sold on a mass market, mostly through intermediaries, and that this will generate a profit.

Was it ever envisaged that there could be other business models that do not fit into that mould ? There are several but, unfortunately, it will be next to impossible to try them out. There may be TLDs for very small communities, or an advertisement driven model in which domains are given out for free. A dynamic DNS service, like DynDNS.org, but performed a the TLD level could not accommodate the registrar model.

Regarding the Application Fee for proposed new gTLDs: while the report states that “Implementation Guideline B suggests that application fees be designed to ensure that adequate resources exist to cover the total cost of administering the new gTLD process, and that application fees may vary for different applicants”, the criteria that will be applied to various applicants are not yet clear, and this is a sensitive area. Will that be a one-time upfront cost ? How do we set it to avoid eliminating good ideas from the start of the process and privilege those incumbent players with deep pockets ? Could that be a per domain name fee to be paid over several years once the TLD is up and running ?

In short, the way the application fee is implemented will be a key factor for the success of new business models.

There is currently a discussion going on between Milton Mueller and Patrik Fältström over the deployment of DNSSEC on the root servers. I think the discussion exemplifies the difficult relation between those who develop standards and those who use them.

On the one hand, Milton points out that the way the signing of the root zone will be done will have a great influence on the subjective trust people and nation states will have towards the system. On the other hand, Patrik states that “DNSSEC is just digital signatures on records in this database”. Both are right, of course, but they do not speak the same language. It is just like saying that a spam e-mail which is RFC (2)822 compliant is a legitimate one. From a technical point of view, it certainly is. From a social point of view, it is still an annoyance.

There is this often expressed feeling in the engineering community that technological choices are politically neutral by design. Nothing is further away from truth, as has been demonstrated by people like Lawrence Lessig. The development of standards is done exclusively by companies. Notice, for example, that those attending IETF meetings do it on company time and budget. The actual users are absent. The logic that says that IETF meetings are open to all is flawed by the fact that an average IETF meeting will cost you around $1500 to attend. Hence, there is an economic barrier to the participation of individuals. Additionally, the influence you might have on a process is proportional to the consideration you get from your peers. Newcomers need quite some time to get accepted by the community, especially if they are not engineers.
Companies are driven by the market. If there is no potential market, there is no need to develop a new standard. A good example of this is the fact that you cannot yet send an e-mail to, say, brønshøj@københavn.dk or addresses in native Cyrillic, Arabic or Asian scripts. Pretty soon, the right hand side will be dealt with, thanks to IDNs. But the use of non-ASCII character sets on the left hand side is still a not standardized. The EAI working group in the IETF has only been launched a few months ago. Why did it take so long ? I guess that the need for this has only appeared in recent years. As long as the Internet was mainly used by the American / Western European world, being restricted to 7 bit ASCII was not much of an annoyance, if at all. Now that the user base has enlarged to include countries that do not use the latin alphabet, it becomes a hot topic. However, it will take years before this can be implemented in the software we use every day. Notice, for example, that most operating systems today still require the user name to be in 7 bit ASCII.

Similar issues exist with RIRs, where again the actual IP address users are absent for the same set of reasons detailed above. However, which IPv6 prefix is going to be allocated by your ISP to your home network in a few years from now is an important one. Yet, those who are active in policy development at the RIR level are those very ISPs. The policy will be related to their commercial interest, which may – or may not – match the user’s interests.

End users are represented in ICANN. I am the first to admit that ALAC may be far from perfect, but it has the merit to exist and we can improve it. Isn’t time for a similar concept for the IETF, the RIRs and all those bodies that have a crucial effect on our user experience while using the Internet ? Being closer to user needs, without the filtering of the marketing department, may help prioritize the future developments.

There is a some parallel that can be drawn between the current dispute on the .EH TLD for Western Sahara and the .VL application. In both cases, the process is being used for political purposes to serve a goal for autonomy or independence. I am not taking sides on the .EH issue, as I do not feel I have enough information to have a meaningful opinion. On .VL however, I think that the 20+ years I spent in Flanders can give me enough background.

In the case of the .VL, there is a public image, posted in English on the ICANN web site, and a quite different one posted in Dutch on the proponents web sites. Some translated extracts, for the benefit of those who do not understand Dutch:

Why a .VL, according their web site:

It is all about being recognized, mostly by the international community. Flanders does have foreign affairs responsibilities, but try to explain simply to Israël that Belgium is made of regions and communities and that you are the Minister of foreign affairs for Flanders and not for Belgium. A specific TLD would enhance the visibility of Flanders in the world, and this can only be positive.

It is clear here that this is about political visibility and not about spreading a culture, like .CAT does. Indeed, this is well in line with the political agenda of the proponents, the Jonge Vlamingen group, which states on their web site (potentially racist humor deleted from the text):

Jonge Vlamingen wishes to promote the separation of Flanders (ed: from Belgium)… We want to build a network where young Flemings who choose for Flemish independence can meet.

As has been explained in a previous post on the subject, other organizations supporting the project have a similar agenda.

My advice to the ICANN community, should this proposal be formalized, is to be aware of the fact they would actually be used to serve a political agenda, rather than a cultural one. The issue of regional autonomy (and now independence) has been on the Belgian political agenda for nearly a century. This is a very sensitive and complicated matter. ICANN would be well inspired not to join the mess.

Now that Catalonia got its .cat domain, other regions are coming up with similar requests. One of those is lead by a group of associations from the Belgian Flanders region, claiming a .VL top level domain. The Jonge Vlamingen association is a nationalist group wishing to make Flanders independent from Belgium.

However, among these associations are also several hate groups. Voorpost is well known for its pro-nazi sympathies and propaganda. The Nationalistische Studenten Vereniging is an extreme right student group. One of its former members was Filip Dewinter, the current president of the extrem right party Vlaams Belang (formerly Vlaams Blok). Those groups are known for their racist positions in Flanders (against the Turkish and Maghrebian minorities) and in Belgium in general for their intolerance against anyone not Flemish.

As for the Taal Aktie Komitee, I can testify I have been physically molested by some of its members because I dared speaking French to some of my friends in a street in Flanders. It was 25 years ago, but my back is still hurting on wet days because of that.

DomainNews.com reports that the Flemish group will team up with the applicants for .cym, .bzh and .gal GeoTLDs. A word of caution to the Welsh, Breton and Galician groups: watch out who you are teaming up with. Do you want racists and revisionists in your group ? If not, you should better think twice before teaming up with the current .VL team, unless they distance themselves from those embarrassing supporters. Actually, they do. Sort of. However, the disclaimer is quite vague:

“Het vermelden van en linken naar deze organisaties en hun website betekent niet dat Jonge Vlamingen en PUNT VL de standpunten van deze organisaties onderschrijven of akkoord zijn met de inhoud van hun website”.

The references and links to these organizations and their web site does not mean that Jonge Vlamingen en PUNT VL supports the positions of those organizations or agree to the contents of their web site.

So, it is not clear however which views they support and which they do not.

Update 20 August: The proponents of .VL point out on their web site (in Dutch) that French Réunion (.re), Guadeloupe (.gp), Martinique (.mq) and French Guyana (.gf) have their own ccTLD. However, none of these French departments or territories use this for the political purposes of separating themselves from their country, and their ccTLD is administered by AFNIC. They also point out to .EU.

They seem to ignore that all these entities have their own ISO-3166 codes. Flanders does not. And unless they convince the UN Statistics Division they are a sufficiently autonomous territory from an economical point of view or an independent state, the VL ISO code is not going to assigned to Flanders any time soon. With regard to ICANN’s policy on new TLDs, I think it would be dangerous for ICANN to assign two letter TLDs which could conflict with later updates to the ISO-3166 list.

ICANN has embarked on the IDN boat at the same time it wants to introduce DNSSEC and new gTLDs. This promises lots of fun. Or grey hair, depending how you look at it.

First is the issue of country code IDNs. The ISO-3166 table, based on two letter codes, is a western convention. Some cultures do not use abbreviations or acronyms. Some do not use a character-based alphabet, but a syllabic one. Hence, the next logical step would be to represent the full country name in local script, rather than a transliteration of the ISO string. As an example, Morocco may want to use المَغْرِب (or xn--mgbc0a9azcg7dsq in punycode) , in parallel with .ma. This is a simple case: Morocco has only one official language.

Imagine the case of India, where there are 1.652 languages, of which 24 are spoken by more than one million people. All have a distinct alphabet. Further, the Constitution of India does not impose an official language. Are we going to have at least 24 new IDN TLDs for India ? This would make political sense, but would be a real burden to manage at the root level, especially if we end up with 1.652 of them, just for India. Obviously, other countries which use several languages may want to do the same.

When it comes to gTLDs, the situation becomes even more interesting. Take, for example, .ORG. ORG stands for “not-for-profit organization”. How does that translate in IDN TLDs under different languages ? If we simply transliterate the “org” string in local script, we might end up with a meaningless name or – more unfortunate – an offensive word in the local language.
On the other hand, there may be several ways to translate the NFP organization concept in a specific language. As an example, if I had to translate the NFP organization concept in French, it would be association à but non lucratif in France, but association sans but lucratif in Belgium or association sans but économique in Switzerland.

Yet, it does not look logical that the incumbents gTLD registries could automatically claim to run any IDN TLD which translates more or less the concept of the original string. We should expect those countries which were not offered a piece of the multimillion dollar gTLD cake in previous years to want some money out of the IDN TLDs in their own script. Just imagine how much money could potentially represent a .com TLD in mandarin or arabic.

ICANN will have a hard time desiging a policy for IDNs. The technical challenges are actually small, compared to the economical, political and cultural issues surrounding those internationalized domain names.

We keep hearing in the ICANN and IETF crowds that DNSSEC is unavoidable and that it is the way to go. These are the same crowds saying that we should move to – or at least support – IPv6. In both cases, the prophets are not always those who actually do it. While www.isoc.org and www.ietf.org are running on a dual IPv4/IPv6 stack, much of the companies working within the IETF do not run dual stack web sites: Cisco, Microsoft, IBM, Sun, etc.

So, rather than telling others that they should run DNSSEC, I figured I should do my homework and run DNSSEC myself, without waiting for my TLDs to get signed.

The job is done, but it was no easy task. If you are looking for a simple button on a GUI to sign your DNS zones, move on. Currently, this is not for the faint of heart, which might explain the slow adoption path. Bind does include all the tools, but you first have to figure out how the damn thing works and use the right parameters.

I found a tool which made my life much easier. It is called ZKT. Once you have configured the header files to your environment and adapted your file directory structure to the requisites of ZKT, you can actually sign all your zones in one pass. It will call the necessary Bind tools with the right parameters. I have created a cron job that will periodically check which signatures need updating and change the zone files accordingly. Highly recommended.

According to this article in IHT , those who want deployment of IDNs now are “political gambits”. Cerf said that the technical side is not yet ready and thus the deployment of IDNs should be done very carefully.

I agree to the technical aspects. However, the next question is of course: “when will it be ready for deployment ?”. Can the ICANN community commit to a deadline it will meet ? If not, ICANN should not blame those “political gambits” who wish to go forward because they just cannot afford to wait anymore.

There is a bad habit in the ICANN community that it should set the agenda and the rest of the world should just follow. Trouble is of course that the “rest of the world” represents several billion people, most of them ignoring the very existence of ICANN and even more its legitimity to set the world agenda. ICANN sounds more and more like Major Tom in David Bowie’s Space Oddity: “Ground Control to Major Tom, your circuit’s dead, there’s something wrong. Can you hear me Major Tom ?”

This post has also been featured on CircleID , where most of the discussion will take place, I guess