This is an english version of this (german) article I wrote a week ago: https://www.leahoswald.de/namensschemata-fuer-systeme-und-das-dns/

There are some well and often emotionally discussed topics in IT, like which is the best Linux distribution or the best editor. But there are also some really serious questions like how to best name a server or another device.

The last few years I’ve given much thought to the question what a good and practical solution would need. I now hope to attain my goal and also hope to help other people by presenting my solution.

The number of infrastructure I maintain privately, for my job and our local community network project isn’t getting smaller, therefor it was important to find a unified naming scheme for devices, interfaces and the rDNS to maintain a general view and to allow a fast and targeted debugging in case of problems.

A good first step to find such a solution is to look how other big infrastructure providers are used to name there devices. Maybe they use a well known scheme. Well, there is no such scheme. But there are guidelines from some big network suppliers like Cisco and Juniper how to name interfaces internally and therefor often in the DNS to. Most networks I’ve seen are using the juniper notation. But there are also a few good papers analyzing the meaning of identifiers used by big ISPs.

The naming scheme should allow me to look at the name or the rDNS with traceroute or mtr and get all the information I need to know to start further debugging. If you want to insist because of security concerns for example because of leaking the information where a firewall is in your network path I have to say that I don’t think that security by obscurity is a good security practice and the gain in easy debugging is much more important.

But enough of the background. First we have to distinguish between naming a device and where you can see and set a name.

Usually there are three places where you can set the name of a device, an interface or an IP address. The first place is the name of a system itself and must be configured in multiple differing ways depending on the system. This name is very important to support you checking if you run your commands on the right system. This is something admins are regularly failing at like here at Gitlab. The best choice is to chose a name you could easily remember. If this is a name referring to the function like db01 or a name like magrathea isn’t that important and should depend on your use case. Generally you should take care that a name you chose once isn’t used again or at different locations at once. After the life cycle of such a device the name is “burned”. I prefer to use function names for network hardware and other single purpose hardware. For multi purpose hardware I use names like magrathea.

The interesting part starts when we look how we could configure this on the DNS. This is the part to which I’ve invested a lot of time and thoughts to find a really good solution. But before starting with the naming scheme I want to do a short trip to how DNS works in both directions. DNS could be used to resolve IP addresses and names in both directions. So you could translate a name like example.com to an IP-address like 2001:DB8::42 or a vice versa. The two directions don’t have to resolve to the same name and address but you should have a record that is resolving forward to the same name you’ve configured in rDNS to prevent problems if you want to send mails.

A short example could look like this if you try to resolve the domain of this blog with the tool dig:

For forward resolving of the domain www.leahoswald.de you would get this output (shortened):

;; ANSWER SECTION:
www.leahoswald.de.	900	IN	CNAME	leahoswald.de.
leahoswald.de.		900	IN	AAAA	2a01:4f8:10a:f226::20


This output tells you that www.leahoswald.de is a CNAME of leahoswald.de. A CNAME is similar to an alias. The second line is a AAAA record which refers to the IPv6 address 2a01:4f8:10a:f226::20. This concept of CNAMEs could be used later to get shorter names for lazy humans.

If you want to reverse this process doing a reverse lookup for an IP address you could use dig with the parameter -x. Such a request for the address above will give you the following shortened output. With this the circuit of forward to reverse to forward resolving is closed.

;; ANSWER SECTION:
0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.2.2.f.a.0.1.0.8.f.4.0.1.0.a.2.ip6.arpa. 7200 IN PTR leahoswald.de.


Now let’s start with the naming scheme. The naming scheme is divided into multiple parts to map multiple use cases. The following scheme explains the full notation for example how to use in rDNS.

<iface-type>-<iface-name>-v<vlan id>.<device type><counter>.<name>.r<rack number>.<datacenter>.<un/locode city><un/locode country>.examle.com


The scheme is structured in the following way. The first block from the left describes the interfaces. This is especially interesting if you have a device with multiple interfaces and addresses. The first part of this block is a short term to describe the interface type (for examples see “Interface type shortcuts” below). The next part separated by a dash is the interface name like it is configured on your device. The last part is also separated by a dash followed by a small v describing the native VLAN-ID of an interface.

The next block is a shortcut to define the type of hardware we try to name. A list with some shortcuts for different hardware types could be found further below. Because you could have multiple such devices there is an incrementing counter prefixed by a reasonable number of zeroes. The zeroes are useful if you want to sort the names with some shitty tools or to prevent misreads. Most times two or tree digits will be enough.

After that there comes the name of the system if suche a name was chosen and if it differs from the hardware type descriptor. The next block starts with a small ‘r’ followed by the rack number. Next a short handle to name the datacenter, for example something like rz10 if you host at Hetzner or fra5 if you host at Interxion.

The last to parts before the Domain name are the city and country encoded by the UN/LOCODE.

An example of the naming scheme described could look like this: wg-dn42-grmml-v42.cr01.magrathea.r02.rz22.fks.de.leah.is

This is the longest version and is best used for rDNS because of the amount information that is encoded in the name. But to be realistic you need some additional version like for devices that are not within a rack or without different interfaces or maybe you just think the version above is to long for you.

So here is a shorter version:

<name>.<datacenter>.<un/locode city><un/locode country>.example.com


The meaning of the parts ist the same as above but we’ve removed some parts. So <name> means a hardware type plus counter or any other name you want to use for the device. This version is for example useful for virtualization hosts like the physical hardware the vm with this blog is running on: vm03.rz10.fks.de.leah.is

The last version is for the lazy people without a shortcut in there SSH config.

This version is as short as <name>.example.com BUT this should always be a CNAME to one of the other two examples. But as everywhere there are some exceptions from this rule. I use this short version also for my laptop and other personal computers without a fixed location. But in the end everything is only an advice not something that couldn’t be customized.

And there is another exception for rDNS of IP addresses which match a sigle website. Here you should name it for the website not the machine the website is running on.

I hope I could give you a good insight on how I name my devices and maybe you now don’t need to think to hard for your own scheme.

If you have feedback, for example on how you solve this challenge I would like to hear your opinion for example via mastodon https://chaos.social/@leah or via twitter.

###### Interface type shortcuts
• fe = fast ethernet
• ge = gigabit ethernet
• te/xe = ten gigabit ethernet
• tu = tunnel interface
• lo = loopback device
• et = 100 GBE
• gre = gre device
• ipip = ipip interface
• wg = wireguard device
###### Hardware type shortcuts
• cr = core router
• cs = core switch
• gw = customer gateway
• asw = aggregation switch
• sw = access switch
• ap = wireless access point (handles clients)
• swp = access switch with PoE
• pdu = power distribution unit
• fw = firewall
• nas = network attached storage (the small box)
• san = storage attached network (the big loud box)
• srv = simple server (e.g. web server)
• vm = vm host (system hosting virtual machines)
###### Geolocation with the UN/LOCODE

There are a lot of possible ways to represent a geolation in a short string. In many cases the so called IATA-Codes are used. These codes are used to describe airports and other parts of aviation infrastructure. Unfortunately these codes are way less precise than necessary for many places, especially when it comes to local hardware like the hardware from our community network project.

A solution we could better use are the five character long codes of the UNECE, the so called UN/LOCODE. This is a list with codes for nearly every place big enough to locate your hardware :) The first two characters describe the country the last three the location. So Frankfurt is DE FRA, Hamburg is DE HAM, New York City is US NYC and Reykjaví is IS REY. The list with the codes could be found here: http://www.unece.org/cefact/locode/service/location

###### Example listing

This is a list of addresses found by doing many traceroutes to big networks all over the world to get an overview on how other providers name there infrastructure. The names I liked or which were inspiring for my naming scheme are marked bold.

• 100ge6-1.core1.lon2.he.net
• omh-edge-11.inet.qwest.net
• xe-1-1-0.r1.bb-fo.ams1.vrsn.net
• cgcil21crs.ipv6.att.net
• decix.bb-c.act.fra.de.oneandone.net
• syn-ex.10g.cr1.r2.ac.de.fiberway.eu
• be2270.ccr22.muc03.atlas.cogentco.com
• juniper4.rz2.hetzner.de
• juniper4.pop2.fra.hetzner.com
• lo-0-1-v6.edge3.Dusseldorf1.Level3.net
• te7-2.c101.f.de.plusline.net
• fra16s18-in-f131.1e100.net
• ae-5.r24.londen12.uk.bb.gin.ntt.net
• ae-7-2003.r02.tokyjp05.jp.ce.gin.ntt.net
• be2960.ccr42.fra03.atlas.cogentco.com
• de-fra04a-rc1-ae60-0.aorta.net
• ae6.cs1.lhr11.uk.eth.zayo.com
• m-eb7-i.M.DE.NET.DTAG.DE
• core1.man.da.as6766.net
• te-0-0-1-0.core1.fra1.ix.f.man-da.net
• core1.man.da.as6766.net
• if-ae-6-2.thar1.F2C-Frankfurt.as6453.net
• asd2-rou-1043.NL.eurorings.net
• nmint-nlams1-010-vl11.connectivity-services.nl
• nl-asd-dc2-ice-ir01.kpn.net
• be-29.crrt01.den03.viawest.net
• vip-redirect-orange.s0.fti.net
• et-3-0-1-0.pastr3.parispastourelle.opentransit.net
• be2960.ccr42.fra03.atlas.cogentco.com
• fw-bae00-v183.alpha.net.b1.fti.net
• rt-esite02-cc.bae.net.b3.fti.net
• akamai-row.franco71.fra.seabone.net
• pc-b.bitgravity.com
• ix-ae-27-0.tcore1.FR0-Frankfurt.as6453.net
• if-ae-2-2.tcore1.FNM-Frankfurt.as6453.net
• Xe5-3-0-0-grtamstc1.ri.telefonica-data.net