Root servers and transition
jdfalk@cybernothing.ORG (J.D. Falk) writes:
Well, let's take the most extreme case, where NetSol suddenly ceases performing the services of the InterNIC. In such an instance, we would hope that the root servers would continue to function as they are, without any changes being made until a new "A" server comes into being and is accepted by the root server operators.
In general the failure modes are the same as a huge snow storm, power failure, fiber cut, smurf attack or any of many other natural disasters which could hit the Network Solutions severing their connectivity. Speaking only of technical concerns, the root servers have seven (7) days from the date of the last update before "something" must be done. That something could be simply extending the expiration date of the zone files, and refreshing them; or changing their configuration to be primary for the root zone. Primary servers never expire; but may require some external coordination between the operators to assure consistency. This has happened on a few occasions in the past, and was generally a non-event to everyone except for those few people who keep track of these things. The zone files would be frozen at the last update until a new zone generation process was implemented. With NSI's latest pronouncements, this gets into the political realm. So I'll just leave it at that. GTLD servers operated directly by NSI, but housed in other locations have some other interesting failure modes, namely network engineer single point of failure. No matter what some network engineers may claim, I haven't found any system which could not be brought to its knees by its own network engineers. I don't believe any zones are solely dependent on the GTLD servers operation. The in-addr.arpa, .mil, and .gov zones are sourced by others, nevertheless they have some interesting historical propagation problems through the "A" root server. Ceasing to function is really the easy case. The hard one is if the data is corrupted or otherwise made unusable. I don't know what proceedures the root zone operators have in place to "roll-back" zone files to an earlier version in case of corruption happening at the same time Network Solutions becomes unavailable. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation
On 03/26/99, Daniel Karrenberg <Daniel.Karrenberg@ripe.net> wrote:
"J.D. Falk" <jdfalk@cybernothing.org> writes:
But, would it really go that smoothly? How long can the root servers last without an A?
A very long time. Certainly long enough as to not affect Internet stability.
That's the answer that I'm sure we were all looking for (and even expecting), but it had to be asked.... On 03/26/99, Sean Donelan <SEAN@SDG.DRA.COM> wrote:
The zone files would be frozen at the last update until a new zone generation process was implemented. With NSI's latest pronouncements, this gets into the political realm. So I'll just leave it at that. [ . . . ] Ceasing to function is really the easy case. The hard one is if the data is corrupted or otherwise made unusable. I don't know what proceedures the root zone operators have in place to "roll-back" zone files to an earlier version in case of corruption happening at the same time Network Solutions becomes unavailable.
Good question...not to put y'all on the spot or anything, but do any of the root server operators already have some procedures in place for such an occurance? ---------========== J.D. Falk <jdfalk@cybernothing.org> =========--------- | "Confusion is mightier than the sword." | | - Abbie Hoffman | ----========== http://www.cybernothing.org/jdfalk/home.html ==========----
On Fri, 26 Mar 1999, J.D. Falk wrote:
Good question...not to put y'all on the spot or anything, but do any of the root server operators already have some procedures in place for such an occurance?
RCS, either regularly triggered: */15 * * * * ci -u -m"Zone Update" root.zone.secondary.file ; co -l root.zone.secondary.file (Add your own wrapper to ensure you don't RCS the file during an actual zone reload) or the same triggered on a zone change (logsurfer/named-xfer). The important thing is to keep copies of zone changes as they occur which you can roll back if required. Add your own dns-lint/awwooga, too many changes scripts. (I run RCS on the zones under our control, but not as yet on the zones we secondary; just give me a few moments ;) ) The 'Internet' is a physical and social network which was founded on casual trust. Hackers have shown that this trust can be abused, Crackers have shown that it will be abused. And NetSOL? --==-- Bruce. si libet alius me dat, domina
On 03/27/99, Bruce Campbell <bc@vicious.dropbear.id.au> wrote:
The 'Internet' is a physical and social network which was founded on casual trust. Hackers have shown that this trust can be abused, Crackers have shown that it will be abused. And NetSOL?
I think NetSol is showing us that trust or distrust should be determined not on the basis of the function that a company provides, no matter how seemingly altruistic, but instead on the controlling interests behind that company. In other words, trusting or distrusting the InterNIC has become totally immaterial because Network Solutions has the ability to make drastic changes at any time -- instead we must decide whether or not to trust Network Solutions. This is becoming political, so I'll stop now. ---------========== J.D. Falk <jdfalk@cybernothing.org> =========--------- | "Life is a bridge. Cross over it but build no house on it." | | -- Gautama Buddha | ----========== http://www.cybernothing.org/jdfalk/home.html ==========----
participants (3)
-
Bruce Campbell -
J.D. Falk -
Sean Donelan