Category: Registry-Backend


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!

 

The raw data approach (Or: Why we display 190+ companies instead of Donuts Inc.)

Ever since ntldstats.com launched, the highest priority was to show all the statistics in a rather raw and untampered fashion. We even had day long discussions about how to display even the smallest things, because one of our concerns was that someone might accuse us of displaying statistics in such a way that it would let those statistics shine in a very specific light – the light of our personal opinion. And that is what we don’t want.

A perfect example for how we try to keep data raw is how we handle gTLD deletion cycles:

  • Auto-renew grace period: When an active domain enters the auto-renew grace period (usually 45 days), it is about to expire, but not yet deleted. Thus, even though the domain might not be present in the zone file anymore, we are still listing it as registered – because technically it is.
  • Redemption grace period: Once the domain enters the redemption grace period, we still list it as registered, because – I know it gets boring, but – it is still registered. Also, the (soon to be former) owner of the domain could still get the domain back into former glory. Yet, every domain in this period will be accounted into our websites “upcoming deletes”-number.
  • Deletion period: No changes here, because we don’t know how long the domain will be in the deletion period. It will be deleted from our statistics as soon as it is – well – deleted. Until then, it is – ahem – technically still registered.

Back to topic. Last week we’ve received a lot of feedback from you guys regarding on how we handle the statistical display of stuff, especially Donuts Inc. stuff. Donuts Inc. is, for obvious reasons and like other Registries, incorporating a new company for each gTLD. Our “raw data” approach confused some people, since you weren’t able to see what company belongs to Donuts Inc. Good news, we’ve changed it! [Big sigh of relief, we know]

And we even changed it in a way that lets us maintain our “raw data” approach: From now on, all the Registries who follow the “one TLD, one company”-scheme will be listed right after those “one-tld-companies” in brackets.