After verifying that the only problem server remaining was H, we managed to track down the keeper of H around 20:15 PST, he had nameservice down at 20:39 PST and back running with correct results now at 20:47 PST. Thanks to: altavista.digital.com - quick RFC reference to verify error code - found http://homepage.arl.mil/~jamesf/dns.html which verified who was responsible for the server (just confirmed the 'whois' data) www.switchboard.com - found his likely home phone number www.mapquest.com - verified that his home is just down the highway from where he works, confirming which home phone number was most likely jamesf@ARL.MIL - got the thing fixed well after working hours ought to be over and everyone on this list who sent me private mail confirming that the problem was global, not local. even if this isn't really the right list for DNS issues. now, to add an infrequent check of the root nameservers to our homebrew NMS, so our NOC operators can see these things happen as they happen, not after the fact. -matthew kaufman matthew@scruz.net
In article <199702140457.UAA08984@scruz.net> you write:
After verifying that the only problem server remaining was H, we managed to track down the keeper of H around 20:15 PST, he had nameservice down at 20:39 PST and back running with correct results now at 20:47 PST. [...] now, to add an infrequent check of the root nameservers to our homebrew NMS, so our NOC operators can see these things happen as they happen, not after the fact.
Should I even ask this? Where is the Internic's NMS for the root-servers to sound an alarm and get someone to act? And don't let them say that the resources aren't there: "Seventy percent of the [domain] fees collected will be retained by Network Solutions to cover operating costs..." -- Bob Kupiec GES / WNA http://www.ges.com/~kupiec Princeton, NJ
participants (2)
-
Bob Kupiec -
matthew＠scruz.net