Introducing WHOIS flaky factor

Introducing WHOIS flaky factor

AA419 has introduced a new toy for internet researchers.


When looking up the registration details (WHOIS) for a domain, in the thin domain gTLD model, we are reliant on registrars to supply these services.

Essentially the access should be freely available and meet the following specifications as per ICANN

Registrars and registries [PDF, 649 KB] are obligated to provide access to WHOIS data through registration data publication services. It must be publicly available in a specific format and on a designated “port” reserved for WHOIS data sharing (port 43), as well as on an interactive webpage. Port 43 access by registrars is required only for domain names registered in ‘thin’ registries. The data must include specific identification, contact and technical information.

At present, web-based WHOIS queries may be performed through the websites of ICANN accredited registrars and registries, most regional Internet registries, and third party WHOIS client providers. The agreement between a gTLD registry operator and registrar may, if approved by ICANN in writing, state alternative requirements for that gTLD. Also, under certain market conditions, the registrar may be obligated to provide bulk access to WHOIS.

Data available depends on whether a registry is “thick” or “thin”. Only a few registries that existed prior to the new GTLD program are “thin,” (such as .com and .net). Thin registries do not include registrant contact details. For thin registries, registrars provide the specific registrant contact information.

ICANN specifies Service Level Agreements related to the performance and acceptable downtime of the registrar & registry’s [PDF, 649 KB] WHOIS services. This includes downtime for maintenance, planned outages or system failures, and performance response times to Internet user queries.

Anyone can submit a complaint that a registrar’s WHOIS service is down. Registries must submit WHOIS performance reports [PDF, 649 KB] to ICANN.


Some registrar’s servers give hiccups from time to time. As a consumer of whois data in AA419’s efforts to protect consumers, we are extremely sensitive to such issues.

In the past we have been told by one registrar, GoDaddy, we need to apply for special permission to get access to whois.

 8 Sept 2014

GD: Remote access is blocked by default. You’ll need to email a request to to be whitelisted…
Please include: Full Name, Business Name, Business reasons for access, and specific IPs which need to be whitelisted. ^CG

Me: I’m not asking for bulk access not subject to rate limiting. I’m trying to use normal low volume port 43 – ICANN mandated free access.

GD: We already allow you access to retrieve the domain, name servers, and creation/expiration dates for the domain as ICANN Mandated…
If you require full access to contact details, you’ll need to proceed with emailing with the info requested. ^CG

Me: ICANN RAA 2013, 3.3 But nvm, I’ll take it up with ICANN Compliance as a compliance issue against Godaddy using this as background. Thx

This led to an ICANN escalation. And then denial of issues (the claims by GoDaddy were never addressed).  Miraculously GoDaddy’s whois servers started behaving though. We ensure these issues occur from various locations around the globe, doing relevant network traces at the TCP layer before making such claims. But what if there is not issue on our side?

Obviously these issues are counter productive to anti-fraud efforts and we simply do not have the time to play these games, especially as in the latest GoDaddy incident.

Once again we are in the same situation and we have broken whois servers on the net at GoDaddyand Wild West Domains. In the current situation, if a new session is opened and whois lookup is done against the relevant registrar’s whois server, the server sets up a network session, then submits a reset to the client.

Connection reset: Godaddy


Connection reset: WildWest

These result in aborted look-ups.

WHOIS lookup failure on reset

Should one try again repeatedly, you may either succeed, or eventually get blocked for a while, probably for being abusive? Fair enough blocking abuse if the server was working like it should, but currently this compounds to the issue.

In the current incident, we tried pointing this out to GoDaddy. From the GoDaddy preferred support chat, we were diverted to phoning in the details. The support operator, Bill, then wanted us to use the online WHOIS. It was necessary to point out the ICANN RAA requirements for a functional port 43 whois lookup server for any registrar registering thin WHOIS domains in the GTLD space. We were then asked to submit the details to which we did. But alas, GoDaddy no longer gives email support?

Thank you Godaddy for wasting our time and money.


Our Solution

Rather than flogging a dead horse, we patched our system and specifically the industry standard software we’re using to obtain whois details, introducing the flaky factor into our database at

We will retry N times with a pause in between each attempt.

  • Should we succeed the first time, the flaky factor will not be shown.
  • Should we have to retry more than once before succeeding, the WHOIS resulting will show an appended flaky factor, example:

Flaky WHOIS Server Alert: We had to retry 4 times

  • Should we fail totally, the WHOIS result will show:

*** Flaky WHOIS Server Alert! ***
whois-nameserver-name  failed.
*** We retried N times ****

We trust this information will be useful to researchers.


The AA419 Team

Comments are closed.