Subdomain glossary

A subdomain is a hostname that sits to the left of the root domain, such as api.example.com. Teams create them constantly, and the naming conventions below are close to universal across the industry. That predictability cuts both ways: it makes infrastructure easy to manage, and it tells an attacker exactly where to look first.

Development

dev High attention

A development or developer environment, usually a near-copy of production used to build and test features. It is frequently left running after a launch, and it often has weaker access controls, seeded test data, and verbose error pages that leak stack traces and internal hostnames.

staging High attention

An environment that mirrors production to rehearse releases. Because it holds a realistic copy of real data, a staging box that stays up after go-live is one of the most sensitive things a company publishes. Common to see it indexed and even left with production credentials.

test / qa / uat High attention

Testing environments. UAT (user acceptance testing) and QA (quality assurance) hosts are typically internal-only by policy, but often reachable from the internet. These are high-value targets because testers routinely attach real files, and access rules tend to be looser than in production.

Infrastructure

api Worth checking

An application programming interface endpoint. Common in subdomain results, and frequently the most security-relevant host you own, since API hosts are designed to be called from anywhere. Sub-paths such as api-v2 or api-staging often indicate a deprecated version still in service.

cdn Usually fine

A content delivery network host, usually fronting static assets and images. Low risk in itself, but its origin configuration is sensitive: an origin that accepts requests from the internet directly can be bypassed entirely, defeating every control the CDN provides.

Email

mail / smtp / imap Usually fine

Mail infrastructure. If these are publicly listed, they are the surface behind credential phishing, and an SMTP host that allows relaying is an open spam relay. Their presence is normal, so a listed mail host alone is not a finding; the configuration is what matters.

Administration

admin / manage / portal High attention

Administration interfaces. These should be the most tightly restricted hosts a company owns, because they are the route to full control of everything else. An internet-reachable admin panel with weak authentication is one of the most commonly exploited weaknesses in existence.

Access

vpn High attention

A remote access gateway. Legitimate remote access for staff, but also a high-value target since compromising it means a foothold inside the network. Should be reachable only from known locations or behind strong multi-factor authentication.

internal / intranet High attention

A name intended for internal use only. Finding one listed in public CT logs usually means either it is genuinely reachable from the internet, or that a certificate was issued for it by mistake. Both are worth investigating.

Delivery

git / jenkins / ci High attention

Source control and build infrastructure. Historically the most damaging category of exposed host, because build servers hold deployment credentials and repository write access. A reachable CI server can be equivalent to full compromise of the product.

Retired

legacy / old / bak / backup High attention

Hosts kept for rollback, migration or an application that was never switched off. The most common genuinely forgotten category, and the reason subdomain enumeration is a routine part of attack surface management. These are usually unpatched, because nobody is maintaining them.

v1 / v2 Worth checking

Version markers. Superseded API and application versions are routinely left deployed long after a successor ships, often on older dependencies and without the fixes applied to the current release. Safe to retire once traffic confirms nothing calls them.

dev1 / test2 / staging-old Worth checking

Numbered and suffixed variants. When a team re-provisions an environment, the old one is often left behind under a new name, accumulating a trail of near-duplicate hosts. Any variant you cannot immediately account for is a candidate for retirement.

Pre-release

beta / alpha / demo / sandbox Worth checking

Pre-release and demonstration environments. Commonly built with real integrations and production API keys, since they are meant to look convincing to reviewers. Sandbox and demo hosts in particular are attractive because they are assumed to be harmless.

preview / pr-123 Worth checking

Automated per-branch preview deployments, which on many platforms create a hostname per pull request. The naming pattern is highly predictable, so a whole set of unmerged, unreviewed deployments can be discoverable even though each one was expected to be temporary.

Standard

www Usually fine

The conventional public-facing host, and by far the most common entry in any subdomain list. Its presence in results is unremarkable. The thing worth checking is whether non-www and www both resolve, and that one canonicalises to the other.

Business

shop / store / checkout Worth checking

Commerce hosts, sometimes running on a separate platform from the main site. Splitting checkout onto a subdomain of this kind creates a distinct trust boundary: a vulnerability there sits directly next to cardholder data even though it is a different hostname.

status Usually fine

A status or incident page, frequently hosted by a third-party service. Rarely a risk in itself, and usually intended to be public. Listed here because it is a common false positive that people waste time investigating.

What to do with an unfamiliar result

Not every name will be on this list, and not every name will be obvious from the hostname alone. When you find one you do not recognise, work through it in this order:

1. Check whether it still resolves. A name that no longer resolves is dead infrastructure, and is only a concern if a DNS record still points somewhere.
2. Look at what it serves. If it responds, note whether it is in scope for your organisation's public surface or an internal system that should not be reachable.
3. Establish ownership. Cross-reference with your DNS zone file, certificate records, and asset inventory. Anything nobody can claim is a governance problem.
4. Decide: keep, fix, or remove. If it is in use, confirm it is patched and access-controlled. If it is not, delete the DNS record.

Why abandoned hosts matter

The reason to care about a dead subdomain is not that it still runs. It is that the name may still be claimable. A CNAME pointing at a lapsed third-party account, or a sub-delegated zone nobody removed, means someone else could register the underlying resource and start serving content under your domain. Deleting the record is the fix; simply ignoring the host is not.

How subdomain discovery works covers the mechanism in more depth, and the FAQ covers removal and legality.