DNS Naming Unconventions


Earlier today on Twitter, Tom Hollingsworth (@networkingnerd) raised the subject of naming conventions. He’s right that having something in the device name that clues you in to where it’s located is really helpful when you’re troubleshooting.

But wait, that’s a form of information disclosure, and some evil h4x0r could use that, plus any other devices they find, to map out your network. So is this good or bad?

Geographical Naming

It all depends how paranoid you are. As Tom observed, does knowing that a server is in Florida somehow make it more vulnerable? No, of course not – you will likely try to compromise a server the same way regardless of where it’s located. On the other hand, if you know that the company’s main data center is in Florida, perhaps that knowledge makes it a more desirable target, and helps an attacker focus their efforts and gain access to core infrastructure more quickly.

Service Naming

How about if your servers also identify what they do? If you know which are database servers, which are web servers, and which are DNS servers, say, does that also give an attacker information that helps them find their way around your infrastructure? Perhaps hacking a DNS server will reveal zone files that allow a hack to enumerate your entire infrastructure? Or maybe it won’t.

Themed Naming

So if we don’t want to use geographical or service naming, what do you do? The classic starting point for many smaller companies has servers using cute names; for example perhaps all the servers are named after Disney characters, Star Trek characters or maybe planets and stars. This is sweet while you have relatively few servers, but frequently scales badly (it’s easy to run out of names). For a new employee, learning that Mickey is the AD Domain Controller while Minnie is the web server can take some time and may slow them down until they’re familiar with the environment. But as there are more and more servers brought up, remembering which servers do what gets even harder.

I’ve seen a hybrid naming scheme used before, where all the web servers were Disney characters, all the AD servers were named after characters from the HitchHikers’ Guide To The Galaxy, and so forth. That worked up to a point, but when I spoke to people it was clear that they had to take an extra second or two to hear the server name, figure out which type of name it was, then translate that to its position in the architecture.

Abstract Naming

The most interesting naming scheme I’ve come across – in a couple of places now – involves using random names for all servers; typically dictionary words assigned with no apparent sequence. It’s a little like giving every server a name based on a random number generator, only instead of a sequence of digits, the names are at least pronounceable and thus a little bit more memorable. Unsurprisingly, in each place I’ve seen this, the policy has come as a directive from the Security team. I can’t honestly imagine trying to troubleshoot a network where the AD Domain Controllers are named BILLY, STARBASE, ALSATION, BANANA and ELEPHANT, while the web servers are TIGER, ELEMENT, BIZARRE, POSSE, DINNER and GELATINE. How on earth do you remember those?

Help Me Out

I am really curious to hear from you all what the best naming convention is. Personally I think the abstract naming is just counter-productive, but I’d love to hear from a security professional as to why that might be a really great idea. Could you live in an environment with abstract naming?


7 Comments on DNS Naming Unconventions

  1. Not a naming scheme per se, but I do remember an incident at one client site a long time ago… We had just taken delivery of two big-ass IBM floor-standing PC servers. Unboxing them, plugging them in, the first one was obviously having some problem with the VGA output – the picture was very pink, so the server was named PINKY. The second one therefore had to be named PERKY. (I said it was a long time ago…)

  2. Nothing’s worse than combining function-based server naming with repurposing servers:

    Wait, why is the FTP server named Oracle_1? …Oh, it *used* to be a database server, but then we bought Oracle_2, but a 3rd party was pushing file transfers to Oracle_1’s address, so we had to keep it around…

    So, I’m against functional names for that reason. It’s less of an issue these days, because hypervisors mean more folks spin up VMs per purpose. If a (virtual) server only does one job until it’s decommissioned, then function creep isn’t an issue.

    …Having said that, renaming servers to follow function creep can also be bad, because it complicates tracking hardware over it’s lifetime. If the “mickey” server had a bad disk controller once, and it continues to be called “mickey” for as long as we own it, it’s more likely that the controller problem will be remembered, paper trails maintained, etc…

    • There’s some good logic there, Chris (not a surprise). I’ve had similar discussions before about switch naming – e.g. a 6500 switch. Let’s call it DistSW01. Ah, but it’s layer 3? So let’s call it DistRT01. I just added an ACE blade. Should it now be DistLB01? What about a FWSM? DistFW01? It just gets silly after a while. Call it a switch. I did find some value in knowing which switches were at the aggregation, access or core layer for example, but beyond that it can be difficult to maintain any level of naming for purpose.

      It’s worse for servers, as you say, because their purpose can change drastically over time. Very good point. Now, if you were to combine an identifier with a purpose, it might be persistent – e.g. S00176_WEB could be changed to S00176_DB if you wanted, and it’s still server 00176. Might still be tricky to manage mind you, but might solve one problem anyway.

      Great thoughts, thank you!

      • distsw01 vs. distrt01 vs. distlb01…


        I’ve long been mystified by folks who insisted on making that distinction when the devices in question have all of those capabilities.

  3. At my previous job our server naming scheme was roughly: [two letter site code]-[function][optional incremental number starting at 1]. The only thing that we were consistent on was the site code.

    Most of our server names gave a general idea of its purpose, but to a new employee they would appear extremely vague.

    Having all of this information documented (and up to date) is also very important! We kept details on all of our servers in a wiki. Each server had an individual page that listed, at the least, its name, IP address, whether it’s physical or virtual, and if applicable, serial number, asset tag, and rack location.

    Our switches, APs, UPSes, PDUs, and other network equipment followed a naming convention of:
    [two letter site code]-[room number]-[device type][##]
    e.g. XX-D400-AP03, XX-K201-UPS01, XX-J134-CS01 (access point, UPS, core switch, respectively).

Leave a Reply

Your email address will not be published.