Would domain name users who are concerned about the accuracy of data served pay extra for the ability to sign their DNS zone ?  A handful of people in the room raised their hand in agreement, but the overwhelming majority of operators did not.

His argument was that this compared well with SSL certification authorities who sell certificates that suggest that visitors to a website are interacting with a validated entity, and the technology guarantees privacy between the visitor and the website.  It’s this technology which makes buying and selling online safe.

However, I think that DNSSEC has different aims altogether – simply to guarantee that DNS data is not changed en-route between the authoratative server, through the caches, all the way to users.  Therefore there are significant attack mitigation reasons to deploy DNSSEC, so I hope that operators will begin trials (we are doing so), and that the pace of trials will quicken as the root zone will be signed this year.

If DNSSEC is deployed as designed, then temporary and brief mistakes will not be imported into DNS caches, users will not fall foul to tampered data in caches, and we all receive an authenticated/secure channel for distributing DNS data inside an organisation.

The argument that Dr. Schweiger used is that DNSSEC adds an operational and technical burden to registries (extra communication with registrars, more complex software, additional CPU and bandwidth requirements).

I hope that my colleagues in other organisations agree that there are significant infrastructure advantages to freely allowing DNSSEC to grow, and that Moore’s Law, automation, and the fact that DNS registries normally find it simple to peer widely with ISP networks will offset the needs to consider the commercial signing model.

All successful internet protocols are elegant and simple by design. This makes it possible to retro-fit great ideas someone has one. Internationalisation was proposed in 1992, and it eventually became possible to register Internationalised Domain Names (IDNs) in the .com space in 2003. Standards move slowly on the internet!

IDN is up for discussion again at the 31st ICANN meeting on Monday. This time, the world’s registry community are meeting in New Delhi, one of the most significant IT regions of the non-Latin world, to discuss the remaining “glitch” in the IDN system. An IDN might look like this: .com. Therefore any user still needs to be able to type .com in order to reach the resource they request. There is a proposal at the ICANN meeting to add Internationalised top-level domains, actual complimentary TLDs to .com, that will mean that resources can be reached in any supported alphabet.

This is interesting stuff. One school of thought is that this could significantly assist the development of electronic enterprise in many more pockets of the world. The supremacy of Silicon Valley as the web’s main economy would then be broken. I think differently – I think that .com is now too established as the main ecommerce ‘brand’ TLD, and attempts to localise the meaning of .com will be fruitless. .com means “I trade online”. Despite .biz and similar TLDs being equal in technical terms, they are not equal in the eyes of shoppers or traders. .com now has specific global meaning, and can’t be diluted.

As a result, requests to process new registrations, renewals, and changes are really slow. It is, what I assume, an offpeak time right now – 10pm Saturday evening, and it has just taken an hour and a half for me to get a response out of the Automaton from a domain renewal request. Traditionally I get responses back in a matter of minutes.

My prediction is that this will renew interest from .uk domain stakeholders that support the movement towards a real-time API like Tucows’