There is a modified version of the OpenSRS client (from an old version) that can do it.
It's a little awkward to use and very slow. It does work. I don't remember exactly where to find it, but a search of the list archive will uncover it. -- Lynn -----Original Message----- From: A. Sharif [SMTP:[EMAIL PROTECTED]] Sent: Saturday, June 22, 2002 12:56 PM To: Lynn W. Taylor; [EMAIL PROTECTED] Subject: Re: Nameserver Questions Is there a way to do a 'bulk nameserver' change in the Manage interface or OpenSRS RWI ? Thanks Abdul ----- Original Message ----- From: "Lynn W. Taylor" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, June 22, 2002 3:18 PM Subject: RE: Nameserver Questions > Hmmm.... > > One of the problems IIRC with the root-servers is that the root zone is so > gawdawfully large that it's hard to transfer. > > So, unless you're running a root server there is no reason to download > anything from NSI -- just query it. > > Now, aside from the root servers, there is the whole issue of TTL on the > individual zone files themselves, and if you have an old copy of DNS and > BIND it suggests some values for TTL that are, well, high. > > .... and that ignores the fact that some DNS servers (caching servers) > ignore TTL fairly dramatically. > > My experience of late is that NSI updates the .com TLD zone twice a day, at > noon and midnight Eastern time. It appears that the update is actually > live on at least one of the GTLD servers about 12 hours later, and the > change is in place on all servers about 12 hours after that. > > I've seen updates close to noon E?T actually hit the servers at midnight, > and I've occasionally missed the update and seen the change in the root 36 > hours later. > > As far as OpenSRS updating NSI, it appears that when you click on the > "change" button in the OpenSRS client, it contacts the OpenSRS servers and > they update the central registry via RRP immediately > <ftp://ftp.isi.edu/in-notes/rfc2832.txt>. This is one of the reasons that > "bulk" nameserver changes go slowly -- it doesn't just update OpenSRS and > then they update sometime later. > > -- Lynn > > -----Original Message----- > From: POWERHOUSE [SMTP:[EMAIL PROTECTED]] > Sent: Saturday, June 22, 2002 12:06 PM > To: Dave Warren; Charles Edmunds; [EMAIL PROTECTED] > Subject: Re: Nameserver Questions > > Actually I USED to work for AOL, I know for a FACT That some of the Smaller > ISP's USED TO only > download the master Database from ICANN only 1 time PER WEEK. > In fact, If memory serves me correctly, this was FIRST held by NetSol, > until > ICANN was formed. > > That was a few years ago, so I don't know about now, but I do know for a > fact that some of my customers > end up having to wait for 5 days before it works in their browser, when it > worked in mine within 24 hours. > > So, It still seems like SOME ISP's don't update every 72 rather at there > OWN > speed. > > Richard. > > ----- Original Message ----- > From: "Dave Warren" <[EMAIL PROTECTED]> > To: "POWERHOUSE" <[EMAIL PROTECTED]>; "Charles Edmunds" > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Saturday, June 22, 2002 1:54 PM > Subject: Re: Nameserver Questions > > > > *blink* No, this is not true... Unless the ISP is downloading root > zonefiles > > and running them locally for some reason. > > > > DNS servers cache root zone file entries for 72 hours maximum, as per the > > TTL. You'd have to be braindead to force a minimum TTL over 72 hours. > > > > > > POWERHOUSE wrote: > > > Keep in mind, that EACH ISP is different, on how often they update > > > there Database. > > > some do it only 1 time per week from what I remember, that may not be > > > the prob, > > > but It happened to me before, I thought it was a OpenSRS issue, but > > > it was just my > > > ISP at that time, had NOT updated the database, so It took a while > > > for ME to be > > > able to see the new propagation, but it was there. > > > > > > Anyways, just another point of view. > > > Rich > > > > -- > > The nice thing about standards, there is enough for everyone to have > their > own. > > > > > > > >
