Who's Responsible for Your Domain Name?

How much value do you attach to your domain name? Many companies seem to treat theirs as if it is only worth the $20 or so they might have spent to register it in the first place.

"Now wait a minute," you might be saying, "we know that it's an extremely valuable business asset." I'm sure you do. So who's responsible for it?

Hint: "My ISP handles all that stuff" is a bad answer.

Two years ago, I got a frantic call from one of my clients - a small insurance firm. They weren't getting any e-mail. A brief investigation soon revealed why - their domain had expired.

Typically, when your domain is in danger of expiring, your registrar will send you numerous e-mails, and probably a letter or two. After all, if your domain expires, they won't collect your renewal fee.

In this case, however, the domain had originally been registered by their previous consultant, and his e-mail address was associated with all the contact information for the domain. He had subsequently shut down his business - so e-mails to him went nowhere. The insurance company had also moved to a new office - so the physical address associated with the registration was wrong. The phone and fax numbers had changed. Even the credit card that had been used to pay for the registration had been cancelled. There had simply been no way for the registrar to contact my client - and no one at the client had realized the need to update the information. They are not a technology company - that's the sort of thing they relied on their 'computer guy' to handle. When their previous consultant left, the domain registration had 'fallen off the radar.'

The lesson I learned was that I could never assume that a new client had anyone who was responsible for their domain, and my 'best practices' for new clients now includes a domain audit.

Among the things that I recommend:

• Domain registrations include several contacts: at a minimum, there will be an Administrative contact and a Technical contact. It is not uncommon to have a Billing contact as well, and there may also be a separate Registrant for the domain. All the contacts should not be the same person! At a minimum, the Administrative contact and Technical contact should be different, and at least one of them should have a contact e-mail address that is not in the registered domain. (If the domain is offline, or there are transfer issues, it may not be possible to reliably send e-mail to addresses within that domain.)


• Your company's network documentation file or binder (you do have one, right?) should list the registrar, the contact information, and the expiration date for the domain. A specific individual should be responsible for domain renewal, and should have a reminder (whether it's an Outlook appointment, a reminder in their contact manager, or a physical 'tickle' file) to renew the domain before it expires. Do not rely on the registrar to contact you. They should, but if something can go wrong, it will. The same responsible person should update the records at the registrar if your company's phone number or address changes. Some pretty substantial companies, who should know better, have failed to renew their domains in time - with embarrasing or amusing results, depending on your point of view.


• Find out whether your registrar will allow you to lock your domain records (most will; many will have already done it for you) in order to prevent unauthorized transfers or changes to your records.


• Your documentation should also list the public DNS servers responsible for your domain (which might also be maintained by the registrar, or by your ISP, by a third party, or by your company itself - depending on the nature of your business, and the extent of your Internet presence.)


• The first entry in a DNS zone file is the SOA, or Start of Authority record, and it includes the e-mail address of the 'responsible' administrator for the domain. Make sure that this is a valid address (at a company where I just completed an e-mail migration, it wasn't) and that the mailbox associated with that address is monitored. This is often a postmaster, hostmaster, or root address, so that it doesn't need to be updated, even if the person who holds that role in the organization changes.


• Keep a copy of the DNS zone file itself, including the names and IP addresses of web servers and mail servers. If you ever have to reconstruct a DNS record from nothing (for example, after a botched transfer to a new ISP or DNS hosting company) this can mean the difference between getting back on the Internet in minutes or hours, rather than days.


• And if you're moving from one ISP to another, or changing registrars, have the process managed by a consultant or engineer who understands how DNS works - and who has successfully run migrations for other organizations. Ask for references.
  
  Done correctly, a move shouldn't even be noticable. But a botched move can result in a domain effectively vanishing from the Internet, and due to the nature of the DNS caching process, it may be impossible to completely correct for 24 hours or more. One former client - against my advice - chose to allow their new ISP to manage the move from their old one. Twice.
  
  Each time, they dropped off the Internet for more than a day. And when all of your revenue is generated from your web site, discovering that your home page now says "Future home of..." is cause for panic.
  
  Partly as a result of their experiences, I now avoid telling an organization's old ISP anything about a move until everything - web site, e-mail, DNS records - is up and running at the new one.

WHERE DO YOU START?

If no one seems to know who your registrar is, you should be able to look it up using the WHOIS tool at Whois Source. (Any registrar will have a WHOIS tool; I like this one because it will also display the former registration records for recently expired domains.) You can verify your records, and the expiration date of your registration.

James Ponder has written a fantastic online tool for all kinds of DNS diagnostics; you can use it to verify your SOA, MX and A records, and perform general troubleshooting on name resolution for your domain.

If you're curious about the inner workings of DNS, DNS and Bind by Paul Albitz and Cricket Liu is generally considered to be the reference. You should have a decent grasp of networking in general - and the TCP/IP protocol suite in particular - before you dive in.

Make sure someone's responsible for your domain name now, instead of after someone asks, "Where did our web site go?"