Category Archives: DNS

Where are the individuals, domain name holders, within ICANN ?

icann-thumbThe just published Whois Registrant Identification Study, Draft Report, is an interesting read. This study, conducted by NORC at the University of Chicago, uses Whois to classify entities that register domain names, including natural persons, legal persons, and Privacy/Proxy service providers.

One major finding in this study is that one third of domain name registrations are done by natural persons, i.e. individuals. As the study points out, these domains are more likely to be used for non-commercial purposes. Up to now, the common wisdom among the ICANN community was that the number of domain names registered for private use was, at best, marginal. Hence, the belief that they were not worth spending any resources on them on the policy side. Read more »

Why I quit Mobile Vikings

A while back, I moved to Mobile Vikings as my mobile operator. I was quite enthusiastic. The picture looked idyllic. 2 Gb per month of data transfer seemed like an offer you cannot refuse, given the state of the Belgian mobile phone market, characterized by high prices, wicked contracts and not-so-honest salesmen. Mobile Vikings is a MVNO, using the KPN network in Belgium. Read more »

Belgacom DNS resolvers lack EDNS support

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 Read more »

New Top Level Domains and software implications

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.

Read more »

Comments on the second draft of ICANN’s gTLD applicant’s guide

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.