This has been a fun topic of discussion on Server Fault. There appear to be varying "religious views" on the topic.
I agree with Microsoft's recommendation: Use a sub-domain of the company's already-registered Internet domain name.
So, if you own foo.com, use ad.foo.com or some such.
The most vile thing, as I see it, is using the registered Internet domain name, verbatim, for the Active Directory domain name. This causes you to be forced to manually copy records from the Internet DNS (like www) into the Active Directory DNS zone to allow "external" names to resolve. I've seen utterly silly things like IIS installed on every DC in an organization running a web site that does a redirect such that someone entering foo.com into their browser would be redirected to www.foo.com by these IIS installations. Utter silliness!
Using the Internet domain name gains you no advantages, but creates "make work" every time you change the IP addresses that external host names refer to. (Try using geographically load-balanced DNS for the external hosts and integrating that with such a "split DNS" situation, too! Gee-- that would be fun...)
Using such a subdomain has no effect on things like Exchange email delivery or User Principal Name (UPN) suffixes, BTW. (I often see those both cited as excuses for using the Internet domain name as the AD domain name.)
I also see the excuse "lots of big companies do it". Large companies can make boneheaded decisions as easily (if not moreso) than small companies. I don't buy that just because a large company makes a bad decision that somehow causes it to be a good decision.
Sure it might work, but why risk having DC2 poisoning your AD with out of date information?
A DCPROMO de-promote restart / DCPROMO promote restart is hardly a big undertaking. Whereas Manually editing things in ADSI & fudging DNS is hardly fun!
Best Answer
Step 0: Have at least two domain controllers.
If you only have one domain controller and it fails in such a way that you cannot recover it, then your domain no longer exists; your only option is to create a completely new domain. This is a painful process that involves recreating users, rejoining client computers and servers, and even recreating every security setting you ever used.
If the server is absolutely unrecoverable, such as due to hardware failure that cannot be easily repaired, then here is how to go about purging it from the domain completely. Once the FSMO roles have been seized, it is critical that the old server is never brought back online. Seriously consider wiping the harddrives to ensure that this can never happen.
Determine which servers were holding the FSMO (Flexible Single Master Operations) roles for the domain and forest. Microsoft has a great article on finding FSMO roles.
Any FSMO roles that were held by the crashed server should be seized on a healthy domain controller. Another Microsoft article for this one.
The "Infrastructure" FSMO role is special, and is actually specified for each application partition. If the crashed server held DNS, you will need to verify that the record in each application partition (DomainDnsZones, ForestDnsZones) has been updated. Better explanation here and official fix here.
Perform a metadata cleanup to remove remnants from Active Directory. Deleting extinct server metadata.
Inspect "Active Directory Users & Computers" and "Active Directory Sites & Services" to ensure that all entries for the extinct server have been removed.
Inspect DNS to find any static entries that were related to the extinct server, and either delete them, reassign them, or put a new server at the same address.
If the crashed server was an authorized DHCP server, check to see if it's still listed as an authorized server. If yes, you may need to use ADSI Edit to remove it from the list of DHCP roots.
(Edit 2010-03-14: Added Graeme's comment about step 0)