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.
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.
No hay comentarios:
Publicar un comentario