Parked Domain Detection

Domain parking is a normal part of the domain industry. When a domain is registered but not yet configured, or when it is being held for future use or sale, parking services host a placeholder page in its place. That placeholder typically shows ads, a "domain for sale" message, or a generic holding page. For standalone domains sitting unused in a portfolio, this is entirely legitimate.

The problem is when a subdomain of an active corporate domain starts pointing to one of these services. That means third-party content is being served under your organization's namespace, and you almost certainly did not put it there on purpose.

DNSAudit.io flags any DNS record on your domain that resolves to a hostname associated with a known domain parking service, registrar default nameserver, or domain marketplace.

Why This Matters

Abandoned subdomains are a common entry point

Over the lifecycle of a domain, subdomains accumulate. Development environments, marketing microsites, product pages, vendor integrations, and internal tools all get DNS records created for them. When those services are shut down, the DNS records are frequently left behind. If the underlying hosting account or platform resource is eventually deleted or expires, the subdomain may become eligible for takeover by whoever claims that resource next, and parking services are often the first to fill that gap.

This is one of the most consistently underestimated risks in corporate DNS hygiene. A subdomain pointing to a parking page is visible to anyone who visits it or queries DNS for it, and it is trivially exploitable.

Subdomain takeover via parking

When a subdomain has a CNAME record pointing to a third-party platform and the underlying resource no longer exists, an attacker who creates an account on that platform and claims the resource can serve arbitrary content from your subdomain. Parking services are a frequent landing point in this scenario because they automatically serve content for any hostname that resolves to their infrastructure.

The attacker does not need access to your DNS. They only need to claim the unclaimed resource on the platform your DNS is already pointing at. From there they can serve phishing pages, harvest credentials, issue TLS certificates through domain validation, and impersonate your organization to users who trust the subdomain because it sits under your corporate domain.

Unauthorized DNS changes

Not every parked domain finding is the result of an abandoned subdomain. Some occur because an attacker who gained access to your DNS management console modified a record to redirect traffic to infrastructure they control, using a parking service as a cover. A parking page looks less suspicious than an obvious redirect and can persist unnoticed for a long time if the subdomain is not actively monitored.

Registrar default nameservers on subdomain delegations

Some parking findings surface through NS records rather than CNAMEs. When a subdomain has been delegated to a separate DNS zone and that zone is hosted on a registrar's default nameservers, it typically means the zone was set up and then abandoned without being properly configured or removed. The subdomain is effectively uncontrolled, and anyone who can claim that zone at the registrar can serve content under it.

Authentication and email subdomains

The severity of a parked subdomain finding depends heavily on what that subdomain was used for. A parked marketing microsite is a brand and reputation problem. A parked subdomain that previously handled login, single sign-on, VPN access, mail delivery, or email autodiscovery is a critical security incident. An attacker serving content from mail.yourdomain.com or login.yourdomain.com can intercept credentials, redirect email, and abuse the implicit trust users place in those hostnames.

What This Check Examines

DNSAudit.io inspects all CNAME and NS records published for your domain and compares their values against a database of known parking provider hostnames, registrar default nameservers, domain marketplace infrastructure, and domain suspension endpoints.

CNAME matches indicate the subdomain itself is pointing directly to a parking service. NS matches indicate that an entire subdomain delegation has been handed to parking infrastructure, which is a broader finding since it affects every hostname under that subdomain, not just the one record.

The check collects all matches across the full zone. A domain can have multiple parked subdomains simultaneously and each one is reported as a separate finding.

Reading the Findings

Each finding includes the record type, the subdomain name, and the parking provider hostname it resolves to. For example, a CNAME finding looks like this:

Type:   CNAME
Name:   promo.yourdomain.com
Value:  parkingcrew.net

And in a raw DNS query:

promo.yourdomain.com.   3600   IN   CNAME   parkingcrew.net.

An NS delegation finding looks like this:

Type:   NS
Name:   old.yourdomain.com
Value:  ns1.domaincontrol.com

Each finding also includes a sublabel indicating the category of parking infrastructure detected. The categories are Parked domain for dedicated parking platform matches, Registrar default nameserver for registrar NS matches, Enterprise domain management for findings on known enterprise registrar infrastructure, and Suspended domain for subdomains flagged by their registrar for contact verification failure.

Complete Fix Guide

Step 1: Identify each flagged subdomain

For each finding, determine what the subdomain was originally used for and when it was last actively configured. Check your DNS change history if your provider logs it. If the subdomain name gives a clear indication of its former purpose, check whether the underlying service, hosting account, or platform resource still exists and who owns it.

Step 2: If the change is unauthorized, respond immediately

If a parking record appears in your zone and no one on your team can account for it, treat it as a potential compromise:

• Rotate your DNS provider credentials immediately to prevent further unauthorized changes
• Review access logs if your DNS provider supports them, looking for unauthorized logins or API calls around the time the record was changed
• Audit the full zone for other unexpected changes made in the same session, since attackers often make multiple changes at once

Step 3: Remove records for decommissioned services

If the subdomain belongs to a service that has been shut down, the correct fix is to delete the DNS record entirely. There is no reason to leave a CNAME or NS record in place for a service that no longer exists.

Before deleting, check whether the subdomain has any live traffic that might still depend on it. A quick check of web analytics or server logs for the relevant service can confirm whether anything is still using it.

Step 4: Reclaim or replace records for active services

If the subdomain should be pointing to active infrastructure but has drifted to a parking page, update the record to point to the correct destination. Confirm the underlying hosting resource exists and is properly configured before updating DNS.

# Before: subdomain pointing to parking infrastructure
promo.yourdomain.com.   3600   IN   CNAME   parkingcrew.net.

# After: subdomain pointing to correct infrastructure
promo.yourdomain.com.   3600   IN   CNAME   yourdomain.hosting-provider.com.

Step 5: Audit the full zone

A parked subdomain is often a symptom of a DNS zone that has not been reviewed in a long time. Once you have addressed the flagged findings, review the full zone for other records pointing to services or infrastructure that no longer exist. Look for CNAMEs pointing to platforms where your organization no longer has an active account, NS delegations to zones that were never properly configured, and subdomains that no longer serve any business purpose.

Special Cases

Prevention

The most effective prevention for parked subdomain findings is a DNS record lifecycle policy. Every DNS record created should be documented with its purpose, the service it supports, and an owner responsible for maintaining it. When a service is decommissioned, removing its DNS records should be a required step in the shutdown process rather than an afterthought.

For larger organizations managing DNS programmatically, infrastructure-as-code approaches where the zone is defined in version-controlled configuration make abandoned records far easier to identify. Any record in the configuration that no longer maps to an active resource becomes immediately visible during routine reviews.

Regular DNS audits using tools like DNSAudit.io catch records that slip through decommissioning processes and surface parking findings before they can be exploited.