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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Charles Daminato > Sent: Thursday, February 21, 2002 4:42 PM > To: ST > Cc: [EMAIL PROTECTED] > 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 > [EMAIL PROTECTED] > > 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 > > > > > >
