Sam Pointer

1983 was a pretty amazing year. Lotus 1-2-3 was released, the IBM PC XT was released, Pioneer 10 becomes the first man-made object to leave the solar system. We get a woman and a black man in space, there is nuclear panic, the first NES is released, Brinks Mat, the IRA and Maggie Thatcher. Also, DNS was invented. If you want the history, here is a link to the Wikipedia article. With it, DNS brought us the great naming conundrum.

As a Systems Administrator (or a variant thereof, whatever the title), I have strong views on DNS naming conventions in your average corporate network. I’ve seen some obtuse and downright sadistic host and DNS naming convention abuses; I want to avoid more of the same. So, below, is my take on the definitive guide to your average internal namespace. Feel free to comment.

Use full words: don’t omit vowels or use cryptic two letter abreviations

‘dc’, ‘prn01’, ‘ps1-LON’. Wrong, wrong, wrong. Just learn to type and use full words. And what is this obsession with omitting only vowels? I mean: ‘exchngsvr’. Is it really worth it? Does it roll off of the fingers that much more easily? Really? It makes things much more obvious to you and non-technical people alike if you just use full words in logical domains. What would you both as an admin and a user prefer?

    app14.svr.internal.corp.com

or

    sales.servers.internal.corp.com

A logically configured name that can be read almost as a sentence can’t be a bad thing. To the business it makes the whole thing seem less like a Heath Robinson cranky geek outfit and a modern proper infrastructure.

Properly Configure and Use the Domain Search List

Make sure your domain search list is properly ordered and contains everything sensible for your outfit. Not only does it simplify configuration to single, obvious (full!) words, it comes into it’s own if you ship Virtual Machines between locations, copy configuration information to backup sites, or otherwise sychronize configuration between differently named domains.

Let’s say you ship a VM to a DR and production location. Each is handed out DNS information via DHCP and they have their domain search lists set to dr.corp.com and production.corp.com respectively. All of your scattered, site-specific configuration goes away. Want to talk to an SMTP server? Call it ‘mailhost’ in your configuration and at the DR site the DNS search list will cause a lookup for mailhost.dr.corp.com - likewise for the production location.

Not forgetting the users, having a domain search list that enables them to refer to hosts as ‘sales’, ‘fileserver’, ‘sage’ without full qualification makes everybody’s life easier.

The Cricket Book

Read it. It is getting slightly out-of-date, but the fundamentals still apply. Not optional.

Be Careful of Split Horizon Namespaces

… or revealing a different view of the world to your internal machines. Better that www.corp.com resolves to the same address no matter where you’re coming from and you handle the traffic from one point of ingress only. When the box moves in a year, or something else changes you’ll have an outage. A subdomain of your real (or /a/ real) domain is preferable to an unqualified ‘.corpnet’ internal domain, or a dummy domain in another TLD unresolvable externally. You have a proper chain of DNS delegation making any future delegation and rearrangement of your DNS configuration exponentially more trouble-free.

Get ready for DNSSEC, Test Your Resolver

DNSSEC is coming. When is open to debate, but it pays to keep on top of things. The DNS-ORAC have kindly created a test to determine if your resolver chain can or cannot receive large responses, a problem with additional traffic required for a DNSSEC lookup. Run it and do something about any problems.

Don’t neglect it

DNS is critical to any modern network, be it the Internet as a whole, or your little part of it. A bit of thought and a bit of discipline will make for a better infrastructure for you and your clients.