What is a thin vs thick registry or whois?

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’.

Domain Transfers

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
Status: clientTransferProhibited
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:

Domain ID:D892392839-LROR
Domain Name:EXAMPLE.ORG
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 ID:reg-38444561
Registrant Name:Domain Owner
Registrant Organization:Domain Company Inc.
Registrant Street1:3551 15th Street
Registrant Street2:
Registrant Street3:
Registrant City:Sample City
Registrant State/Province: NY
Registrant Postal Code: 12345
Registrant Country: US
Registrant Phone:+1.2125551212
Registrant Phone Ext.:
Registrant FAX:+1.2125551212
Registrant FAX Ext.:
Registrant Email:[email protected]

etc.

What is Registrar Data Escrow (RDE)?

Registrar Data Escrow (RDE) is an ICANN mandated process that registrars must follow to store a copy of the customer’s whois information with a third party. Smaller registrars will deposit the information weekly (larger registrars in higher frequencies) on the server of the RDE provider in an encrypted format. Should your registrar go out of business, this would be the information passed on to the new registrar who takes over the domains and your clients. Going forward, registrars offering whois privacy services will be obliged to deposit the underlying whois information (without privacy) with the escrow provider.

ICANN had initially selected Iron Mountain as a Registrar Data Escrow provider. As of March 2018, DENIC e.G. also offers Registrar Data Escrow services through DENIC Services GmbH & Co. KG, a sister company of the German registry. If the registrar uses Iron Mountain or DENIC, there are no additional charges to be paid as ICANN is paying for their fees. Some registrar system providers might, however, charge fees to enable the deposit service on their end. Registrars are also able to choose from other approved providers but will have to pay those directly.

What is the Transfer Emergency Action Contact (TEAC)?

The Transfer Emergency Action Contact (“TEAC“) is a contact that each registrar must provide to ICANN through ICANN’s Radar Interface. This contact is to be used by other registrars, ICANN and the registries if there’s a need to quickly address issues with domain transfers between two registrars. The contact must respond (non-automated) to inquiries within four hours, though the final resolution may take longer.

The TEAC is part of the Inter-Registrar Transfer Policy (IRTP).

What is the ICANN FOA (Form of Authorization)?

The FOA (Form of Authorization) is an ICANN mandated message (basically an Email template) that the registrar needs to send to the “registered name holder” when an incoming (gaining) or outgoing (losing) transfer request is received.

The gaining side FOA is used in order to obtain the registered domain holder’s permission in order to transfer a name from another registrar to yours. The losing side FOA is used when another registrar has requested a transfer out for a domain that was previously held under your registrar. While the transfer out is auto-completed after five days. this gives the domain holder another chance to review the transfer that is going to happen to make sure it is happening with his knowledge.

The emails form part of the Inter-Registrar Transfer Policy (IRTP).

ICANN Requirements for Expired Domain Names

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.

Messaging Requirements

  • 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.

Cost of becoming ICANN accredited

A frequently asked question is, how much does it cost to become ICANN accredited.

Here is a quick summary of the fees payable to ICANN:

One time fees

  • $3,500 non-refundable application fee

Ongoing fees

  • $4,000 annual fee
  • variable quarterly fee ($800-$1,200) – amount depends on ICANN budget and amount of domains under management
  • $0.18 fee per domain name year, invoiced quarterly

Other financial considerations:

  • Must show liability insurance in the amount of at least $500,000 USD (no longer a requirement)
  • Must show proof of $70,000 in working capital
  • Technical systems to operate the registrar will have to be provided ($)
  • Consulting may be needed to become ICANN accredited ($)
  • Fees payable to registries (deposits)

Current ICANN Compliance Audit Notes

ICANN has contracted KMPG to run a compliance audit where all of the registrars will be audited over a term of three years. The first 1/3 of registrars have received their questions on November 27th, 2012 and will have to respond by December 17th, 2012.

As one of our clients is part of the current audit, here are a few notes/observations regarding the audit from our end:

  • It appears the list of domains may also contain domains that are/were not under your accreditation.
  • Even though the audit email itself does not reference the deadline to respond (it’s mentioned in a pre-notification email), it should be December 17th, 2012 for any of the registrars included in the current round.
  • Other than that the audit just pertains to a history of a list of names and verifies some of the ICANN accreditation requirements along with contact data.
  • One section of the audit is related to resellers – an upload of the current reseller agreement is requested.

If you need any help with your audit, contact your current solution provider or contact DomainCocoon.

Comment now on domain name locking during UDRP proceedings

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.

DomainCocoon’s Comments on the proposed renewal of the .COM Registry contract with VeriSign

Below you will find a copy of the renewal of the dot-com registry agreement with VeriSign as proposed by ICANN. You can also find our submission on the ICANN website.

The deadline for submitting comments is at 23:59 UTC today. The contract proposes an renewal of the agreement with VeriSign (as opposed to opening the contract to bidding) and will allow VeriSign to continue to increase prices by 7% for four out of six years.

Summary:

DomainCocoon opposes the renewal of the current dot-com contract with VeriSign under the terms proposed by ICANN. We believe the contract should be open to both public scrutiny and bidding from interested parties.

Background:

In our daily work we interact with VeriSign as well as with many ICANN-accredited registrars and their interfaces. We always have valued the level of support VeriSign provides to its registrars and have been impressed with the stability of the services it offers.

That being said, we’re surprised to learn that ICANN proposes to re-assign the COM operational contract to VeriSign without further review of any potential competitive bids. This is especially astonishing when bearing in mind that intricate details of the current version of the contract are merely the result of a lawsuit settlement between ICANN and VeriSign. The settlement in question was forged without public input from community and stakeholders, and without much information given to the public at large. The main concern of the contract, though not the only one, is a provision which permits a price increase of 7% for four out of six years.

It seems unrealistic for this price increase to be necessary, let alone to open a venue for continued increases in the first place. Since the cost of technology bandwidth and other related factors have significantly come down over the years and will most likely continue to reduce, the provision mentioned is anti-intuitive to the idea of spreading technology and nurturing participation among Internet users.

Especially in light of the much lower registration prices for .NET names, for which VeriSign operates a similar Registry infrastructure, the cost on a per domain name basis should be lower for the .COM registry operation. This is mainly due to the higher volume involved in .COM. Consequently, the cost should decrease with the larger .COM transaction volume, not increase.

Thank you for your consideration.

Frank Michlick,
Consultant/Founder for DomainCocoon Inc.

DomainCocoon is a consultant to registrars, resellers and hosting companies. Amongst other services we currently help to manage three active ICANN accredited registrars that also offer registration services for COM/NET domains and others. Since our company also holds a portfolio of about 800 domain names, we also see ourselves on the commercial registrant side.

Setting up an Offshore Domain Registrar: 5 Things to Keep in Mind

Judging from the inquiries we received over the last couple of weeks, apparently a number of people are looking at setting up an offshore domain registrar. So I figured it would be a good time to summarize 5 items to keep in mind when becoming ICANN accredited with an offshore company.

  1. Becoming accredited is just one step, you will also need a registrar solution (software or hosted service) to run your new domain name registrar.
  2. If you are looking at a hosted registrar solution, you will most likely only be hosting your registrar front-end on offshore servers. Make sure you know where your hosted registrar provider’s servers are located, as they may be subject to another jurisdiction.
  3. While your offshore jurisdiction may offer protection against legal “attacks”, the registry will be still located in another jurisdiction. While it is likely that the registry will fight anything that could set precedence and make them responsible for actions of registrants, it is still a possibility for a potential complainant to go directly to the registry.
  4. The commercial liability insurance that ICANN requires you to have is usually more expensive for an offshore entity than it is for a company located in the US or Canada.
  5. Do not buy an existing registrar, if the company is not already accredited in the right jurisdiction. Changing a jurisdiction for an existing registrar is complicated and takes time. In most cases it is easier to set up a new registrar.

DomainName.com Registrar For Sale

While DomainCocoon in general recommends becoming ICANN accredited from scratch versus purchasing an already accredited registrar, the auction happening today may be worth a look. As reported by Domain Name News, the registrar company, a customer base of 8,000 domains, some hosting accounts and domain DomainName.com are all up for sale. The Buy It Now price of $3,000,000, which expired yesterday, seems rather high for our taste, but who knows how much room there is for negotiation.

[Update] The registrar was sold successfully, the price was not made public at the time. Today, the domain name seems to be used for brokerage service.

Iron Mountain to Offer Additional Audit Services for Registrar Data Deposits

When ICANN introduced the mandatory Registrar Data Escrow (RDE) for registrars in 2007, the program was a direct result of the problems experienced with the registrar RegisterFly. ICANN requires all registrars to deposit a copy of their whois information with an approved RDE provider in order to protect registrants from the loss of their domain. The system is trying to encourage registrars to deposit the underlying whois information for domains under whois privacy (which was one of the issues at Registerfly, since some of the ownership data was lost). Registrars under the old Registrar Accreditation Agreement (RAA) can still deposit whois proxy information, but the new RAA forces registrars to inform their registrants if this is the case.

In November of 2007, ICANN selected Iron Mountain as the preferred provider for RDE services. While registrars are free to select another (ICANN approved) provider, most, if not all, chose to go with Iron Mountain, also since there would be no additional cost involved. Today Iron Mountain announced in a press release, that it now offers an audit service for the submitted information.

With the ICANN Deposit Audit Service (IDAS) application, Iron Mountain systematically audits registrar escrow deposits, measures the integrity of those deposits, and reports the results to ICANN. The new application supplements Iron Mountain’s Registrar Data Escrow service. With this service, domain name registrars periodically escrow their registration information records to safeguard these intellectual property assets. Because the registration data is placed in an escrow account with Iron Mountain and verified through the IDAS application, it can be effectively retrieved by ICANN in the event of a technical, operational, or business failure of a registrar.

The additional reports will be used by ICANN to audit compliance of registrars. Details on how the audit works were not provided, but it can be assumed that the deposited data would be verified and compared with zonefile and registry records, since bulk querying the whois-servers of registrars would be against their terms of use.

“The goal of the data escrow program is to help ensure the security and stability of the Domain Name System by protecting the data associated with registered domain names in a secure escrow account,” said Mike Zupke, ICANN’s registrar liaison manager. “Iron Mountain’s Deposit Audit Service is the next step in a full range of programs and procedures that will work to safeguard registrants and maintain Internet stability.”

The new service underlines how important it is for registrars to comply with the RDE requirements and deposit accurate data. If you have yet to set up your RDE deposits and need help, you can contact DomainCocoon for assisting you with the process.