2009-02-27

Does Anyone Remember How Powerful DNS Can Be?

I'm not talking about the handful of sysadmin gurus. I mean everyone else from developers to the rest of system and application administrators.
You don't need to name a machine after what it does. You can. But you don't have to. And chances are good that if you own that machine for several years, it will become many more things.

Use a DNS CNAME.

What the fudge is a CNAME?

It's a name that points to another name to get an IP address resolution. Think of the phonebook. You look up "Euripidies Flintstones" to find a phone number. "Euripidies Flintstones" would be considered a DNS A record, or a mapping of a name to an IP address.

Now imagine we had a more sophisticated phonebook that knew Euripidies usually went by the less formal first name "Phil." Looking up "Phil Flintstones" would refer you to "Euripidies Flintstones." In this case, "Phil" is the CNAME.

You have a non-production machine that hosts your dev, qa and uat environments for a web application. The box (we'll call the box "bob" for the sake of argument) is older but perfectly serviceable. And you really don't want to rename it for a number of reasons. And that means you already have a DNS A record for bob.domainname. The box name is unimportant. Name it whatever you want. But if you have to access a major resource on the box, create a CNAME for it.

You could put all your environments on different ports. Heck, you could do what most thoughtless folks do and just address it by IP (oooo, now that's not prone to creating extra work down the road!). Or, you could be one of the 1-percent who take this advice.

bob.domainname's cnames:
devweb.domainname -> points to bob.domainname
qaweb.domainname -> points to bob.domainname
uatweb.domainname -> points to bob.domainname

Web apps are really easy for this. With the magic of IP-less hosting, asking the web server to talk to "devweb" will send you to the right web service.

Take a production example. You have a file server already named "myfiles.domainname." You're just big enough that you plan to add separate database and mail servers. But you'll colocate them on the file server to get started.

myfiles.domainname's cnames:
sql-01.domainname -> points to myfiles.domainname
mail-01.domainname -> points to myfiles.domainname

Why bother? Well, you've already configured numerous clients to talk to myfiles for file shares. When you install your mail server, you're going to have to direct them to something. One day, when you create a dedicated mail server, you have to go touch every client to change from "myfiles" to "mail-01." Or you could just edit the CNAME for mail-01 to point to your new mail server when you finally install it.

The database server can be an even bigger deal. You'll probably write tens (or hundreds) of small and large programs that access the database server. If you leave it as "myfiles," all those applications will need to be changed when you install your dedicted database server. Or, you could use a CNAME and repoint it later with a lot less fuss.

You don't need them for every server and every minor case. But they are an immensely useful tool in your sysadmin arsenal.

CNAMEs, folks. It's the wave of the future, only it was envisioned in the early 80s and ignored by scores of IT professionals.

By the way, here's a useful external link with a simple CNAME explanation: http://rscott.org/dns/cname.html

(One caveat... some Windows services rely on more than a DNS name. They expect to find a WINS name as well. While you can create custom WINS entries, and they're usually successful, Windows file services are notoriously picky about the actual system name... thanks Microsoft!)

No comments: