fabiohanson.it
  • Projects & Case Studies
  • Solutions Engineering
  • Platform Engineering
  • Security & Identity
  • On-Prem Architecture
  • Operations & Runbooks
  • Continuing Professional Development
  • Interesting Fixes
  • Credentials
@2026 - All Right Reserved.
Category:

Operations & Runbooks

Operations & Runbooks

Naming – FQDN Canonical (Reverse) Convention

by Fabio Hanson 2 months ago
written by Fabio Hanson 2 minutes read

Summary

This variant uses a reverse, dot-delimited ordering to make the most specific identifier appear first, followed by location, provider, environment, and DNS domain. It is optimized for FQDN-based grouping and some DNS browsing patterns, at the cost of slightly worse “human scanning” readability.

Reading List

  • UN/LOCODE Code List by Country

Purpose

Provide an alternative canonical FQDN naming pattern that prioritises service instance identity first, then locality, then provider and environment, while preserving the same underlying data fields.

Scope

In scope

  • Host FQDNs for servers, nodes, and service endpoints that publish DNS records
  • Internal-only DNS zones (e.g., systemdomain.internal)
  • Assets that benefit from “instance-first” sorting/grouping

Out of scope

  • End-user device naming (desktops/laptops)
  • Display names and free-form labels

Statements

General Rules

  • MUST use a single canonical naming pattern for hostnames and DNS records as defined below.
  • MUST use only allowed characters:
    • A-Z, 0-9, and – (Hypen)
    • _ (Underscores) should not be used, and are defined for a different purpose.
  • MUST be unique within its relevant namespace

Canonical FQDN

  • MUST follow
    • [HostProvider] as A
    • [Country] as B
    • [City/Town] as C
    • [Service] as D
    • [Iteration] as 0
    • [Environment] as E
    • [Domain] as F
    • [TLD] as G
  • [Service][Iteration].[City].[Country].[HostProvider].[Environment].[Domain].[tld]
  • D00.CC.BB.AA.EEEE.FFFFFFFF.GGGG

Example:

H01.FNS.DE.HZ.PROD.DOMAIN.INTERNAL

Definitions & Constraints

  • HostProvider MUST be a short, fixed 1-2 char.
  • Country MUST use the UN/LOCODE country code 2 char
  • Town/City MUST use the UN/LOCODE location code, typically 2-3 char
  • Service MUST be a short mnemonic 1-3 char
  • Iteration MUST be a small integer or hex value 0-9, A-F.
  • Environment MUST be one of the approved values
    • LAB
    • DEV
    • TEST
    • STAGE
    • PROD
  • Domain & TLD MUST be one of the owned public/private DNS zones.

Rationale

  • DNS grouping: Names naturally group by instance (H1.) and then by site (.FSN.DE.*) when browsing or filtering.
  • Consistency: Preserves the same semantic fields as the non-reverse convention; only ordering changes.
  • Machine parsing: Dot-separated labels map cleanly to structured fields.

Implementation Guidance

CodeProviderNotes
HZHetznerHosting provider
AZAmazon Web ServicesCloud provider
MSMicrosoft AzureCloud provider
GCGoogle Cloud PlatformCloud provider
OPOn-premInternal / datacentre
CodeService typeNotes
SSQL/DBPresumed SQL-based database engine, but is equally open to Postgres, Mongo, etc.
DDockerDocker Nodes
MGeneric Multi Purpose Member
RRouting/VPN/RRASRouting & Remote Access, VPN, etc.
WWebweb frontends/reverse proxies
CodeEnvironmentNotes
labLabexperiments/sandbox
devDevelopmentactive dev
testTestfunctional/QA testing
stageStagingpre-production
prodProductionlive

Exceptions

Exceptions are allowed, but they must be deliberate and clearly declared.

Compliance & Verification

  • Regex-based checks per naming class
  • FQDN pattern for hosts/services
  • Numeric-only device pattern with range validation

Roles & Responsibilities

  • Owner: Platform/Ops
  • Approvers: Team-Lead
  • Implementers: Engineers creating infrastructure, services, devices

Revision History

VersionDateChange
1.02026-02-18Initial

2 months ago 0 comments
0 FacebookTwitterPinterestEmail
Operations & Runbooks

Naming – Readable Hostname Resource Naming Convention

by Fabio Hanson 2 months ago
written by Fabio Hanson 3 minutes read

Summary

This standard defines how to name infrastructure, services, and end-user devices so they’re easy to identify, search, support, and audit. The goal is predictable names that carry just enough meaning without becoming a novel.

Reading List

  • UN/LOCODE Code List by Country

Purpose

Provide a single, testable naming convention for all digital systems to improve operability, triage, reduce mistakes, and support governance including inventory, audit, compliance.

Scope

In scope

  • Servers (physical/virtual), hypervisors, cloud instances
  • Cluster nodes (Kubernetes/Swarm, database clusters, etc.)
  • Networked services and service endpoints
  • Infrastructure resources that surface names externally (DNS, monitoring, CMDB)
  • End-user devices (desktops/laptops), if they’re managed and inventoried
  • Self hosted services

Out of scope

  • Human display names (e.g., “Finance API”) unless they map to an underlying system ID
  • One-off lab experiments that never leave a sandbox (unless they touch shared DNS/monitoring)
  • Third-party managed SaaS where naming is not under internal control

Environments included

  • lab, demo, dev, test, stage, prod (minimum: prod and non-prod)

Statements

General Rules

  • MUST use a single canonical naming pattern for hostnames and DNS records as defined below.
  • MUST use only allowed characters:
    • A-Z, 0-9, and – (Hypen)
    • _ (Underscores) should not be used, and are defined for a different purpose.
  • MUST keep the left-most hostname label within the 15 character limit for NetBIOS compatability
  • MUST be unique within its relevant namespace

Canonical FQDN

  • MUST follow
    • [HostProvider] as A
    • [SystemDomain] as B
    • [Country] as C
    • [City/Town] as D
    • [Service] as E
    • [Iteration] as 0
    • [Environment] as F
    • [Domain] as G
    • [TLD] as H
  • [HostProvider]-[SystemDomain]-[Country]-[City]-[Service][Iteration].[Environment].[Domain].[tld]
  • AA-BB-CC-DD-E0.FFFF.GGGGGGGGGG.HHHH

Example:

HZ-SD-DE-FSN-H1.PROD.SYSTEMDOMAIN.INTERNAL

Definitions & Constraints

  • HostProvider MUST be a short, fixed 1-2 char.
  • SystemDomain MUST be a short 1-2 char code representing the owning platform
  • Country MUST use the UN/LOCODE country code 2 char
  • Town/City MUST use the UN/LOCODE location code, typically 2-3 char
  • Service MUST be a short mnemonic 1-3 char
  • Iteration MUST be a small integer or hex value 0-9, A-F.
  • Environment MUST be one of the approved values
    • LAB
    • DEV
    • TEST
    • STAGE
    • PROD
  • Domain & TLD MUST be one of the owned public/private DNS zones.

End-user devices

Devices that are just a number, and not prefixed by a A-Z character are only permitted if:

  • They are managed in an inventory systen that clearly defines the type and owner
  • There is no collision with any other namespace
  • The device number is directly associated with a end-user device.
  • 0-499 being desktops
  • 500-999 being laptops

Rationale

  • Operability: Names encode the minimum details needed for on-call and support
  • Auditability: Consistent naming supports inventory, access reviews, incident timelines, and asset lifecycle.
  • Error reduction: Predictable patterns reduce mis-targeting
  • Compatibility: The 15-character host label limit supports legacy Windows/NetBIOS constraints where applicable.
  • Human factors: Hyphens are “a worthy sacrifice” for readability

Implementation Guidance

CodeProviderNotes
HZHetznerHosting provider
AZAmazon Web ServicesCloud provider
MSMicrosoft AzureCloud provider
GCGoogle Cloud PlatformCloud provider
OPOn-premInternal / datacentre
CodeSystem domainNotes
C1Company 1
C2Company 2
C3Company 3
C4Company 4
CodeService typeNotes
SSQL/DBPresumed SQL-based database engine, but is equally open to Postgres, Mongo, etc.
DDockerDocker Nodes
MGeneric Multi Purpose Member
RRouting/VPN/RRASRouting & Remote Access, VPN, etc.
WWebweb frontends/reverse proxies
CodeEnvironmentNotes
labLabexperiments/sandbox
devDevelopmentactive dev
testTestfunctional/QA testing
stageStagingpre-production
prodProductionlive

Exceptions

Exceptions are allowed, but they must be deliberate and clearly declared.

Compliance & Verification

  • Regex-based checks per naming class
  • FQDN pattern for hosts/services
  • Numeric-only device pattern with range validation

Roles & Responsibilities

  • Owner: Platform/Ops
  • Approvers: Team-Lead
  • Implementers: Engineers creating infrastructure, services, devices

Revision History

VersionDateChange
1.02026-02-18Initial

2 months ago 0 comments
0 FacebookTwitterPinterestEmail

Popular Posts

  • 1

    Naming – Readable Hostname Resource Naming Convention

    2 months ago
  • 2

    Naming – FQDN Canonical (Reverse) Convention

    2 months ago
  • No tags

Recent Posts

  • Naming – FQDN Canonical (Reverse) Convention

    2 months ago
  • Naming – Readable Hostname Resource Naming Convention

    2 months ago

Featured Posts

  • Naming – FQDN Canonical (Reverse) Convention

    2 months ago
  • Naming – Readable Hostname Resource Naming Convention

    2 months ago

Guides & Tips

  • Naming – FQDN Canonical (Reverse) Convention

    2 months ago
  • Naming – Readable Hostname Resource Naming Convention

    2 months ago
  • Linkedin
  • Email
Footer Logo

@2026 - All Right Reserved.