Subdomain Resolution

RedScore enumerates subdomains for your domain (from passive DNS aggregators and CT logs), takes a stratified sample by prefix, and resolves each one. The key distinction in scoring: only owned subdomains (those with A, AAAA, or CNAME records you publish today) affect the verdict. Subdomains that appear in third-party historical sources but have no owner-published DNS now are reported for context but do not penalize the score.

How the check works

Three phases per scan:

• Enumerate. Pull subdomains from passive DNS sources (crt.sh and aggregators). If passive data is unavailable, fall back to apex + www only and warn.
• Sample. Take a stratified sample by prefix bucket (api, admin, dev, mail, etc.) up to a per-run cap so popular domains do not blow the scan budget. Stratification ensures coverage of common prefix groups even when the full population is large.
• Resolve. For each sampled host, check whether it has an authoritative DNS record (owned) and whether it resolves. Compute per-bucket resolution rates with 95% Wilson confidence intervals.

How the verdict maps to evidence

• Pass: all owned subdomains resolve, OR owned resolution rate at or above 75%, OR no owned subdomains were found (everything is passive artifacts).
• Warn: owned resolution rate between 30% and 75%. Some owned DNS records do not resolve.
• Warn (fallback): passive enumeration was unavailable for this scan, so scoring fell back to apex/www only. Re-running the scan later may produce a real verdict.
• Fail: owned resolution rate below 30%. Most of your published subdomains do not resolve.

The evidence breaks results into owned_subdomains (your DNS) and passive_footprint (everything else), plus per-bucket metrics so you can see which prefix groups have the most stale entries.

Warn or fail: clean up stale owned DNS

Walk the unresolved_samples and evaluated_hosts arrays. For each owned subdomain that does not resolve, the question is whether you still need it.

Owned subdomains that should still resolve

If the subdomain points at a host that should be live (web app, API, internal service), the failure is likely one of:

• The CNAME target is dead (see Dangling CNAME Detection for the takeover-risk analysis).
• The A record points at an IP that no longer responds.
• The host is up but DNS is misconfigured (wrong glue, NS issues at a delegated subzone).
• The host serves on non-standard ports and does not respond to the resolver's expected probes.

Fix the underlying DNS or resurrect the target host.

Owned subdomains that should not exist

If the subdomain is left over from a deprecated service, marketing campaign, or migrated host, just delete the record. Each stale owned record is a small attack surface (subdomain takeover risk, monitoring noise, drift in your asset inventory) and a needless reduction in your hygiene score.

In your DNS provider UI (Cloudflare, Route 53, Google Cloud DNS, NS1, Azure DNS, DNSimple), find the record by hostname and remove it. In a BIND zone file, delete the line and reload (rndc reload). Wait one TTL for the deletion to propagate before re-scanning.

Warn (fallback): passive enumeration unavailable

When passive DNS data is not available for your domain, the check falls back to scoring only the apex and www and reports a warn. This is a scan-side limitation, not a problem with your DNS. Two reasons it can happen:

• The passive enumeration task did not complete in time for this scan run. Re-run the lookup; it usually resolves on the next scan.
• Your domain is genuinely too new or too obscure to have appeared in passive sources yet. The fallback warn is honest in that case; once your domain accrues more public DNS history (CT log entries from cert issuance, mentions in passive aggregators), the check will start scoring against a real subdomain list.

Pass with stale passive entries

If passive_footprint shows passive_only_stale > 0, those are hosts that appeared in third-party historical DNS data but have no live records on your zone today. They do not affect your score (the check intentionally does not penalize you for old records other people captured). They are reported only for context.

If you want to clean up the public record, the only practical move is time: passive aggregators typically expire records after months without re-confirmation. Reissuing certs or publishing records that overlap the historical entries can refresh them, but it is rarely worth the effort.

Verify the fix

• Pull the unresolved_samples list from the previous scan's evidence.
• For each entry, run dig +short A <host> @1.1.1.1 (and dig CNAME, dig AAAA). Confirm the deleted ones return nothing and the fixed ones return the right address.
• Re-run the RedScore lookup. The owned_subdomains.resolving / owned_subdomains.count ratio should be at or near 100%.

Common pitfalls

• Confusing passive-only stale with owned stale. The check separates them deliberately. Cleaning up your owned DNS does not remove third-party historical records.
• Re-running too quickly after a fallback warn. Passive enumeration takes time. If you re-scan within minutes, you may hit the same fallback. Wait an hour or so.
• Treating Pass as "all good." Pass means owned resolution rate at or above 75%, not 100%. Look at owned_subdomains.resolving vs count to find the remaining stale records.
• Removing a record that something still uses. Audit before deleting; hardcoded references, OAuth callbacks, monitoring checks, and email templates can break silently.
• Not investigating stale CNAMEs for takeover risk. Each unresolved CNAME is also a potential subdomain takeover surface. Cross-reference unresolved CNAMEs against the Dangling CNAME Detection findings.