Newly regged domains not resolving Few domains acquired (by back order) through name.com are still having issues. Now more than one week. Name.com has failed to get these domains transferred properly and now they are not resolving. Telnic, can you help to get these sorted out please? Thank you in advance. ++++ |
I tried to transfer away to another persons Name.com account, wouldn't let me do it after raising this with them this was Name .coms reply "The issue with transferring the domains is something that we are working on with Telnic to resolve with the API" They offered to transfer them manually, but still haven't done so. |
We received a similar reply from name.com. That's the reason we want to bring it to the attention of Telnic. Let's see what is their response. ++++ |
Here too, there is something wrong with the process and each is pointing fingers at the other. Took 2 weeks to fix americans.tel and I still have a couple others stalled. This process needs the attention of Telnic to solve and make simpler for the registrars. Mark |
Name have created a new CTH account in my list - ends in numbers. Anyone else experienced this? There is nothing in it, and I didn't ask for it. |
Quote:
Their CTH names with numbers are created by default if you don't type a name for the CTH. Most probably something has been transferred in OR they probably attempted to configure a domain if you had back ordered or something like that. ++++[/size] |
@TELcp, Ah! Thanks for the explanation. Now that I know why, I think I know what caused that to appear. |
I have contacted Name.com again regarding this issue. It would help if I had some examples of .tel domains affected, so please send me these if you have any. |
@Aled, Sent three domain names by pm. Thanks. |
Quote:
Is not just name.com DM as well I got some BO from them, I can go to my CTH and write information but nothing come live and in telnic manage tel as well nothing come on. Just click on these 2 .tel that I got on DM BO and you will see what I am talking about: http://ideal.tel http://minicab.tel And even wrong now is around 3 weeks since I got some .tel from DM BO and still does not work like these ones: http://movie.tel http://cinema.tel http://books.tel http://ebook.tel On Monday I will contact DM to see what they say. Regards http://supercyberheroes.tel[/size] |
I too have had BO names not resolving, took about a week, I like NAME.com however one thing really irks me, they constantly rejig their site, if it "ain't broke don't fix it", yes I know………you have to keep up with the times etc etc, but the constant changes IMHO go beyond fine tuning. |
So, according to the post #10 by Supercyberhereos of this thread, it is NOT just the name.com having issues in sorting out configuring/resolving. It is now very clear that there is a common factor causing these issues. Looks like all pointing fingers at the Registry. Can anyone think of something else other than Telnic, in this situation? Dear Telnic, it is your duty to look after your community whether they are registrars, resellers, third party developers, hobbyists, directory builders or telname's single page enthusiasts. Kind Regards ++++ |
With domainmonster, if you successfully win a back order, I can say from personal experience (consistently over the past 2 months) that you must follow up each domain win with a request to domainmonster staff to fix the resolving. They in turn contact the registry. It's fixed very quickly, so that's great |
Quote:
I had backorders at both DomainMonster.com and Name.com In both cases I had domains that were not resolving. With Name.com I simply went into the Domain Information and Manually "Assigned" them to the CTH Account and they began resolving. With DomainMonster.com I was forced to use the Support Ticket system and DomainMonster had the issue resolved within 2 days. All are resolving, and I have had to do this multiple times with multiple names at each registrar. All are working today. :cool:[/size] |
mixed bag from my view. both name and dm, some work straight away others need an email to help resolve. as mentioned before in one of my other posts, there's something wrong here and needs some attention to fix once and for all. |
There are .tel domains not resolving due to some unknown issue according to the registrar. We have done everything from this side.(We are quite familiar with client side issues when it comes to CTH maanagement/configuration at name.com's dashboard) And Name.com says they have done their best as well. ++++ |
Is anyone using familar with the following issue? as displayed in name.com dashboard: QUOTE: Telhosting Management Your domain is in the Community TelHosting (CTH) platform. However, we were unable to create the zone. REASON: not enough name servers available to fulfill your request for 5 name servers, because 5 name servers are blocked by at least one other zone. Manage this domain in the private account in the Community TelHosting (CTH) platform at https://telhosting.name.com. TEL MX Record Management UNQUOTE: The issue is "not enough name servers available to fulfill your request for 5 name servers, because 5 name servers are blocked by at least one other zone." When you get that msg user has no option other than inform support at name.com. But they (support at name.com) have failed to rectify this. One such domain having problem is www.brasilia.tel. It is still pointing to DM. ++++ |
Quote:
Not every is, glad you clarified your problem further, now it actually makes more sense. Definitely something crazy there ! :)[/size] |
To clarify the process with regards to a registrar setting up a .tel account for a name that has previously expired/been transferred: The registrar has two tasks when setting up a .tel in their partition: a. Creating the account in their partition (including setting the username and password) b. Setting up the domain and zone so that the .tel name points to that specific account. Having these as separate steps allows the registrar to prepopulate the .tel if they wish to do so (as many do). It also minimises any downtime for the domain in the case of a transfer since the account can be set up before the transfer even completes. As a domain can only have one zone, on launch of .tel we advised all registrars that they should delete the zone in their partition should a name be deleted, expired or transferred to another registrar. It soon became clear that this wasn’t happening and as a result “new” registrars were having an issue creating the zone as the “old” zone still existed. To circumvent this issue we updated the “CreateZone” command used by the registrars two years ago, so that an additional parameter could be used to force creation of the zone even in the event of another zone already existing. All registrars were notified of this update and how it could help them in the zone creation process, especially in the case of transfers and registration of recently expired names. A reminder was also sent to registrars a few months later. The zone creation command can only succeed if the registrar making the request matches the sponsoring registrar for the name. It seems that some commands are failing this requirement for one of two reasons: 1. The registrar company has a number of different registrar accounts which they use and they are making the request from a different account to the one actually used to register the name. I see that some registrars (e.g. Name.com) are using different registrar accounts for drop catching. The command must be issued from the registrar account to which the name was registered. 2. The command is made before the WHOIS has been updated to show the “new” registrar. It is possible that the issues some of you are experiencing are the result of “drop-catches” whereby the command is being made before the WHOIS has updated and is failing as a result. Reissuing the command (with the correct parameter for forcing creation of the zone) once the WHOIS is updated will ensure that the zone is correctly created and pointing to the “new” partition. Registrars also have the ability to manually create zones using their partition control panel. Creating zones in this way also deletes the “old” zone so that setup is complete. As mentioned, all registrars have been sent this information, and I also remind them of the steps required to make this a smooth process whenever I contact them regarding this issue. That is actually all I can do in this process. Names which have an issue which is then resolved, is resolved either by the registrar reissuing the create zone command correctly or manually creating the zone. The error message given above regarding the 5 nameservers being blocked means that the create zone command has failed either: 1. Because the “old” zone still exists and the additional API parameter has not been used OR 2. The command was issued from the incorrect registrar CTH account OR 3. The command was issued before the registrar became the sponsoring registrar in the WHOIS The situation where a user registers a name but when it is activated still shows the previous owner’s details is the result of the “old” zone still being active and the registrar not yet having created the new zone correctly. I apologise if this is overly technical for many, but with “fingers being pointed” at Telnic as stated above, I thought it was important that the process is explained fully. |
aled - appreciate the detailed response. very helpful and interesting. is there no way to centralise this back at telnic or does the way the whole system and zone files operate require this to be split up and delegated to the registrars? viewing this from 10,000ft it's easy to say that it should be centralised, appreciate there may be some hidden gotchas or reasons! |