The DNS naming scheme I use for infrastructure was designed to:
- Describe “what”, in “what state”, and “where”; and
- Be easily queryable and groupable in the inventory management system; and
- Be translatable to reverse domain name notation (ex.
com.exmaple.infra...), again, for queries and when documenting things - for example, to use as a wiki structure.
- Document things. Especially clusters and generations within the same service root.
- Document relationships between different services, generations, and clusters.
- Isolate your DNS. Infrastructure DNS should not be queryable from unauthorized devices (zero trust - remember?).
- Don’t include business purpose - DNS should be used as a street address. It is
Duke's at 1596 2nd Ave, New Yorknot
I will have a beer and some wings at Duke's, at 1596 2nd Ave, New York. It’s just superfluous and useless.
- Don’t reuse identifiers after obsoleting them. Have a new one. There are plenty to go around. Immutable infrastructure is more of a replacing thing with the same thing in a different state, so reuse is permissible there.
- DO NOT register these DNS entries in a public DNS server (provided by your registrar, Cloudflare, and who knows what else).
Components of infrastructure asset FQDN
<edge> - Identifier conforming to
e[1-9][0-9]*. A network “edge” - server, virtual machine, router, anything really.
You should not use different prefixes for edge nodes (for example, to identify the purpose of the node). Node identifiers should be meaningless - but documented.
Old identifiers of discarded infra should not be reused with a single exception of replacing infra on purpose, with immutable infrastructure deployment being a good example, replacing identical hardware being another.
<cluster> - Cluster identifier conforming to
c[1-9][0-9]*. Identifies a group of nodes somehow linked to one another to deliver the same service within the same generation. Independent nodes which will (supposedly) never be part of a cluster should never be grouped under a single cluster of nodes. For example, 3 independent MySQL servers should be
<gen> - Deployment generation conforming to
g[1-9][0-9]*. Bump the generation every time you destructively migrate a thing to another state. E.g. spin up a new version of something, migrate everything there and discard the old hosts. This is unlikely to happen often. Also used when the same service is deployed twice with different versions concurrently. For example, PostgreSQL 9 and 11 (for some reason). You should not use generation numbers to reflect version numbers and version increments of the service group.
<sgroup> - service group conforming to
[a-z-]+. The service group is used to describe what service the node provides. For nodes with more than one service, come up with your short-name and document that. For example,
Java + MySQL. For single service nodes, use the name of the service. Do not use pointless and generic names like
vpn, etc. The only thing where such naming is permissible is for purpose-specific hardware, like
ups for UPS,
hwfw for hardware firewall, etc, but even then, better to use vendor name or some such, ex.
mcrs (MikroTik CRS).
<loc> - Physical location / region / data center -
[a-z-]+. Should use the name of an availability zone, or region, or data center used by the vendor. Several components should be separated by a dash
(-) if the vendor provides several location tags (for example,
r3-dc2-de for Rack 3, DC 2 in Germany). Invent your own for local assets. City short-name + N is a good start, for example,
nyc1 for New York office 1.
<vendor> - Provider / vendor / co-locator -
[a-z-]+. Examples include
azure, and so forth. Use
local for assets directly owned and controlled by the organization, e.x. office hardware. This is NOT to be used to identify the manufacturer of hardware and such.
<root> - a root domain. For infrastructure used organization-wide
infra.example.com is a good choice. Multiple customers? Use a customer-specific second-level domain (
infra.customer.com) or customer-specific third-level domain (
infra.customer.example.com). Standalone project? Use a project-specific second-level domain (
infra.project.com) or project-specific third-level domain (
infra.project.example.com). Use for office hardware? Same rules. Infrastructure is infrastructure and business purpose is irrelevant.
Common examples for web infrastructure
Example for your LAN