Hostname Naming Standard Checker

Check status

Hostname inventory:

Use one hostname per line; URLs and first-column CSV rows are normalized before checking.

Standard preset:

Choose the rule family that should decide pass/fail before exporting the audit.

Naming regex:

Default expects site-role-service-sequence names such as dc01-rtr-edge-01.

Regex target:

Use host label when FQDNs should still be checked against the asset naming pattern.

Lowercase policy:

Require lowercase for strict naming standards, or warn when auditing a mixed legacy inventory.

Required domain suffix:

Blank keeps suffix checks off; values accept example.internal or .example.internal.

{{ result.fatal ? 'Fix the checker setup' : 'Hostname inventory needs input' }}

{{ message }}

Input	Normalized	Status	DNS syntax	Naming regex	Case	Duplicate	Detail	Copy
No hostnames parsed yet Paste hostnames, URLs, or CSV rows before exporting the audit ledger.
{{ row.input }}	{{ row.normalized }}	{{ row.status }}	{{ row.syntaxStatus }}	{{ row.patternStatus }}	{{ row.caseStatus }}	{{ row.duplicateStatus }}	{{ row.detail }}

Rule	Scope	Status	Affected	Example	Next action	Copy
No rule findings available Parse at least one hostname to build the rule breakdown.
{{ row.rule }}	{{ row.scope }}	{{ row.status }}	{{ row.affected }}	{{ row.example }}	{{ row.action }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Infrastructure names carry more than a label for DNS. They appear in monitoring alerts, certificate requests, configuration management, Kubernetes manifests, asset inventories, shell scripts, and handoff notes between teams. A hostname that looks harmless in one spreadsheet can break later when a platform rejects an underscore, a certificate automation job expects lowercase, or two records collapse to the same name after normalization.

Good hostname standards solve two related problems. First, the name must fit the syntax accepted by the systems that will use it. Second, it should tell people enough about the asset to reduce guesswork without turning the name into a long description. DNS-safe syntax and a local naming convention are not the same thing: web01.example.internal may be syntactically safe, while web01 might still fail a company rule that expects site, role, service, and sequence tokens.

Most operational hostname rules use the letter-digit-hyphen, or LDH, shape. Labels are separated by dots, each label has a length limit, and host labels should not begin or end with a hyphen. DNS comparisons are normally case-insensitive, but mixed case still creates avoidable drift in tools that sort, compare, template, or copy names as text. That is why many teams enforce lowercase even though DNS itself does not treat WEB01 and web01 as different names.

Enterprise host-label shape with DNS suffix

dc01 rtr edge 01 .example.internal

Site

Location, data center, region, or environment marker.

Role

Router, switch, firewall, server, database, app, VPN, or load balancer class.

Service

Human-readable asset purpose that still stays inside the naming pattern.

Sequence and suffix

Unique instance number plus the approved DNS zone when a fully qualified name is required.

A naming standard also needs a clear boundary between host labels and fully qualified domain names. A short asset name such as dc01-app-api-01 is usually the host label. A dotted name such as dc01-app-api-01.example.internal includes the DNS suffix. Some checks should apply only to the first label, while others need the whole dotted hostname. Mixing those scopes is a common reason for false failures during migrations and cleanup projects.

Hostname audits are most useful before names are loaded into another system. Rename campaigns, DHCP imports, CMDB cleanup, certificate enrollment, monitoring discovery, and Kubernetes deployments all benefit from catching format drift early. A clean naming result can show that a proposed name fits the selected rules, but it cannot prove the host exists, resolves to the right address, belongs to the right owner, or is safe to rename without service impact.

How to Use This Tool

Paste one hostname, URL, CSV row, or host=value style snippet per line. You can also browse for a TXT, CSV, or LOG file under the displayed file limit.
Use Normalize when you want the textarea rewritten to the host text that will be checked, with URL schemes, paths, ports, and trailing root dots removed where possible.
Select the standard preset that matches the destination: enterprise naming, RFC 1123 hostname or fully qualified domain name, single DNS label, Kubernetes DNS label, or custom regex with DNS syntax.
For enterprise and custom modes, enter the naming regex and choose whether it applies to the first host label or the full normalized hostname.
Choose the lowercase policy. Require lowercase for strict standards, warn only for legacy inventories, or ignore the separate case rule when case should not affect this pass.
Add a required domain suffix only when every accepted name must sit under one zone, such as example.internal. Leave it blank for short labels or mixed-zone inventories.
Review the Hostname Audit, Rule Breakdown, Hostname Failure Mix, and JSON tabs. Copy or download the rows you need for cleanup tickets, change records, or review notes.

If the naming regex cannot be compiled, fix that setup problem first. Row-level findings are only meaningful after the selected rule set can run.

Interpreting Results

The summary separates clean names from names that fail or need review. A hard failure means the row violates a required rule, such as DNS syntax, lowercase policy, suffix membership, or naming regex. A review result means the name is not automatically rejected by the active hard rules, but it still deserves a human check before import or deployment.

Hostname audit status meanings
Status	Meaning	Common causes
Pass	The normalized hostname meets every active rule.	DNS-safe labels, matching naming pattern where active, acceptable case, required suffix present, and no duplicate finding.
Fail	At least one required rule is broken.	Blank normalized value, invalid character, overlong label, leading or trailing hyphen, all-numeric final label, regex mismatch, suffix mismatch, or required-lowercase violation.
Review	The row should be checked manually even when no hard failure is present.	Duplicate normalized hostname or uppercase when the policy is warn-only.

The audit table is row-focused, while the rule breakdown is policy-focused. Use the audit table when you need to fix specific hostnames. Use the rule breakdown when you need to see which rule is causing the most cleanup work. The failure mix chart counts categories, not unique failing hosts, so one hostname can contribute to more than one bar when it has several issues.

Treat duplicates as a review queue rather than an automatic delete list. Repeated names may be stale exports, aliases, repeated monitoring rows, or genuine conflicts. Confirm ownership and DNS records before removing or renaming anything.

Technical Details

DNS names are built from labels separated by dots. The DNS protocol is broader than hostname policy: it can carry labels that ordinary host software or platforms should not accept as hostnames. Hostname standards normally narrow the allowed shape to LDH labels, length limits, and predictable start and end characters so names work across resolvers, operating systems, TLS tooling, inventories, and automation.

RFC 1035 defines important DNS size limits and case-insensitive comparison behavior. RFC 1123 relaxed older hostname rules so a host label may begin with a digit. Operational guidance still warns about all-numeric labels and address-like names because users and software can confuse them with IP address notation. Kubernetes resource names add another layer of platform policy by requiring lowercase DNS-style labels, and many resources require an alphabetic first character unless a specific feature gate changes that behavior.

Rule Core

Hostname naming standard rule core
Rule area	Boundary used	Result effect
Hostname length and labels	Normalized hostname length must be 253 characters or fewer. Each label must be non-empty and 63 characters or fewer.	Any blank, empty-label, overlong-label, or overlong-hostname condition is `Fail`.
Allowed label characters	Labels may contain letters, digits, and hyphens. A label must start and end with a letter or digit.	Underscores, spaces, punctuation, leading hyphens, and trailing hyphens are `Fail`.
Numeric final label	A dotted hostname whose final label is entirely numeric is rejected.	`Fail`, because the value can be confused with numeric address notation.
Single-label presets	The single DNS label and Kubernetes label presets require exactly one label, with no dots.	A dotted fully qualified name fails those presets even if each individual label is valid.
Kubernetes label preset	One lowercase label, up to 63 characters, letters/digits/hyphen only, starting with a lowercase letter and ending with a lowercase letter or digit.	Uppercase letters, dots, underscores, digit-first names, and overlong labels are `Fail`.
Naming regex	Enterprise and custom modes apply the configured regular expression to either the first host label or the full normalized hostname.	A mismatch is `Fail`. A regex that cannot be compiled stops the audit until the setup is fixed.
Lowercase policy	Case can be required, warning-only, or ignored as a separate policy. Kubernetes mode still enforces lowercase as part of its syntax rule.	Require produces `Fail`, warn-only produces `Review`, and ignore skips only the separate case check.
Required suffix	A suffix such as `example.internal` accepts the exact suffix name and hostnames ending in `.example.internal`.	Names outside the required suffix are `Fail`. A blank suffix leaves this rule off.
Duplicate inventory	Duplicates are counted by normalized lowercase hostname.	Repeated names produce `Review` when no hard failure is present.

Input Normalization

Normalization turns mixed inventory text into a candidate hostname before the rule checks run. It is meant to remove common wrapper text, not to prove that the resulting hostname exists in DNS.

Hostname input normalization examples
Input style	Normalized host text	Why it matters
`web01.example.internal:8443/status`	`web01.example.internal`	The host is checked instead of the port or path.
`hostname=DC02-FW-EDGE-01`	`DC02-FW-EDGE-01`	Key-value inventory snippets can still be audited for case and naming policy.
`web01.example.internal.`	`web01.example.internal`	The trailing root dot is removed before suffix and duplicate comparison.
`dc01-app-api-01,owner,prod`	`dc01-app-api-01`	The first CSV-style field can be checked without cleaning the whole file first.

Preset Differences

Hostname standard preset differences
Preset	Best fit	Important boundary
Enterprise host label + DNS syntax	Internal asset names that must follow a site-role-service-sequence pattern.	Uses DNS syntax plus the naming regex. The regex target can be the first host label or the full hostname.
RFC 1123 hostname or FQDN	General hostnames and dotted names where organization-specific regex rules should stay off.	Checks DNS-safe hostname syntax, label lengths, final numeric label, case policy, suffix, and duplicates.
Single DNS label	Short names that must not include a domain suffix.	Rejects any dotted name even when each label is otherwise valid.
Kubernetes DNS label	Resource names that need Kubernetes-style lowercase label behavior.	Requires one lowercase label that starts with a letter and ends with a lowercase letter or digit.
Custom regex + DNS syntax	Team-specific standards that differ from the default enterprise pattern.	The DNS checks still run, so a matching regex cannot approve an invalid hostname.

The final status follows ordered severity: any fail-level issue makes the row fail; review-only issues produce review; rows with no active issues pass. That keeps the audit conservative while still separating hard breaks from cleanup questions.

Limitations and Privacy Notes

The checker validates naming text only. It does not query DNS, confirm forward or reverse records, test reachability, inspect TLS certificates, or verify service ownership.
Internationalized names are not converted to Punycode. Non-ASCII host text fails the LDH-style hostname checks used here.
Trailing root dots are removed before comparison. If your change process distinguishes absolute DNS names from display names, track that detail separately.
Pasted names and uploaded files are checked in the browser. Avoid placing sensitive internal hostnames in exports, screenshots, or shared URLs unless your process allows that disclosure.
A regular expression can enforce shape, but it cannot confirm that a site code, role token, service code, or sequence number is actually assigned to the right asset.

Use the output as a naming-standard audit, then pair it with DNS lookups, CMDB ownership checks, certificate checks, and platform admission tests when those facts matter to the change.

Worked Examples

Hostname naming standard worked examples
Input	Likely result	Reason
`dc01-rtr-edge-01`	Pass under the default enterprise pattern.	The name is lowercase, DNS-safe, and follows the expected site-role-service-sequence shape.
`DC02-FW-EDGE-01`	Fail or review, depending on lowercase policy.	The characters can be DNS-safe while the operational case rule still rejects or flags the row.
`lab_router_01`	Fail.	Underscores are not accepted in the hostname label rules used by these presets.
`dc01-srv-web-02.example.internal/status`	Checked as `dc01-srv-web-02.example.internal`.	The path is removed, then the selected preset, regex target, case rule, suffix, and duplicate checks run against the normalized hostname.
Two rows normalize to `dc01-app-api-01`.	Review.	The repeated normalized lowercase name may be harmless duplication, an aliasing pattern, or an inventory conflict.

FAQ

Why can a DNS-valid name still fail?

A local naming regex, lowercase policy, suffix requirement, or Kubernetes-style label rule can be stricter than general DNS hostname syntax. That is normal in enterprise inventories and platform admission checks.

Are underscores allowed in hostnames?

The hostname presets here reject underscores. DNS can contain names used for purposes other than hostnames, and some record-owner names use underscores, but ordinary host labels should stay with letters, digits, and hyphens for broad compatibility.

Should the regex check the host label or the full hostname?

Use the host-label target when the asset naming pattern applies only to the first label, such as dc01-app-api-01. Use the full-hostname target when the pattern intentionally includes the suffix or a dotted structure.

Does pass mean the host resolves?

No. Pass means the supplied text matches the selected syntax and naming rules. DNS resolution, reverse DNS, service reachability, ownership, and certificate coverage need separate checks.

Why are duplicates marked review instead of fail?

Repeated rows can come from exported aliases, duplicate monitoring records, copied examples, or a real naming conflict. The review status keeps them visible without assuming which interpretation is correct.

Glossary

Hostname: The name used to identify a host or service target in operational tooling, often represented as a DNS-safe label or dotted name.
DNS label: One part of a DNS name between dots, such as web01 in web01.example.internal.
FQDN: A fully qualified domain name that includes the host label and enough DNS suffix to identify its position in the namespace.
LDH: The letter-digit-hyphen character shape commonly used for interoperable host labels.
Required suffix: The domain ending that accepted hostnames must match, such as example.internal.