In a thin domain registry the domain contact information is held by the registrar. The registry whois just holds a referral to the registrar, the registration, expiry, update date, nameservers and domain status.
A thick domain registry holds all of the contact information needed for the domain names.
After a transition of .ORG to a thick whois in 2003 .COM and .NET are the only generic Top Level Domains (gTLDs) still using a thin registry. Many of the ccTLD (country code top level domain) registries that were running thin registries are switching to using the Extensible Provisioning Protocol (EPP) protocol for the registrars to communicate with them, which normally goes hand in hand with a ‘thick whois’.
In a thin registry, the contacts are not transferred as part of the transfer itself as the are in a thick registry. Thus the gaining/new registrar has to parse them when a domain is transferred or replace them with the contacts that were entered on the order. The lack of mandated registrar whois output format makes the parsing of whois information difficult.
Thin whois example:
Domain Name: EXAMPLE.COM
Registrar: EXAMPLE REGISTRAR LTD.
Whois Server: whois.example.com
Referral URL: http://domains.example.com
Name Server: NS1.NAMESERVER.COM
Name Server: NS2.NAMESERVER.COM
Updated Date: 15-mar-2013
Creation Date: 01-mar-2005
Expiration Date: 01-mar-2016
The remainder of the contact information would be provided by the sponsoring registrar.
Thick whois example:
Created On:23-Nov-2006 03:19:55 UTC
Last Updated On:19-Sep-2013 18:54:54 UTC
Expiration Date:23-Nov-2014 03:19:55 UTC
Sponsoring Registrar:Example Registrar Ltd. (R555-LROR)
Status:CLIENT TRANSFER PROHIBITED
Registrant Name:Domain Owner
Registrant Organization:Domain Company Inc.
Registrant Street1:3551 15th Street
Registrant City:Sample City
Registrant State/Province: NY
Registrant Postal Code: 12345
Registrant Country: US
Registrant Phone Ext.:
Registrant FAX Ext.:
Registrant Email:[email protected]
During a recent webinar, ICANN went through the new Expired Registration Recovery Policy (“ERRP”) for registrars – here’s the summary and what you need to know. Please make sure that you read the original Expired Registration Recovery Consensus Policy if you need any more details. Registrars have to comply with the new policy by August 31st, 2013. This policy was developed from the Generic Name Supporting Organization (GNSO)’s Post Expiration Domain Name Recovery (PEDNR) recommendations. ICANN’s Board of Directors adopted the policy and ran it through a public comment period.
Expired Registration Recovery Policy (“ERRP”)
- Registrars can delete domain names any time after they expire
- The existing DNS has to be “disrupted” for 8 days before deletion, meaning the domain name has to either be put on “Registrar Hold” effectively removing it from the zonefile or changing DNS to point to a registrar supplied site. If a page is displayed, it must include instructions for renewing the domain name.
- The registrant must be able to renew the domain name any time before deletion.
- If the domain is renewed the registrar must restore DNS “as soon as commercially possible”.
- The registry automatically renews the domain one the day of expiry and charges the registrar’s prepaid account
- If the domain transfers out or is deleted within 45 days of the expiry/autorenewal, the prepaid funds will be returned to the registar’s account
- After the domain name is deleted (unless a delete happens within the first 5 days after registration), the domain (for all gTLDs other than sponsored gTLDs) will enter the “Redemption Grace Period” (RGP), which lasts 30 days. During this time the domain may still be restored by the registrar at a higher cost. This must be offered by registrars.
- The domain name will then go into “Pending Delete” status and will be deleted after five days
- Any fees for renewals, post expiration renewals and redemptions must be displayed/be available to the registrant at the time of registration, for example as part of the registration agreement.
- The registrar’s published renewal policy also must reveal how renewal reminders will be sent.
- ICANN will publish information on this process on their website, registrars will have to link to it.
- Resellers will have to display all of this information as well.
- Notify registered domain holder of the expiry of their names at least two times
- The notices may be combined for domains expiring at the same time.
- Approximately one month and one week before expiration.
- Sent in language of the registration agreement
- Must be sent to the “Registrant at Expiration” (RAE), meaning the holder of the name at expiration.
- If the name is not renewed until five days after expiry, another “Final Renewal Reminder” must be sent explaining how to renew the domain
- Registrars that send more or other notices may continue to do so
- No prescribed template
- Registrants cannot opt out of notices.
- All messages sent to the registered name holder must be available for audit.
A current working group formed by the ICANN Generic Names Supporting Organization (GNSO) Council is looking at how a domain name should be locked during UDRP proceedings. If you have anything to say in this matter, I suggest you participate in the related survey, as we just did.
I’m actually a bit surprised that this is such a huge issue and would love to see statistics on how this is currently handled by registrars. I think in general the directions are clear and so is what a “lock” means, but then again, our registrars/registrants are not commonly targeted by UDRP.
Further information about the work group (they are still looking for participants) can be found here.
One issue we did encounter though is that the initial notice in a case we recently handled on behalf of a client registrar was apparently too large for one of the involved mail-servers to handle. In this case it’s important for the UDRP provider to act based on the bounce message that they use other means to contact the registrar. After receiving the copy of the complaint directly from the complainant we attempt to verify the validity with the UDRP provider, which unfortunately took another seven days to respond to our request for confirmation.
Obviously we also examined and adjusted the limits for inbound mail in this case.