Namensschemata für Systeme und das DNS

Es gibt manche Themen in der IT, die schon immer Teil kontroverser und emotionaler Diskussionen waren. Bekannte Beispiele sind Diskussionen darüber, welche Linux-Distribution oder welcher Editor am Besten ist. Aber auch, und das ist eine wirklich komplizierte Frage, wie ich einen Server oder andere Geräte am Besten benennen soll.

In den letzten Jahren habe ich mir über diese Frage wirklich viele Gedanken gemacht und versucht eine gute und in der Praxis nützliche Lösung zu finden. Ich hoffe jetzt langsam an meinem Ziel angekommen zu sein und möchte meine Antwort auf diese Frage hier auch anderen Suchenden vorstellen.

Der Umfang der von mir privat, beruflich, aber auch für Freifunk Rhein-Neckar betreuten Infrastruktur wird nicht weniger, da ist es umso wichtiger ein einheitliches Schema dafür zu finden, wie Geräte, Interfaces und das rDNS zu benennen sind, sowohl um den Überblick zu behalten, als auch um bei Problemen schnell und zielgerichtet reagieren zu können.

Um sich der Frage nach einem guten Schema zu nähern, empfiehlt es sich immer mal bei "den Anderen" zu gucken, wie die das machen. Vielleicht gibt es ja ein einheitliches Schema, dass alle großen Betreiber nutzen?
Gibt es nicht, aber es gibt zum Beispiel von großen Anbietern wie Cisco und Juniper zumindest Vorschläge wie Interfaces intern und daher auch im DNS genannt werden können. Am häufigsten habe ich dabei die Bezeichner von Juniper gesehen, dazu aber später mehr. Es gibt auch einige gute Paper, die die Bedeutung der von großen ISPs genutzten Bezeichner analysieren.

Für mein Namensschema ist es mir wichtig, dass bereits aus dem Namen bzw. rDNS ersichtlich wird, womit genau ich es zu tun habe. So enthält schon ein mtr oder traceroute einige Informationen, die wichtig sind, um das Problem einzugrenzen. Falls ihr euch jetzt denkt "Das ist doch ein Security Problem zu verraten, welches Geräte z.B. eine Firewall ist", muss ich sagen, das ist für mich kein Thema, Security by obscurity hilft bekanntermaßen nur sehr bedingt und der Zugewinn an Wartbarkeit und einfachem Debugging ist hier entscheidend.

So, nun aber genug der Vorgeschichte. Zuerst einmal müssen wir unterscheiden, wie ich mit der Benennung des Systems umgehen kann und wo welche Namen auftauchen und wie diese gesetzt werden können.

Meistens gibt es drei Orte, an denen der Name eines Systems, Interfaces oder einer IP-Adresse gesetzt wird. Der Erste ist der Name eines Systems selbst und wird von System zu System unterschiedlich eingerichtet. Meist taucht er jedoch zum Beispiel in der Konsole wieder auf und hilft dort zu erkennen, ob ich auf dem richtigen System arbeite. Das geht manchmal ja leider schief, wie hier bei Gitlab. Hier eignet sich daher ein griffiger Name, ob das jetzt eine Funktionsbezeichnung wie db01 ist oder ein Name wie varuna ist erst mal egal.
Grundsätzlich empfiehlt es sich jedoch Namen nicht wiederholt oder an unterschiedlichen Standorten einzusetzen, um Irritationen z.B. nach einem Umzug oder im Betrieb zu vermeiden. Sprich, wenn ein solches System ausgemustert wird, gilt der Name auch als "verbrannt".
Ich nutze meist die Funktionsbezeichner für Netzwerk Systeme und die Namen-Variante für Server oder Ähnliches bei denen häufig kein eindeutiger Funktionsbezeichner möglich ist.

Spannender wird es, wenn wir jetzt gucken, wie wir das Ganze im DNS abbilden können und hier habe ich mir wirklich lange Gedanken gemacht, wie ich das ganze am hübschesten bauen könnte. Dazu aber erst kurz einen Abstecher in die beiden Richtungen von DNS. Das DNS kann sowohl dazu genutzt werden Namen wie example.com in eine IP-Adresse wie 2001:DB8::42 aufzulösen, aber auch, um 2001:DB8::42 wieder in einen Namen umzuwandeln. Das muss dabei nicht unbedingt der gleiche sein, wichtig ist nur, besonders bei Systemen die Mails versenden, das der Name, zu dem eine IP auflöst, auch vorwärts, also Name nach IP, auflösbar ist.

Kurz noch mal am Beispiel dieser Seite erklärt. Wenn ihr die IP zu dieser Seite wissen möchtet, könnt ihr diese mit dem Tool dig erfragen:

Für eine vorwärts Auflösung von www.leahoswald.de bekommt ihr eine Ausgabe wie dieser hier (gekürzt):

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

Diese Ausgabe sagt euch, dass www.leahoswald.de ein CNAME, also eine Art Alias auf leahoswald.de ist, das zur IP Adresse 2a01:4f8:10a:f226::20 auflöst. Dieses Konstrukt mit CNAMEs wird gleich noch mal wichtiger.

Wenn ich die erhaltene IP Adresse jetzt wieder in einen Namen auflösen möchte, kann ich dies auch mit dem Tool dig und dem Parameter -x erreichen. Dort erhalte ich dann die folgende (gekürzte) Ausgabe. Somit ist der Kreis quasi wieder geschlossen.


;; 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.

So, jetzt zu meinem Schema. Dieses besteht aus mehreren Teilen, um verschiedene Nutzungsszenarien abzubilden. Folgendes Schema stellt die vollständige Schreibweise dar, wie sie zum Beispiel für das rDNS genutzt werden sollte.

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

Dabei ist das Schema wie folgt aufgebaut. Im ersten Block beschreiben wir das Interface, das ist insbesondere dann interessant, wenn wir über Netzwerkgeräte wie Router, mit mehren Interfaces und IP Adressen, sprechen. Dabei besteht dieser Block aus einem Kürzel für den Interface-Namen ( siehe "Abkürzungen für Interface Typen" weiter unten) getrennt durch einen Bindestrich vom Interface Namen auf dem Gerät selbst und der durch einen weiteren Bindestrich und ein kleines v eingeleiteten VLAN-ID, sofern es sich um ein VLAN-Interface handelt.

Der darauffolgende Block beschreibt den Hardware-Typ. Auch hier findet sich weiter unten eine Liste mit möglichen Abkürzungen. Da es von einem Hardware-Typ N Stück geben kann, nutzen wir hier einen über alle Locations inkrementierenden Counter. Dieser wird mit führenden Nullen genutzt, um Namen einheitlicher länge zu erreichen und Verwirrung durch überlesene Zahlen zu vermeiden. In der Regel empfehlen sich zwei oder drei Inkrement Stellen, außer es ist eine größere Installation absehbar.

Anschließend folgt der Name des Systems, sofern einer vergeben wurde. Der nächste Block beginnt mit einem klein r und erhält danach einen Counter für das Rack. Dann ein Bezeichner für das Datacenter in der Stadt, die als Nächstes kommt. Dabei empfiehlt sich zum Beispiel bei Hetzner einfach die Abkürzung für das RZ wie rz10.

Den Abschluss vor der Domain machen Stadt und Land abgekürzt durch den UN/LOCODE, der ebenfalls weiter unten beschrieben wird.

Als Beispiel könnte das ganze wie folgt aussehen:
wg-dn42-grmml-v42.cr01.varuna.r02.rz22.fks.de.leah.is

Das ist die lange Maximalfassung, diese eignet sich wegen der umfangreichen Informationen insbesondere für das rDNS. So schön die Theorie, ich höre aber schon Stimmen sagen, dass Interfaces und Racks nicht immer Sinn machen und das eh alles zu lang ist.

Der Praxis wegen, gibt es daher noch eine verkürzte Schreibweise.

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

Das Schema ist das Gleiche wie oben, nur das hier bei Name bzw. Hardware-Typ+Counter, der hier ebenfalls mit "name" abgekürzt ist der Bezeichner aufhört. Dies Abwandlung nutze ich besonders gerne für VM Hosts, wie zum Beispiel das physikalische System auf dem die VM mit diesem Blog läuft: vm03.rz10.fks.de.leah.is

Als Letztes gibt es noch die Variante die zum Tippen praktisch ist, wenn es nicht eh nochmal Kurzformen in der SSH Config gibt ;)

Diese sieht dann einfach wie folgt aus <name>.example.com, ist jedoch nur ein CNAME auf eine der vorherigen Varianten. Ausnahme sind bei mir ein paar wenige Systeme wie meine privaten Maschinen bei denen weder eine Geo noch eine RZ Angabe Sinn macht. Allgemein gilt auch, was nicht passt, darf durchaus weggelassen werden.

Außerdem gibt es eine Ausnahme für IP Adressen hinter denen einzelne Websites oder ähnliches stehen, diese sollten, wie im Beispiel oben, direkt auf diesen Namen im rDNS auflösen.

Ich hoffe, ich konnte euch einen guten Einblick in mein Namenschema geben und hoffe vielleicht damit das Grübeln an der ein oder anderen Stelle verringern zu können.

Über Feedback wie ihr das löst, zum Beispiel via Mastodon https://chaos.social/@leah, würde ich mich freuen.


Abkürzungen für Interface Typen
  • fe = fast ethernet
  • ge = gigabit ethernet
  • te/xe = ten gigabit ethernet
  • tu = tunnel interface
  • ae/lag = aggregated link
  • lo = loopback device
  • et = 100 GBE
  • gre = gre device
  • ipip = ipip interface
  • wg = wireguard device
  • rl = directed radio link
Abkürzungen für den Hardware Typ
  • 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)
  • re = radio equipment
  • srv = simple server (e.g. web server)
  • vm = vm host (system hosting virtual machines)
Standorte mit dem UN/LOCODE beschreiben

Es gibt viele verschieden Arten eine Geo-Information in einem kurzen String zu codieren. In vielen Fällen werden dazu die sogenannten IATA-Codes genutzt, mit denen Flughäfen und andere Bereiche aus der Luftfahrt abgekürzt werden. Leider sind die Abkürzungen in vielen Fällen zu ungenaue, insbesondere wenn lokale Hardware, wie zum Beispiel bei Freifunk beschrieben werden soll.

Als Lösung für dieses Problem bieten sich die fünf Zeichen umfassenden Codes des UNECE, der sogenannte UN/LOCODE an. Diese existieren für fast jeden Ort der groß genug ist, um dort Geräte stehen zu haben :) Dabei beschreiben die ersten beiden Zeichen das Land und die übrigen drei den Ort. Aus Frankfurt wird so DE FRA, aus Hamburg DE HAM, aus Hamburg-Mitte DE HTJ und aus Reykjavík wird IS REY. Die Listen mit den Codes findet ihr hier: http://www.unece.org/cefact/locode/service/location

Beispiel Listing

Hier findet sich noch eine Liste die aus einer größeren Sammlung an Traceroutes zwischen großen Netzen entstanden ist, um einen Überblick zu erhalten, wie Andere das Problem der Benennung lösen. Die Namen aus der Liste, die ich ganz gut finde, oder die mich inspiriert haben, habe ich mal fett markiert.