ICANN ICANN Email List Archives


<<< Chronological Index >>>    <<< Thread Index >>>

Admin Panel Whois / Public Whois synchronization

  • To: <irtp-b@xxxxxxxxx>
  • Subject: Admin Panel Whois / Public Whois synchronization
  • From: "President" <President@xxxxxxxxxxxxxxxx>
  • Date: Thu, 24 Sep 2009 04:43:21 -0400

An issue the previous poster brings up, and one that is VERY evil:

For some time now many registrars plays games with their admin panel versus the 
public whois. That is, the registrant's admin panel view of their updates are 
allways correct, however the public whois has a different value.

This is also a fundamental problem with the current data escrow, the registrant 
beleives their information is correct (after all the admin panel says so). The 
registrant then fails to notice the public whois has a completely different 
value. Most registrants have no clue what the public whois even is and what it 
actually means to them and insuring an audit trail for their lease of the 

I've posted about this issue for many years noting even seasoned domainers did 
not realize this was happening. The rule is simple:

NEVER check the whois of your domain at the registrar that sponsors the domain!

In fact, when you do a whois query at many registrar's public panel, that 
service draw from their LOCAL data table and NOT the public data table! Thus 
even if the registrant is smart enough to check the "whois", it does not work 
as it's not the whois value returned by the thick registries or the port 43 
COM/NET whois service at the same registrar!

So, again, registrars have yet another game to play on registrants. And when a 
registrar gains $1 of benefit to renew a domain, but $20 to $50 MINIMUM to 
auction the domain via transfer fullfillment, is obvious to see the motivation 
for admin panels that give different info that the public panel.

One example of this that can be found in the domain forums are cases where 
registrants renewed COM/NET domains, had their credit cards billed, and the 
domain was auctioned off. Nobody seemed to be able to figure out what happened. 
However, as I've posted in the forums, there have been many documented cases of 
port 43 whois showing different EXPIRATION DATES for domains that the real 
date. Those that are aware of Internic, and the fact that internic pulls from 
the registry directly, have the knowledge to cross check and VERIFY sponsoring 
registrars showing bogus info in the public whois.

So we are back to "garbage in = garbage out".

Until registrars are FORCED, and be accountable for, displaying factual whois 
date (in this case what the registrant entered in the admin panel!) it's just 
not possible to address the issue of figuring out who regged what when and thus 
who to return the domain to.

An evil registrar can drive a supertanker though this loophole to steal or 
launder domains at will ... And thus increase their top line to get domains 
into auctions and blame it on an out of sync database. 

To be fair to the honest registrars, another way this happens (for the THICK 
registries) is the registrant performs a whois update on a block of domains, 
the registrar's local table is immediately updated, however the list is then 
shelled out to a batch to run against the registry.For systems that work this 
way the registrant is "gone" at the time of the registry transactions, for a 
number of reasons some may fail, and their is no way to return that error to 
the registrant. The registrar should retry, but even that get the registrar's 
system into weird state should it happen at a registry service period. The 
registrars that do not batch, or force the registrant to wait until the results 
of the update are avialable, tend to be immune to this database sync problem. 
But this failure mode can't forgive COM/NET since both tables are local to the 
registrar and the registrar has FULL end to end control, which most registrants 
and domainers assume is correct and never think to verify.

Again, we need to clean up the very process of instantiating the whois from end 
to end; centralized whois for all TLDs, and NO privacy whois! Given this post 
one could also derive the requirment that registrar's whois system SHALL pull 
from the registry whois server and NEVER from any internal tables, this then 
guarentees that registrant has a shot of noticing the errors.

And should the reader think I'm refering to events that happen with 
insignificant frequency, I again refer you to the domainer forums. I also refer 
you to my previous comment where RegisterFly was modding my whois without my 
making any changes. Again, honest registrars allready know how to deal with 
these issue, evil registrars will do this to hide their tracks. And the Data 
Escow will NEVER detect this or ever be usefull in resolving it since the data 
escrow requirement is written against the PUBLIC whois and not what the 
registrant see in their admin panel.

If  registrant is not insured of their admin panel whois date being the 
pubically displayed data, no third party can ever be sure who registered what 
when and why a domain moved from one sponsor to another.

Charles Christopher 
Domainer Since 1999 
CIO ICANN Accredited Regisrars; Alfena, IgniteLA, PocketDomain, Yenkos


<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy