At 11/6/02 1:14 PM, OpenSRS Replies wrote: >On Monday November 4, 2002 it came to our attention that the >'Transfers Away Notification' functionality in OpenSRS had not >been running correctly for four days - from October 31, 2002 until >November 3, 2002. At that time, we re-initiated the functionality >and ran the notifications for requested transfers that had arrived >as of October 31, 2002.
It unfortunately seems like this kind of thing has happened a few times recently. Perhaps some engineering resources could be dedicated to creating regression tests and monitoring systems that check that each system is working every so often with an end-to-end test. I've found this tremendously useful in my business. For example, I have a fairly complicated Apache server setup, and I was always worried that I'd break something whenever I made a change to the httpd.conf file or upgraded Apache. So I setup a test account on the server for each type of client we have (a test account that works identically to a real account), then spent a day writing a program that makes several dozen different types of HTTP requests (every possibility I could think of -- CGI with POST, CGI with GET, PHP with POST, PHP with GET, SSL combinations of each, etc.) to each test account and compares the result to the "expected" result. Now when I make a change to Apache, and at regular intervals otherwise, I run that program and I can guarantee that everything we support is working properly. Same thing with mail: I have a cron job that injects mail to addresses at the test accounts every five minutes (via SMTP), and another that attempts to read the mail that was injected (via POP). If no mail can be read for ten minutes, an alarm is triggered and my pager goes off. I'm a strong proponent of monitoring systems by their result (Did SMTP injected mail actually get delivered and read through the POP server? Does the HTML response contain the text that the PHP script should have generated?), rather than programs that check servers indirectly (Does the SMTP server answer on port 25? Does the HTTP server respond on port 80?). In the case of transfer away notifications, OpenSRS could create a system that submits a transfer away request for a test domain every hour, and then reads the domain's admin mailbox and reseller's contact mailbox for the notification messages (and cancels the transfer request). Every hour, you should get one "transfer away" message and one "transfer has been canceled" message at each address: if any of those don't arrive for two hours, something's wrong. Similar things are possible for other parts of OpenSRS. Anyway, just my 2 cents. >The 'Transfers Away Notification' is now operating normally. We >would like to stress to you, that 'Transfers Away Notification' >should not be used as an alternative to 'Name Locking' for name >security. The 'Transfers Away Notification' functionality relies >on too many sources of information outside of our control to be >considered a security tool. It is an informational tool only. >In order to prevent unauthorized Transfers Away, we recommend that >Resellers utilize the 'Name Locking' functionality in OpenSRS. Has there been any progress on creating a message to resellers that will notify us when a domain has actually been transferred? This "Transfer Away Notification" that tells us that the process has been started is currently the only message we get, but it doesn't tell us if the transfer away was completed. ------------------------------------ Robert L Mathews, Tiger Technologies
