What does this tool actually check?

It compares each subdomain label against a bundled list of sensitive naming patterns such as admin, staging, internal, backup, vpn, git, jenkins, grafana, and kibana. It is a naming hygiene check, not a live scan, so it never connects to your hosts.

Why does a name like staging or internal matter?

Public DNS is enumerable by anyone, so a name like staging or internal tells an attacker exactly where the soft targets are. Pre-production and internal services are often less hardened, run debug modes, or use default credentials, making them a favoured entry point.

How are the severities assigned?

Critical covers services that commonly expose data or grant control with no auth, like kibana, redis, jenkins, and backup. High covers admin panels, dev and staging environments, and remote access. Medium covers legacy and demo hosts that are weaker but lower value.

Should I just rename my sensitive subdomains?

Renaming raises the bar but is only obscurity. The real fix is to keep internal services off public DNS entirely, put them behind a VPN or zero-trust proxy, enforce authentication, and restrict source IPs. Use the flags as a prompt to verify those controls.

Is my subdomain list sent anywhere?

No. The pattern list is bundled into the page and all matching happens locally in your browser, so the hostnames you paste never leave your machine. You can safely check internal naming conventions.

Subdomain Naming Security Checker

Public DNS is an open book: anyone can enumerate your subdomains, and a name like jenkins.example.com or staging-admin.example.com hands an attacker a map of your soft targets. This tool scans a pasted list of your subdomains against known sensitive naming patterns and ranks the matches by severity, so you can clean up your external attack surface before someone else maps it.

How it works

The checker splits your input into individual hostnames (stripping any http(s):// prefix and path), then breaks each one into dot-separated labels. Every label is compared against a bundled registry of sensitive tokens — admin, staging, dev, internal, backup, vpn, git, jenkins, grafana, kibana, redis, phpmyadmin, portainer, k8s, and many more.

A subdomain matches a token if any label equals it or begins with it (so staging-app matches staging). Each token carries a severity:

Critical — services that commonly leak data or grant control without authentication (kibana, redis, jenkins, backup, phpmyadmin, portainer, kubernetes).
High — admin panels, dev/staging/test environments, and remote access (admin, dev, vpn, rdp, grafana).
Medium — legacy, demo, or expected-but-noteworthy hosts (old, demo, mail, monitor).

Matches are grouped per subdomain and the table is sorted with the most dangerous findings first.

Example

Pasting a list that includes admin.example.com, jenkins.example.com, and internal-tools.example.com flags all three: Jenkins and the internal tools host as critical, the admin panel as high. Plain hosts like www, api, and blog are reported as clean.

Notes and tips

This is a naming-hygiene check, not a vulnerability scan. A clean result only means your names are not self-advertising; you still need real authentication and network controls.
The strongest control is keeping internal services off public DNS entirely — use split-horizon DNS or a private zone, and front anything remote-accessible with a VPN or identity-aware proxy.
Wildcard DNS and forgotten staging hosts are a classic subdomain-takeover risk. Audit your DNS regularly and decommission records that no longer point anywhere valid.