Hostname Naming Standard Checker
Check hostnames, URLs, CSV rows, or host=value lines against DNS syntax, naming regex, lowercase, suffix, and duplicate rules before inventory review.Hostname Naming Standard Checker
- {{ message }}
| Input | Normalized | Status | DNS syntax | Naming regex | Case | Duplicate | Detail | Copy |
|---|---|---|---|---|---|---|---|---|
| No hostnames parsed yet. | ||||||||
| {{ row.input }} | {{ row.normalized }} | {{ row.status }} | {{ row.syntaxStatus }} | {{ row.patternStatus }} | {{ row.caseStatus }} | {{ row.duplicateStatus }} | {{ row.detail }} | |
| Rule | Scope | Status | Affected | Example | Next action | Copy |
|---|---|---|---|---|---|---|
| {{ row.rule }} | {{ row.scope }} | {{ row.status }} | {{ row.affected }} | {{ row.example }} | {{ row.action }} |
Introduction
Hostname naming standards turn infrastructure names into predictable records that people and automation can read the same way. A name such as dc01-rtr-edge-01 can carry site, role, service, and sequence clues, while a mixed-case or underscore-heavy name can drift away from DNS, certificate, Kubernetes, inventory, or monitoring expectations.
Good hostname checks separate two questions that often get blended together. First, the name must be safe for the DNS-style syntax used by hosts and many platform identifiers. Second, it may need to follow an organization-specific pattern that says which tokens belong in the name and in what order. A name can pass DNS syntax and still fail the local naming pattern.
Hostname review matters before a rename campaign, monitoring import, certificate request, DNS handoff, or Kubernetes migration. A bad name can work in one place and break in another because a platform rejects dots, uppercase, a long label, an underscore, or a label that starts or ends with a hyphen.
A clean hostname audit is still a naming-policy check, not a guarantee that the host exists, resolves, has a certificate, or points at the right service. Treat the result as a readiness screen for syntax and naming drift, then confirm DNS records and service ownership separately.
Technical Details:
DNS hostnames are built from labels separated by dots. The practical host-name subset is often called LDH because labels use letters, digits, and hyphen. Each non-empty label must fit within the per-label limit, and host labels should start and end with a letter or digit. RFC 1123 relaxed the older first-character rule so an Internet host label may start with a digit.
DNS matching is case-insensitive for ordinary ASCII labels, so WEB01 and web01 can refer to the same DNS name. Operational naming standards still often require lowercase because inventories, scripts, certificates, file paths, and Kubernetes resources tend to behave better when the same asset is written the same way every time.
Fully qualified names add another check: every label must be valid, the overall name must stay within the supported length, and the final label should not be entirely numeric for normal hostname use. Single-label checks are stricter in a different way because a dotted value such as web01.example.internal is no longer one DNS label.
Rule Core
The audit applies normalization first, then syntax, pattern, case, suffix, and duplicate checks. A failing syntax, pattern, suffix, or required-lowercase check produces Fail. A warning-only lowercase issue or duplicate produces Review when no fail condition is present. A row with no issues produces Pass.
| Check | Boundary used | Output effect |
|---|---|---|
| DNS syntax | Non-empty labels, full name up to 253 characters, labels up to 63 characters, letters/digits/hyphen only, no leading or trailing hyphen, and no all-numeric final label on dotted names. | Any syntax issue marks the hostname as Fail. |
| Single DNS label | The value must contain exactly one label, so dotted hostnames fail this preset even when each label is individually valid. | Useful when checking short asset names rather than FQDNs. |
| Kubernetes DNS label | One lowercase label, letters/digits/hyphen only, maximum 63 characters, starting with a lowercase letter and ending with a lowercase letter or digit. | Uppercase, dots, underscores, digit-first names, and overlong labels fail. |
| Naming regex | Applied in Enterprise host label + DNS syntax and Custom regex + DNS syntax modes. The regex can target the first host label or the full normalized hostname. |
A mismatch marks the row as Fail; an invalid regex stops the run with a setup message. |
| Lowercase policy | Require lowercase fails uppercase hostnames, Warn only marks them for review, and Ignore case skips the separate case policy check. |
Kubernetes syntax can still fail uppercase names even when the separate case policy is ignored. |
| Required domain suffix | Blank disables suffix checks. A value such as example.internal accepts that exact name and names ending in .example.internal. |
Names outside the selected suffix fail the suffix rule. |
| Duplicate inventory | Duplicates are counted by normalized lowercase hostname. | Repeated names produce Review so aliases or competing host records can be checked by a person. |
| Input shape | How it is normalized | Why it matters |
|---|---|---|
| Plain line | The first whitespace-separated token is used, after trimming quotes or backticks. | Pasted inventories can include notes after the hostname without breaking the row. |
host=value or hostname=value |
The value after the key is kept as the candidate name. | Log snippets and configuration fragments can be checked without manual cleanup. |
| CSV-style row | The first CSV cell is used, with quoted cells handled. | A first-column inventory export can be pasted directly. |
| URL or host with path | The hostname is extracted from a URL; simple paths and trailing root dots are removed. | Incident notes and monitoring links can be reduced to the name that actually needs review. |
| Host with port | A trailing numeric port is removed before checking. | web01.example.internal:8443 is judged as the hostname, not as a service endpoint string. |
The audit is deterministic for the entered text and selected controls. It does not query DNS, test reachability, reserve names, rewrite hostnames automatically, or decide whether a proposed rename is safe for every consuming system.
Everyday Use & Decision Guide:
Start with the preset that matches the handoff. Use Enterprise host label + DNS syntax when a short asset label should match the default site-role-service-sequence pattern. Use RFC 1123 hostname or FQDN when the question is basic hostname syntax for a dotted name. Use Kubernetes DNS label when the value must fit platform naming rules for a single resource name.
Paste one hostname per line into Hostname inventory. The field can also accept URLs, first-column CSV rows, and host=value snippets, then Normalize can rewrite the text area to the names that will be checked. TXT, CSV, and LOG files under the size limit are read in the browser session.
Keep Regex target on Host label before first dot when FQDNs should still be judged by their asset label, such as dc01-srv-web-02.example.internal. Switch to Full hostname only when the approved pattern is meant to include dots and the domain suffix.
- Hostname Audit is the row-by-row review. Check
Normalized,Status,DNS syntax,Naming regex,Case,Duplicate, andDetailbefore copying results. - Rule Breakdown shows which rules affected the batch, one example name, and the suggested next action for each rule.
- Hostname Failure Mix gives a quick count of clean names and issue categories when a larger inventory needs triage.
- JSON keeps the selected mode, pattern, suffix, totals, issue counts, audit rows, rule rows, and chart rows in a machine-readable summary.
A common mistake is treating mixed case as a DNS failure. The DNS comparison itself is case-insensitive, but the selected lowercase policy can still fail or warn because consistent lowercase names reduce drift in automation and platform handoffs. Another common mistake is assuming Pass proves the host is live. It only means the entered name passed the selected naming rules.
Before trusting a clean batch, confirm that Standard preset, Naming regex, Regex target, Lowercase policy, and Required domain suffix match the standard you meant to enforce. A wrong regex target can make every FQDN look broken or let a short host label pass when the full name should have been checked.
Step-by-Step Guide:
Work from inventory cleanup to rule choice, then inspect the audit rows before using the totals.
- Paste names, URLs, CSV rows, or
host=valuesnippets intoHostname inventory. The source hint should show how many lines or files are loaded after you browse, drop, or edit text. - Click
Normalizewhen the input contains URLs, paths, ports, or trailing root dots. The textarea should change to one normalized hostname per line. - Choose
Standard preset. If the preset uses a regex, confirm thatNaming regexcompiles; if the setup message says the regex could not be compiled, fix the expression before reviewing rows. - Set
Regex targettoHost label before first dotfor asset-label standards, orFull hostnamefor patterns that include the domain suffix. - Set
Lowercase policyto require, warn, or ignore uppercase. UseRequired domain suffixonly when every hostname should be under the same DNS suffix. - Read
Hostname Audit. A row withFailneeds a syntax, regex, suffix, or required-lowercase fix. A row withReviewusually needs duplicate or warning-only case review. - Open
Rule Breakdownto see how many names each active rule affected and which example name should be inspected first. - Use
Hostname Failure MixandJSONafter the audit rows match the policy you intended to test.
Interpreting Results:
Read Status and Detail together. Pass means no selected rule flagged the normalized name. Fail means at least one hard rule failed. Review means the name avoided hard failures but still hit a warning, usually duplicate inventory or warning-only uppercase.
The strongest trust check is the Rule Breakdown. If the active rule list does not show the regex, case policy, suffix, or Kubernetes label rule you expected, fix the controls and rerun the review before using the batch summary.
| Result cue | What it means | What to verify next |
|---|---|---|
DNS syntax = Fail |
The normalized name has an empty label, bad character, long label, long full name, leading or trailing hyphen, or numeric final label. | Fix the hostname shape before checking naming pattern drift. |
Naming regex = Fail |
The selected regex did not match the chosen target. | Confirm whether the pattern should inspect the first host label or the full hostname. |
Case = Review |
Uppercase was found while the lowercase policy is warning only. | Decide whether to rename, accept legacy casing, or switch to required lowercase for a stricter audit. |
Duplicate = Review |
The same normalized lowercase hostname appears more than once. | Confirm whether the repeated row is a true duplicate, an alias note, or an inventory export issue. |
All pass |
Every parsed hostname passed the selected rules. | Still verify the regex and suffix setup, then confirm DNS records or platform ownership elsewhere if those facts matter. |
Do not overread a failure count as a rename plan. Some failures are simple cleanup, such as pasted URL paths or ports. Others may require policy changes, inventory correction, DNS owner review, or coordinated host renaming.
Worked Examples:
A mixed inventory before a network import
Paste dc01-rtr-edge-01, dc01-sw-core-01, and dc01-app-api-01 with Enterprise host label + DNS syntax, the default pattern, Regex target set to host label, and Require lowercase. Hostname Audit shows Pass rows because the labels fit DNS syntax and match the site-role-service-sequence pattern. Rule Breakdown should show zero affected rows for DNS syntax, lowercase policy, naming regex, and duplicate inventory.
A legacy uppercase firewall name
Paste DC02-FW-EDGE-01 in enterprise mode with Warn only for Lowercase policy. The row can avoid a hard DNS syntax failure, but Case becomes Review and Status becomes Review if no stricter rule fails. Change the policy to Require lowercase and the same uppercase value becomes a fail condition.
A Kubernetes label candidate
Check 7-api.edge with Kubernetes DNS label. DNS syntax fails because this preset accepts one label, requires lowercase alphanumeric characters and hyphen only, and requires the label to start with a lowercase letter. Renaming the candidate to api-edge-7 gives the row a chance to pass the Kubernetes label rule.
A URL pasted from a monitoring alert
Paste https://dc01-srv-web-02.example.internal/status, click Normalize, and keep Regex target on host label. The input becomes dc01-srv-web-02.example.internal, while the regex check uses dc01-srv-web-02. If Required domain suffix is example.internal, the suffix rule can pass at the same time as the asset-label regex.
FAQ:
Can I paste a full URL?
Yes. A URL is reduced to its hostname, paths are removed, a trailing numeric port is removed, and a trailing root dot is stripped before the audit row is created.
Why did a valid DNS name fail the enterprise preset?
Enterprise mode checks DNS syntax and the naming regex. A name can be DNS-safe but still fail because the host label does not match the selected regex or because the regex target is set to the wrong part of the hostname.
Why does Kubernetes mode reject a dotted hostname?
Kubernetes DNS label checks one label, not an FQDN. Remove the domain portion or choose an RFC hostname preset when a dotted value is the intended input.
What should I do when the regex setup fails?
Fix Naming regex before reviewing rows. The pattern must be a valid JavaScript regular expression, either as plain pattern text or slash-delimited regex text with supported flags.
Does the checker look up DNS records?
No. It checks the pasted or loaded inventory text in the browser session against syntax, regex, case, suffix, and duplicate rules. Use a DNS lookup or trace tool when you need resolver evidence.
Glossary:
- Hostname
- A DNS-style name or host label used to identify a machine, service, or platform object.
- Host label
- The first label before the first dot, such as
dc01-srv-web-02indc01-srv-web-02.example.internal. - FQDN
- Fully qualified domain name, a dotted name that includes the host and its DNS suffix.
- LDH
- The letters, digits, and hyphen character set commonly used for Internet host labels.
- Regex target
- The part of the normalized hostname that the naming regex checks: either the host label or the full hostname.
- Required domain suffix
- An optional suffix gate that keeps names inside an approved DNS domain.
References:
- RFC 1035: Domain names - implementation and specification, RFC Editor, November 1987.
- RFC 1123: Requirements for Internet Hosts - Application and Support, RFC Editor, October 1989.
- Object Names and IDs, Kubernetes documentation.