I recently had a difficult situation when my ISP suddently went out of business without warning, stranding my domain, DSJ.NET, on his servers. Usually, I would simply email a request to Network Solutions (the dot com people where I have my domain registered) and they would check the origins of my email, verify from the headers that it came from me, the owner of the domain, and then they would execute the request to host the domain on different name servers or to modify the contact information. But this was impossible in my case, because all the mail Network Solutions or anyone else directed to dsj.net wound up going to a mail server that either no longer was running or that no longer could forward mail to my local mail server. I could no longer receive mail at that address. And without being able to receive mail at that address, Network Solutions could not verify that the request to change the email address for the administrative and technical contact for the owner of the domain. It was a Catch-22 situation.
Finally, I am back in shape. But I have a few lessons learned that will apply to you UNIX/Linux geeks out there who like to run your own nameservers or who host sites on your own computers, or who receive mail from your ISP's server to your own Sendmail (or other mail) server.
Your contact email address. The email address that you use for your domain contact address should be an address that you can get to anywhere, not one that depends on a connection which might go away. In other words, don't make your contact email address yourname@yourdomain.com unless you're sure you'll always be able to get your mail from that server. What if the person who hosts that domain suddenly goes out of business? What if your dedicated lines goes down indefinitely for reasons beyond your control? What if you must make a change ASAP, but that mail address is inaccessible?
I recommend that you use an address that you can get to from anywhere at anytime. Make it a Yahoo or pobox or some other kind of forwarding address or something. That way, you can get it from a coffee shop or a borrowed internet connection if you have to.
MAIL-FROM authentication. One of the ways your domains requests are authenticated is by "MAIL-FROM:". This simply makes sure that the mail requests actually come from who they're supposed to come from through email header parsing. However, this method is not secure, because it's possible to forge headers and spoof IP numbers in network packets. Some authentication servers can be tricked into thinking that Joe "Bad Guy" Blackhat is actually you because he spoofed his headers to look like they came from your machine. So, you shouldn't depend on a MAIL-FROM method for authenticating requests to modify your domain.
Other authentication methods are PGP and Password. PGP is my first choice, but unfortunately this isn't always reliable either. It's not because PGP or GPG (Gnu Privacy Guard: see www.gnupg.org) are at any sort of fault, but rather because Network Solutions doesn't keep their PGP keyservers running reliably. There doesn't seem to be anyone there with sufficient knowledge or expertise to do so. Why they don't use the normal network of keyservers, I don't know. They probably think public keyservers are vulnerable to being hacked. But their own keyservers rarely work, so maybe it's security by denial of service? Go figure.
Anyway, that leaves us with an encrypted password method of authentication. This is more secure than MAIL-FROM, and it's better than trying to use a PGP keyserver that isn't available. But it's still not super secure. It will have to do, though, until another reliable method of authentication is implemented.
Authorized Relays. Another problem you can run into is that when you send mail from your local mailserver, your mail will be bounced because it won't be relayed. Since your ISP has disappeared or your dedicated connection has gone down, there is no authority to say your mail server is an acknowledged server. Therefore, your mail won't be relayed by your recipient's mailserver. You'll get a bunch of returned messages back with errors like ``invalid host'' or ``no authorized host found''.
One way to get around this problem is to route your mail through an acknowledged mail forwarder, otherwise known as an SMTP server. This is normal for people who run Windows or Mac and use mail clients instead of mail servers. But in UNIX we're pretty used to simply using our own local servers.
The way you route your mail through another smtp server is to change the address thusly:
John Doe <@smtp.myisp.com:jdoe@hisisp.com>
Notice the ``@smtp.myisp.com:'' between the brackets?
That's the trick. This just tells your mail server to route the
mail first to ``smtp.myisp.com'' before sending it to
``jdoe@hisisp.com''. For more information on this, check out the
manpage for ``mailaddr''. Typing man 7 mailaddr should do
the trick.
SMTP Authentication. There's still the problem of using an smtp server when you're between ISP accounts. Let's say you have to use smtp.yahoo.com's smtp server, which requires smtp authentication? How do you handle that? It's simple if you use Eudora on Windows; there's a checkbox for smtp authentication in the configuration options. But what about if you're using Mutt or Pine or Elm or something?
Fortunately, you're running UNIX, so you can explicitly tell Sendmail (or whatever your MTA is) exactly what to do. You don't have to leave it up to your MUA. You can define a smart host. That is, a host through which your SMTP server routes all outgoing mail bound for outside your network. For more information, see the documentation for your MTA and look for the explanation of setting up a ``smart host.''
Secure FAX. This is a contradiction of terms: ``secure'' and ``fax''. But, because I couldn't use my email to authenticate my domain requests, I had to fax my request on company letterhead with the ``contact modify request by fax'' form, and I had to include a copy of my driver's license. This method eventually worked. But it was not without pain or anxiety on my part.
It took 4 faxes before someone who could actually help me got the request. Two faxes went to the standard Network Solutions fax fax number for domain requests, and after those had gotten lost in their system, a third fax went to some tech's special fax number. Somehow, that fax also got lost. So, I now had three copies of my driver's license floating around on fax machines across the country, and still my domain's contact information had not been modified.
The fourth fax finally went to a fax machine right next to the person I talked to on the phone. He was right there when it came over the wire, thank goodness. My request was executed instantly, and the WHOIS database was updated within about 12 hours or so.
A Better Way. While I was glad to finally get all this done, I really wished it could have been smoother and more organized. Since I've had my domain since 1996, back when Network Solutions (called InterNIC then) was the only authorized domain registrar around, making changes to my WHOIS information wasn't really anything new. I had a pretty good idea of how things should go. And I had even used PGP before too. I was really happy with the security of that method, even if not many people knew what it was over the phone. But now I'm told that PGP is no longer an acknowledged method of authentication at Network Solutions.
I haven't checked other domain registrars yet. I have seen some pretty inexpensive competitors out there. If one of them has a better price and a better method of authentication, I'll be buying their services.