New gTLDs Whois Server

zigzagweb · February 15, 2016

Hi Brian

thanks for replaying with more info. much appreciated.

I am not sure why, but having the .TLDs|whois|match strings on the list in post #347 where all returning false results.

Many of which where as you suggest in your last post .TLD|whois.nic.TLD|string.

After changing them to what was suggested using those 2 resources as described in my last post above

(like |whois server|---whatever) All worked correctly.

So I will have to stick with what works and keep an eyes on it periodically.

I am quite new to WHMCS, I set it up a while ago with just few TLDs, I think there were about 12 or so, .com .net .org etc. About 2 weeks ago I had some time over the weekend and I thought, ok lets try sort it out and bring all those new TLDs into play.

I had no idea what I was getting myself into... 2 weeks on, and it is finally sorted... and I am a lot wiser!

My problem was

* First discovering the search results I was getting where all false.

* Then understanding why I get those false results - (meaning search results of domain taken when in reality it is still available)

* I assumed the search is done using resellerclub API and then discovered that WHMCS DOES NOT at all uses Resellerclub for searching.

* But uses /includes/whoisservers.php file with whois lookup match strings

* I also wrongly assumed this file would include ALL the new possible TLDs

* then discovered 99% of the domains I wanted to sale were not included on the list.

* So I came here to the forum, copied all I needed from this and other threads and entered it into that file

* Still had lots of false results...

* Then I had to find out HOW to find the correct whois servers and match strings.

* Enter them into the list and test that each is working. (compared results with other search sites)

The problem with supporting others (and I know it from my own experience) is that we can never assume what someone might or may not know. and this is a perfect example of that. I JUST DID NOT KNOW THE BASICS like that there is such a utility in WHMCS itself, or that not all TLDs are included, or that the match strings and whois server could change over time...

I describe all of this, for the benefit of others, who might be in same situation I was!

I am quite sure there are many new resellers who do not realise they get false results. I only stumbled on it because I was testing it a lot with domain names that were very unlikely to be registered and when they all came back as taken I realised I should test it against results from other sites.

thanks again for all your help

Best

OA

Edited February 15, 2016 by zigzagweb

brian! · February 15, 2016

Hi OA,

thanks for replaying with more info. much appreciated.
I am not sure why, but having the .TLDs|whois|match strings on the list in post #347 where all returning false results.

Many of which where as you suggest in your last post .TLD|whois.nic.TLD|string.

it's those asterisks that will be causing the issue - find out the reason why they exist on your file and any strings posted in the future should work.

After changing them to what was suggested using those 2 resources as described in my last post above (like |whois server|---whatever) All worked correctly.

it's more likely to be working because you typed them in instead of copy&pasting existing text... I bet if you typed in any of the ones that i've posted, they'll work too! :idea:

So I will have to stick with what works and keep an eyes on it periodically.

as will I!

I am quite new to WHMCS, I set it up a while ago with just few TLDs, I think there were about 12 or so, .com .net .org etc. About 2 weeks ago I had some time over the weekend and I thought, ok lets try sort it out and bring all those new TLDs into play.

I had no idea what I was getting myself into... 2 weeks on, and it is finally sorted... and I am a lot wiser!

yep, two weeks sounds about right!

and they're never finally sorted - it's always an on-going project as they change often... :mad:

My problem was
* First discovering the search results I was getting where all false.

* Then understanding why I get those false results - (meaning search results of domain taken when in reality it is still available)

* I assumed the search is done using resellerclub API and then discovered that WHMCS DOES NOT at all uses Resellerclub for searching.

that was another reason in the past why I didn't sell my file - I thought with the then forthcoming v6, using whois was going to be a thing of the past... and here we all are, still using it. :roll:

you might want to take a look at the free addon below - that can use the resellerclub API for searches.

http://www.whmcs.com/appstore/329/FREE-ResellerClub-Tools-v2.html

* But uses /includes/whoisservers.php file with whois lookup match strings
* I also wrongly assumed this file would include ALL the new possible TLDs

this thread exists because we know that it doesn't!

* then discovered 99% of the domains I wanted to sale were not included on the list.
* So I came here to the forum, copied all I needed from this and other threads and entered it into that file

* Still had lots of false results...

well if they were old threads/posts, they might fail... the file needs to be regularly checked and updated.

* Then I had to find out HOW to find the correct whois servers and match strings.

for anyone wanting the documentation on that...

http://docs.whmcs.com/Domains_Configuration#Adding_Additional_WHOIS_Services

I am quite sure there are many new resellers who do not realise they get false results.

oh i'm absolutely certain that occurs - the example that sticks in my mind is that between v5.3.14 and the full release of v6, the correct settings for .cn changed... they updated it in one of the early betas, but anyone not in the beta program wouldn't have realised that searches for .cn were giving false results (e.g not available) until they noticed a drop in sales - and perhaps not even then... that went on for weeks, perhaps months.

I only stumbled on it because I was testing it a lot with domain names that were very unlikely to be registered and when they all came back as taken I realised I should test it against results from other sites.

you shouldn't really need to use other sites - just use a phrase that should be registered (nic.TLD will nearly always be registered), and then use a random string.TLD and that will usually be available.

zigzagweb · February 16, 2016

Oh man if that was the only issue I would be dancing....

Yesterday was watching my partner as he tried to order 2 domains, and boy the problem runs deep...

He tried ordering .xyz and .market - both failed - why? because they were PREMIUM DOMAINS

of course search results were not showing them to be premium domains and sowing them as AVAILABLE TO REGISTER.

On top of it all error log was reporting 2 different reasons for the fail and only one triggered an email JUST TO ME that registration failed.

WHAT A MESS!

Also the following domains from rightside: .ENGINEER, .MARKET, MORTGAGE, .DEGREE, .SOFTWARE, .VET, .GIVES, and .REHAB

Highly-regulated TLDs: .DENTIST, .ATTORNEY, and .LAWYER Military TLDs: .ARMY, .NAVY, and .AIRFORCE.

Trigger their own specific Terms and Conditions which of course DO NOT APPEAR anywhere during the registration process - therefore regardless of a domain being or not a premium domain, registration would fail.

WHAT A MESS!

we are expected to sell and refund sell and refund all day long?????

Not to mention the litigation risk attached....

NO, this is unacceptable.

p.s. Do you use the free addon below - that can use the resellerclub API for searches. http://www.whmcs.com/appstore/329/FR...-Tools-v2.html

if so why would you still need to update the whoisserver.php?

Best

OA

brian! · February 17, 2016

Yesterday was watching my partner as he tried to order 2 domains, and boy the problem runs deep...
He tried ordering .xyz and .market - both failed - why? because they were PREMIUM DOMAINS

of course search results were not showing them to be premium domains and showing them as AVAILABLE TO REGISTER.

that's not really the fault of WHMCS software - unless you want to argue that WHMCS should have developed API solutions for the major registrars for the v6 launch - it can only go on what the whois server replies... if it doesn't return a result of the domain being registered, it assumes that it's available.

the basic rule with premium domains is to either use an API/EPP solution or don't sell them - off the top of my head, I can think of three API solutions (Enom, Resellerclubtools and Hexonet)... but there may be others that aren't springing to mind...

Also the following domains from rightside: .ENGINEER, .MARKET, MORTGAGE, .DEGREE, .SOFTWARE, .VET, .GIVES, and .REHAB
Highly-regulated TLDs: .DENTIST, .ATTORNEY, and .LAWYER Military TLDs: .ARMY, .NAVY, and .AIRFORCE.

Trigger their own specific Terms and Conditions which of course DO NOT APPEAR anywhere during the registration process - therefore regardless of a domain being or not a premium domain, registration would fail.

but there is a built-in feature to handle this - Additional Domain Fields - it's in the documentation just below the link I posted in the above post.

http://docs.whmcs.com/Domains_Configuration#TLD_Specific_Additional_Domain_Fields

Certain TLD's have various additional requirements to the regular name & address information that customers normally provide during signup. For example things like Legal Types, Company ID Numbers, Registrant Names, etc... So for these we have a feature in WHMCS called "Additional Domain Fields".

These are defined in the file /includes/additionaldomainfields.php and consist of a name which is used to reference the values via modules, a DisplayName which can be used to override what a client sees in the frontend, and also a LangVar option which overrides even the DisplayName setting to take the field name from the text defined in a language file if set.

With the sub-options of a dropdown field type, those can also be specified in a format so that the display value is different to the value passed through to modules like this: "key|display name". So for example you could have "C11|US Citizen,C12|Permanent Resident,etc..."

This allows you to fully customise and localise the TLD specific additional fields to your customers should you need to add any alternative/additional text or guidance. The data the client provides can be viewed towards the bottom of their Domains tab.

as an example, for those Rightside (and highly-regulated) TLDs that you mention above, when you sell them through OpenSRS, you need to add a link to Exhibit A (a document on the OpenSRS website) - you can do that via the above method and add a checkbox (which will appear during the registration process in the cart) that the client is required to tick to show they have agreed to the content.

even for the military ones, it doesn't specifically say so, but OpenSRS would probably just need the same link to Exhibit A during ordering... that document contains the following...

.ARMY, .NAVY, .AIRFORCE: In the case of an .ARMY, .NAVY, .AIRFORCE registration, as a regulated TLD, the following conditions apply:

You agree to the Rightside Inc. Acceptable Use and Anti-Abuse Policy, located at http://rightside.co/registry/for-registrars/#c290

You acknowledge that TLDs offered by Rightside Inc. will have non-uniform renewal registration pricing, such that the fee for a domain name registration renewal may differ from other domain names in the same or other Rightside TLDs.

You must take steps to ensure against misrepresenting or falsely implying that you or your business is affiliated with, sponsored or endorsed by one or more country's or government's military forces if such affiliation, sponsorship or endorsement does not exist.

anyway, we don't offer these military domains as they'd be very little call for them.

it's also worth mentioning that while you can add these domain fields, they may not necessarily be passed during automated domain registration - each registrar might require slightly different specifics, so it's not really possible to produce a generic list that will work for everyone... although the information entered should be available to you in the admin area.

i'm quite happy to berate WHMCS about their TLD knowledge and support (though it's not worth the effort!), but on this score, i've got some sympathy for them - if it were simple to produce such a generic file, i'd have been willing to write and sell it alongside whoisservers.php, but it's a lot of hassle for no real gain.

http://forum.whmcs.com/showthread.php?110871-Customize-additionaldomainfields-php-for-new-TLDs

WHAT A MESS!
NO, this is unacceptable.

it's not really a mess - but selling TLDs (beyond the most common ones), can get complicated and unless you're prepared to put the work in (or find someone who already has done), it's easier to stick to the basics.

there are lots of potential minefields with TLDs and WHMCS - you've come across 3 already - whois, premium domains and domain fields... i'll give you a fourth that most are ignorant upon - Whois Privacy (ID Protection), you'd be surprised how many users think that Whois Privacy can be applied to all TLDs - but it can't... the general rule is that you can use it for gTLDs and not for ccTLDs - but there are many exceptions to that rule for both.

p.s. Do you use the free addon below - that can use the resellerclub API for searches. http://www.whmcs.com/appstore/329/FR...-Tools-v2.html
if so why would you still need to update the whoisserver.php?

we use it on one of our devs, but not on any live sites - we utilise multiple registrars with WHMCS, with a highly customised domainchecker and domain settings, so it's of little use to us on a live site... updated pricing is imported via another method.

I believe that the addon uses whoisservers purely as a backup in case the TLD isn't supported by API or an API result can't be determined.

as to why the live sites uses our whoisservers file - it's simple, we don't offer TLDs that include premium domains and I can trust the file to be accurate. :idea:

anishyaas · February 26, 2016

Till today, i didnt find " .desi" domain who is details .

Can anyone help me to find .desi working who is for whmcs ?

brian! · February 26, 2016

try using...

.desi|whois.nic.desi|queried object does not exist

satsuke · February 27, 2016

Why I cant register ".top" domain with whmcs last version? it always says that domain already registered.

brian! · February 27, 2016

Why I cant register ".top" domain with whmcs last version? it always says that domain already registered.

because the entry for it in whoisservers.php is wrong - it should be....

.top|whois.nic.top|queried object does not exist

satsuke · February 27, 2016

Nice brian!

Btw, what's the difference between that codes?

It just "No match" and "queried object does not exist" I thought that's a comment line.

brian! · February 27, 2016

they're just the whois response strings that WHMCS checks for to see if a domain is available - for .top, it used to be "No match", and now it's "queried object does not exist" - it will probably change again sometime in the future!

satsuke · February 28, 2016

How do you determine it?

layeronline · February 28, 2016

Is there a way to have a secondary whoisserver.txt so the original one won't get overwritten from upgrads?

brian! · February 28, 2016

Is there a way to have a secondary whoisserver.txt so the original one won't get overwritten from upgrades?

before upgrading, you are supposed to make a backup first!

so if you do, your modified whoisservers.php file will be your backup and you can restore it after the update is complete.

cosmin · March 1, 2016

Anybody know the whois for this extensions?

.cooking

.download

.trade

.yoga

.best

.jobs

.thanks!

brian! · March 1, 2016

try using...

.best|whois.nic.best|queried object does not exist
.cooking|whois.nic.cooking|queried object does not exist
.download|whois.nic.download|queried object does not exist
.jobs|whois.nic.jobs|No match for
.trade|whois.nic.trade|queried object does not exist
.yoga|whois.nic.yoga|queried object does not exist

Terra · March 1, 2016

Hi Brian,

Can you help with

.click

.design

.help

Many thanks, Edith

- - - Updated - - -

ah, the free list by brontobytes came to the rescue, here's the answer in case somebody else needs it:

.click|whois.nic.click|is available for registration
.help|whois.nic.help|is available for registration
.design|whois.nic.design|DOMAIN NOT FOUND

cosmin · March 3, 2016

Brian, all extensions are working!

Thank you very much!!!

Terra · March 4, 2016

Just got this from Afilias Technical Support (.PRO domains):

Please be advised the whois for .pro has been changed to ' whois.afilias.net '.

The old 'whois.registrypro.pro' is no longer working, just times out, the new one above works fine:

.pro|whois.afilias.net|NOT FOUND

brian! · March 4, 2016

thanks for the update on this, Edith! :idea:

cosmin · March 7, 2016

Anyone know the whois for

.archi

.beer

.bid

.buzz

.casa

.club

.engineer

.fit

.garden

.work

Many thanks!

brian! · March 8, 2016

try using...

.archi|whois.nic.archi|queried object does not exist
.beer|whois.nic.beer|queried object does not exist
.bid|whois.nic.bid|queried object does not exist
.buzz|whois.nic.buzz|queried object does not exist
.casa|whois.nic.casa|queried object does not exist
.club|whois.nic.club|queried object does not exist
.engineer|whois.nic.engineer|Domain not found
.fit|whois.nic.fit|queried object does not exist
.garden|whois.nic.garden|queried object does not exist
.work|whois.nic.work|queried object does not exist

most of the above aren't even in the "updated" v6.3RC1 whoisservers.php file... and one of the few that is, is wrong! :roll:

it seems leopards really don't change their spots.

cosmin · March 8, 2016

@brian!,

all works OK.

Many many thanks!!!

Vservs · March 13, 2016

Hi

.amsterdam|whois.nic.amsterdam|is free

Is not working, on vservs.amsterdam i get correct info back, but vservs111.amsterdam says in red header The domain vservs111.amsterdam is already registered > but in whois output it says:

WHOIS Output

---Domain Name: vservs111.amsterdam

Domain Status: free

>>> Last update of WHOIS database: 2016-03-13T16:00:47Z <<<

Record maintained by: SIDN

Who has correct line?

brian! · March 13, 2016

you found it yourself...

.amsterdam|whois.nic.amsterdam|Domain Status: free

Vservs · March 13, 2016

Thanks allot

New gTLDs Whois Server

Recommended Posts

Link to comment

Share on other sites

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Popular Posts

brian!

brian!

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Similar Content

Recently Browsing 0 members

Important Information