Understood.
Note that adding nameservers to the registry(ies) is realtime, and you
don't have to wait for the update.
Charles Daminato
TUCOWS Product Manager
chuck@tucows.com
On Fri, 22 Feb 2002, ST wrote:
> Hi,
>
> >Additionally, since not all OpenSRS resellers are enabled on all
> >suppliers, we'd have to only try to add to registries for which you're
> >signed up for, which is extra logic.
>
> Would this really matter? My logic was basically "If I'm going to add this
> host name to .info, I might as well add it to .biz and even .com, if it's a
> ccTLD, so that if someone else needs to use this hostname for a .biz domain,
> they won't get an error." It's really more of a public service. It may
> benifit me in the future, or it might benifit another RSP or a customer of
> another registrar. Or maybe it will benifit no one.
>
> I finally posted my suggestion to the list yesterday after adding a ccTLD to
> .info for a customer. Ironically, I received the following from the customer
> today:
>
> <snip>
> Thank you. That helped.
>
> But - now I have the same(?) problem with .info. I have tried to change
> nameservers for "$domain.info" and "$domain.info".
>
> Could you please help with that problem too?
> </snip>
>
> My immediate thoughts about this were that I should have just added the
> hostname to .info yesterday, which would have saved myself a minute or two,
> and the customer about a half a day of waiting, since he missed the root
> update. And knowing that, I can't help but think that I should go ahead and
> add hostnames to both .info and .biz in the future. I actually feel kinda
> dumb that I didn't do it the first time. Which brings me right back to the
> idea that the system should do this automatically.
>
> ST
>
>
>
> -----Original Message-----
> From: owner-discuss-list@opensrs.org
> [mailto:owner-discuss-list@opensrs.org]On Behalf Of Charles Daminato
> Sent: Thursday, February 21, 2002 4:42 PM
> To: ST
> Cc: discuss-list@opensrs.org
> Subject: Re: Registry Nameservers
>
>
> There are some difficulties with this.
>
> If we make it add to "all" registries, as more and more registries are
> added the more expensive and time consuming (from a system POV) this would
> be. When a supplier is slow beyond measure (as happens from time to
> time), this could potentially fail and the command becomes useless (you
> can't add to any if it gets stuck up on one and times out).
>
> A good suggestion though; we may be able to figure something out...
>
> As for adding it to manage, the logic here is tricky. If we check before
> adding the nameserver, it's an extra command for each update. If we try
> to add it due to error, it's more time processing. Again, if the registry
> is slow, the update becomes impossible and the feature is useless.
>
> Additionally, since not all OpenSRS resellers are enabled on all
> suppliers, we'd have to only try to add to registries for which you're
> signed up for, which is extra logic.
>
> After reading through, I might just be making excuses. I will take this
> back for some thought and discussion internally to see what we can't do...
>
> The best thing would be for the registries to remove this unneeded
> restriction!
>
> Charles Daminato
> TUCOWS Product Manager
> chuck@tucows.com
>
> On Thu, 21 Feb 2002, ST wrote:
>
> > Perhaps the "Registry Nameservers" tool in the RWI should be modified so
> > that it attempts to add the hostname to all the registries. It strikes me
> > that if a hostname such as ns1.blah.se needs to be added to the .info
> > registry, it may also need to be added to the .biz and .com registries. It
> > wouldn't hurt to have it try, so that it can save someone the trouble of
> > possibly having to add it later.
> >
> > You could just replace the link for Registry Nameservers with a one field
> > form that would attempt to add the hostname to all registries.
> >
> > Ideally, it would be great if manage.cgi could detect that a hostname
> needed
> > to be added, then add it to the appopriate registries, and then finally
> > update the domain that the user it trying to update, instead of giving
> them
> > an error message.
> >
> > ST
> >
> >
>
>
This archive was generated by hypermail 2.1.3 : Tue Oct 19 2004 - 23:37:03 EDT