techblog 

The day following the death of Michael Jackson, Google published a graph showing that their system were heavily hit by queries related to this news. Details can be found on the Google Official Blog.

Our experiments suggest that Nominet systems experienced an analogous, although orders of magnitude smaller, phenomenon. The following figures show the number of new registrations per hour of domain names that contain the name of Michael Jackson (or part of it) and the number of WHOIS queries that Nominet systems received in the same period.

The two graphs are highly correlated because it is common practice for domain name owners to make WHOIS lookups around the period of time they register new domains. The peak around the 27 of June in the second graph is probably related to news stories concerning suspicions about Michael’s death.  Apparently, it did not lead to an immediate rise in the number of domain name registrations.

We have conducted an informal analysis of the domain names that were registered in the last week. The majority of them belong to three categories: parking pages, commercial pages and commemorative sites such as blogs and forums. At the moment, we have no evidence of domain names used for scam or phishing.

In general, this episode confirms (again) that the dynamics of the Domain Name System follow those of the “real world”. A question that is still partially unanswered is at which degree these dynamics are followed by Internet users, i.e. how much their navigation behaviour depends on news stories. In the following months we plan to study the correlation between DNS data and other public events. Google has done something similar in the past, by correlating Google searches for flu-related terms with the spread of flu in North America. The results are very interesting and definitely merit extension to other data sources such as DNS traffic.

Typo-squatting is the practice of registering a domain name with the intent to confuse it with the name of a trademark or a famous other domain name

In March, I presented the paper Typo-Squatting: The “Curse” of Popularity in the poster session of the first International Conference on Web Science in Athens. The paper, written together with co-authors David Duce and Faye Mitchell (Oxford Brookes University) and Stephen Morris (Nominet) can be downloaded here.

In the paper we study typo-squatting from a statistical point of view. The distribution of names in the co.uk registry is analysed using the concepts of syntactic and visual neighbourhoods of a domain name (the sets of all other domain names which are syntactically or visually similar to to it).  Our preliminary results show a strong correlation between the popularity of a domain name and the size of its syntactical and visual neighbourhoods although, counter-intuitively, the neighbourhood size does not depend on length.  This suggests anomalous activity “around” very popular domain names, as well as indicating that the size of the neighbourhood can be used as a reliable indicator for the likelihood of being typo-squatted.

I’m pleased to announce the release of enumdroid.

This application adds ENUM (E.164 Number Mapping) support to your Android phone.

Each time you dial a full international number (i.e. starting with a ‘+’) your phone will check the DNS for additional routing information and offer you a list of alternate contact methods.

The application is open source (under the Apache License) and the code is available for download from Google Code.  The application can be downloaded from the Google Market under Applications -> Communication

Here are some screenshots, which show in turn:

1. Nominet’s switchboard number being dialled
2. ENUM results being returned
3. A call being placed over the PSTN to a tel: URI
4. The ENUM application’s settings page

Last week I attended the user experience conference UXLondon organised by Clearleft, with a solid day of keynote talks, followed by two days of half-day workshops.

In brief summary the conference highlighted several key points:

• How we should work with the customer at all stages to ensure both designer and customer are working towards the same goals.
• Developing software that is intuitive, aligned with user behaviour, can really make a software product stand out from it’s competitors.
• How using prototypes before starting development can really help iron out usability bugs before investing too much time and expense.
• Designing good interfaces for complex systems is hard!

My own detailed notes can be found in “UXLondon – Notes on User Experience and Design” (with one of the presentations embedded), where I talk more about what I personally learnt and what I thought of the individual sessions attended.

I got bitten by a silly bug in my dnsruby code recently - I thought I’d share it here in case anyone else starts pulling their hair out over this in future!

DNSSEC RRSIG records contain the signatures required to prove that a DNS zone has been correctly signed by an entity which possesses the correct keys for the zone. DNS clients can obtain the correct keys for the zone, then use the RRSIG records to prove that the zone (or record of interest) is correct. Of course, these records shouldn’t last forever - the data records are periodically re-signed (possibly with different keys), and the RRSIGs updated. The RRSIG includes an inception time, and an expiration time, to show the period over which it is valid. To verify a set of records, the DNS client must first produce an array of bytes, the digest of which is taken and used as the signature for the records - the salient data of of the RRSIG record (including the inception and expiration times) is included in this set of bytes.

The code I had written to do this was working fine - I had coded in the examples from the RFCs, and done a lot of work with actual signed zones (reading the data from the authoritative servers, and proving that it was correct). However, when I started to try to do this with real-world zone files, I started noticing that the signatures weren’t verifying. At least, they *sometimes* weren’t verifying. Very odd. Of course, with this kind of work, all you get is a Pass/Fail - no clue as to what is going wrong. I could see that the records were being translated to and from text format correctly - all the data in the RRs was showing as fine. However, when I compared the byte sequences prepared by my DNS client and Net::DNS, I noticed that four bytes were different. It turned out that, of the four byte sequences written to for the RRSIG inception and expiration time, there was a difference of 0xE100 - this works out to 16 hours worth of 3600 seconds. At last, I was onto something!

There are several ways to express time in the presentation format of the RRSIG record - “1234567890″ (seconds since 01/01/1970), or “YYYYMMDDHHMMSS” (e.g. “20090608123435″). Dnsruby worked fine with the first, and even translated the second from presentation format and back to presentation format correctly. However, when read using the following line :

return Time.mktime(year, mon, day, hour, min, sec).to_i

I got a 16 hour offset from the correct time! [When converting this time to/from the text format, the translation worked perfectly - it was only when inspecting the internal epoch time that the difference could be noticed]

I changed this to :

return Time.gm(year, mon, day, hour, min, sec).to_i

And suddenly everything worked just fine.

I’m sure that seasoned Rubyists will sneer at me for my stupidity - it did take me some time to track this one down! So, if you start noticing strange 16 hours offsets in your Ruby code, it’s worth checking your usage of the Time class…