Category: ICANN


Ductus Exemplo

That one different gummy bearSometimes when you buy a pack of sweets, some of the sweets are damaged or look weird. One time, I even had them mixed with a different type of sweets. This may happen to you once a year or less, but the people who are working in the factory surely see it happening more often.

This works for everybody: Doctors see more injuries, Bartenders hear more weird stories and we see more inaccurate WHOIS entries and compliance-violations than most other people.

At some point, it has become so much that I started to become very interested in how this works in detail. ICANN provides binding (hah!) agreements between Registrars and Registries. Let’s take postal codes as an example.

ICANN says (through the RAA): Postal codes need to be in the format specified in RFC 5733 and in accordance with the UPU address format for the country in question (in this example: China).
IETF says (through RFC 5733): Postal codes are represented through character strings with a defined minimum and maximum length.
UPU says (through international addressing sheet China): 6 digits.

You could agree with me here that we established the fact that the postal code for a registrant form China needs to be six digits. Not two, not eight, not letters, not symbols and so on, right?

Well, while writing this post, we have 11.100.156 new gTLD domains registered to registrants from China.

905.693 of them are in violation of the UPU address format, the RFC 5733 and thus, ICANNs RAA. That’s 8,1%. And that’s postal codes in China only. Worldwide we also have

  • 2.211 domains with invalid country ISO-3166-1 codes
  • 205.952 telephone numbers with a non-existing country codes
  • 263.906 domains don’t even have a telephone number entered at all
  • about 50 email addresses that should fail even the simplest email syntax check (containing spaces, missing @, missing host name, etc.)
  • 941 missing email addresses
  • 137.138 disposable email addresses

And we’re far from being done with our checks yet.

Knowing this makes ICANNs specifications look like a joke to me. To put it into perspective, here is my favourite piece from ICANN regarding this:

  1. Validate the presence of data for all fields required under Subsection 3.3.1 of the Agreement in a proper format for the applicable country or territory.
  2. Validate that all email addresses are in the proper format according to RFC 5322 (or its successors).
  3. Validate that telephone numbers are in the proper format according to the ITU-T E.164 notation for international telephone numbers (or its equivalents or successors).
  4. Validate that postal addresses are in a proper format for the applicable country or territory as defined in UPU Postal addressing format templates, the S42 address templates (as they may be updated) or other standard formats.
  5. Validate that all postal address fields are consistent across fields (for example: street exists in city, city exists in state/province, city matches postal code) where such information is technically and commercially feasible for the applicable country or territory.
  6. Verify:
    1. the email address of the Registered Name Holder (and, if different, the Account Holder) by sending an email requiring an affirmative response through a tool-based authentication method such as providing a unique code that must be returned in a manner designated by the Registrar, or
    2. the telephone number of the Registered Name Holder (and, if different, the Account Holder) by either (A) calling or sending an SMS to the Registered Name Holder’s telephone number providing a unique code that must be returned in a manner designated by the Registrar, or (B) calling the Registered Name Holder’s telephone number and requiring the Registered Name Holder to provide a unique code that was sent to the Registered Name Holder via web, email or postal mail.

And those inaccurate informations are for valid and active domains. A quick check revealed that only 1% of those domains are in clientHold or any similar status, which would allow such false entries to exist. But even then you could question the acceptance of such methods, since even a domain on clientHold is gone and can’t be registered by someone else for the time being.

Now this post isn’t supposed to be just a rant. We want to lead by example and act within our capabilities to make the whole new gTLD domain space a better place (I know it sounds cheesy, but whatever). So we approached ICANN with the goal of finding a way to provide them with the most up-to-date inaccuracies. Basically, we want to enable ICANN to fast-forward the process of identifying “faulty” domains and Registrars/Registries who just don’t care and thus, “poisoning” (yep, strong word) the whole thing.

Believe me when I tell you that while working with every type of client from the domain industry, I realised that if everyone would do their job just with a little more effort, this whole thing would not only be way more easy for you and me, but also way more fun. Instead of reacting to a bizillion of errors and fixing problems that are being thrown in our faces because some Registry is changing creationDate entries (suddenly dated back, missing, etc.) – and thus, making our statistics worthless – we could provide you with so much more interesting and amazing statistics you’d neglect your own wife because you “just wanna browse nTLDStats a bit” instead of coming to bed.

That being said – good night!