Domain Names for Non-Techies

One of my non-technical friends, a writer and motivational speaker, bought a new domain name recently, then asked me how to get it pointed to her soon-to-be-rebranded website. The ensuing discussion revealed that she, like most non-techies, knew next to nothing about domain names, other than that “she needed one.”

Since I suspect there are many other people around just like her, I thought it might be a good idea to demystify domain names. So, let’s go on a tour through the wild, wild badlands of the Internet.

A Registrar is a company that has been authorized to register (and accept payments for) domain names.

A Hosting Company provides computers on the Internet that can host web sites. For small sites, which pretty much defines the kinds of sites that writers and motivational speakers have, they’ll usually host multiple web sites on one computer. Sometimes Registrars also function as Hosting Companies to secure additional income, but the two roles are distinct.

Every computer on the Internet has an ugly, non-intuitive address that looks something like this: 123.10.234.56. That’s known as an IP Address. They’re not very easy for people to remember. So some bright people invented Domain Names, which are like relatively easy-to-remember names that can “point” to an IP Address.

Except that it’s not quite that simple. How do you find out what IP Address a Domain Name points to? You could query every computer on the Intenet: “Hey buddy, do you answer to keenertech.com?” But that might take a while.

So somebody really devious came up with the idea of the DNS Name Server, which is basically a computer that 1) holds information about a whole bunch of domain names and where they point to, and 2) can respond with the correct IP Address if you politely ask it about a domain name. But, sometimes computers crash, so most people who run DNS Name Servers also run a backup server just in case the first one fails.

Now we come to the fun part. Your Hosting Company has DNS Name Servers associated with your hosting account. You can usually look up what they are using some via sort of “Dashboard” or “Control Panel” that they provide to their customers. When you find their DNS Name Servers (sometimes they’ll be listed as just “name servers”), record that information.

Next, you need to login to the Registrar, who generally has their own Dashboard or Control Panel, and tell them what DNS Name Servers will be associated with your domain name. By default, they’ll list their own name servers — you want to change the name servers to the ones from your Hosting Company.

Back at your Hosting Company, you need to create a web site, generally something that can be done via their Dashboard. Next, you need to tell them, via the Dashboard, which Domain Name will point to your web site. They’ll make sure their DNS Name Server properly directs Internet users to your web site.

If your Registrar and Hosting Company are the same, then they’ll already have them handled by a DNS Name Server. All you’ll have to do is configure your web site so that the Hosting Company knows what Domain Name you’re using.

Once you set up your Domain Name to point to your web site, you may have to wait a few hours for this to propagate outward so the rest of the Internet knows where to find your web site. You should double-check to make sure that both your Domain Name and your Domain Name preceded by “www” point to your web site.

Awesome! Now you’re using a real Domain Name, and look look so much more professional than all those other folks using derivative and unprofessional addresses like great-speaker.blogspot.com. If you have any problems, check the documentation on your Hosting Company’s web site — setting up Domain Names is a common problem that they deal with all the time. If all else fails, don’t be afraid to send an email to Customer Support — they will help you out.

I hope this tour of IP Addresses, Domain Names, Hosting Companies and Registrars has been useful to some of you.

The Magic Incantation

If you’re a system administrator, please don’t read this article. It contains highly sensitive and technical information of general use only to software engineers. Also, please note that when I say “software engineer,” I mean individuals who actually develop software.

Um, and by “developing software,” I mean individuals who actually write code. So, basically, this article is for the roughly 10% of software engineers and system engineers that actually build things (I’m not actually being snarky; this is the rough percentage that I’m seeing in government contracting).

All right. Good. Now that we’ve got that out of the way, I’d like to talk about government contracting for a moment.

The first thing that happened when I entered government contracting — “they” handed me a paperweight. Well, actually it was a Dell laptop PC, but it had been locked down to the point that software development was impossible. (What was equally disconcerting of course, was that I had hitherto been used to Macs; so not only did I get a PC, but I got laughed at when I mentioned Macs).

And, really, to be honest, it wasn’t the first thing that happened, because it was actually a couple of days before I got the laptop. And, since it was so locked down, it was about three weeks before I could do anything with it. (Not to worry though, I was still billable, so all was well).

It turned out that the standard laptop (in a company that specialized in software development) didn’t come with Local Admin Access. I had to put in an online request for Local Admin Access, justifying why I needed this privilege level to a chain of people that went to, well, let’s just say, rarified heights.

I was turned down. Multiple times. Until, finally, one of my friends, a long-time veteran of the company, looked at the text of my request, and told me that I was doing it all wrong. This helpful wizard crafted a “magic incantation” that saved the day.

Thanks to this magic incantation, I was able to secure the access that I need to actually perform the software duties for which I was being paid. I passed it on to my teammates and they, too, were able to get their jobs done.

Without further ado, here’s the magic incantation:

User is a developer on the <program name> program. This host is his primary development workstation. He requires local admin rights to be able to add entries to the HOSTS file and install virtual machines (with VMware and/or Virtualbox), development tools (IDEs like Eclipse, Visual Studio, Cygwin, Ruby/Rails) and servers (e.g. Tomcat). He needs to be able to apply patches and updates to these things as needed.

The incantation subtly makes two main points to the system admins: 1) the individual really does need this level of access, and 2) you’ll be doing a bunch of work if you don’t give it to them. This is necessary in order for them too approve your request and then pass it on to upper management. To managers, the incantation makes an important third point — hey, this person is going to actually do work.

It’s worked without fail for several years now. I’m distributing this incantation to the technical community as a public service. May it serve you as well as it has served me.