Dangling DNS Cleanup: A Safe Service Retirement Workflow

Define what retirement means

Retiring an application, removing a hostname, and allowing a registered domain to expire are different decisions. A product can close while its domain remains necessary for redirects, customer communications, or fraud prevention. A shared hosting resource can remain active after one tenant leaves.

Microsoft's dangling-DNS guidance describes records that survive resource deletion and recommends comparing DNS references with resources that exist and remain under your control. The risk depends on the service and its ownership protections; a stale CNAME alone does not prove that someone can claim the target.

Give the retirement ticket three owners: the application owner, the DNS or platform operator, and the person responsible for domain retention. One person can fill several roles, but none should disappear when the original project closes.

The business outcome is a defensible closure decision. You want to stop unnecessary infrastructure spending while preserving customer routes, registration obligations, and evidence for future investigations. “The endpoint stopped responding” is not enough to close the work.

1. Build an owned-asset retirement manifest

Export candidates from your service catalog, infrastructure configuration, and DNS management system. A lookup of one hostname cannot enumerate every reference in a zone. Include delegated subdomains, alternate hostnames, IPv6 records, and shared destinations where relevant.

For each entry, record the hostname, parent registered domain, resource identifier, owning team, proposed action, change ticket, and retention decision. Attach the current authoritative records and the provider account that controls the destination. Resolve missing ownership before requesting deletion.

Treat this manifest as an approved list of assets, not a queue of arbitrary domains to probe. For a larger portfolio, partition work by owning team and change window. This makes exceptions actionable rather than leaving one undifferentiated spreadsheet of warnings.

2. Capture a baseline before changing references

Use DNS record validation to collect the specific A, AAAA, CNAME, MX, or TXT records relevant to the service. Compare those observations with your authoritative configuration. Do not assume a successful response means every configured record was examined.

Check registration context at the registrable-domain level. Preserve raw data and available parsed fields, then reconcile expiration dates with the registrar account. An absent field means the workflow needs another source; it does not mean the domain has no renewal obligation.

Use IP and ASN context to recognize unexpected network associations. These fields can support security investigation, but a shared ISP or hosting organization does not prove resource ownership. The cloud account and resource inventory must answer that question.

For retained HTTPS destinations, collect certificate validity and expiration evidence. Record which hostname and port you inspected. A valid certificate is useful evidence about that connection, not proof that the business still controls the hosting account.

These requests use the documented production endpoints. Set RETIRE_HOST and REGISTERED_DOMAIN from the approved manifest; keep the key in the runner's secret store.

curl --fail-with-body --silent --show-error --max-time 20 \
  --get 'https://api.ops.tools/v1-dns-lookup' \
  --header "x-api-key: ${OPS_TOOLS_API_KEY}" \
  --data-urlencode "address=${RETIRE_HOST}" \
  --data-urlencode 'type=CNAME' \
  --data-urlencode 'skipCache=true'

curl --fail-with-body --silent --show-error --max-time 20 \
  --get 'https://api.ops.tools/v1-whois-data' \
  --header "x-api-key: ${OPS_TOOLS_API_KEY}" \
  --data-urlencode "domain=${REGISTERED_DOMAIN}" \
  --data-urlencode 'parseWhoisToJson=true' \
  --data-urlencode 'noCache=true'

curl --fail-with-body --silent --show-error --max-time 20 \
  --get 'https://api.ops.tools/v1-ssl-checker' \
  --header "x-api-key: ${OPS_TOOLS_API_KEY}" \
  --data-urlencode "domain=${RETIRE_HOST}" \
  --data-urlencode 'skipCache=true'

The DNS response includes success, address, and type, with optional records and error details. Certificate responses expose validity and expiry fields. Registration parsing is optional. Retain these differences in your evidence model rather than inventing one universal “healthy” flag.

3. Change DNS while you still control the destination

Approve the removal or replacement in the DNS management system. Keep the old resource under your control while the change is verified. If customers need a transition page, provision and validate that controlled destination before repointing records.

Review references outside DNS too: callback URLs, OAuth redirects, application configuration, documentation, and customer integrations. Removing a record does not remove stored trust in that hostname. The OWASP prevention guidance describes these dependencies and the importance of coordinating DNS cleanup with resource decommissioning.

Base the observation window on the previous record configuration, provider behavior, and your operational policy. Do not hardcode a universal waiting period. A cache-bypass request does not prove that every resolver has refreshed. Use the freshness evaluation method to understand what the API observations establish.

For delegated zones, include the parent delegation in the review. Route 53's dangling-delegation documentation shows why zone deletion and nameserver references need coordinated handling. Apply the actual provider's lifecycle rules instead of generalizing one cloud's protections.

4. Run a bounded bulk validation worker

Bulk processing here means your worker makes documented single-target requests over the approved inventory. It does not assume an undocumented batch endpoint. Start sequentially, cap the job, and retain one outcome per check before introducing concurrency.

The example below deliberately handles only CNAME checks. Its manifest contains exact expected values for approved replacements, or an empty list for intended removals. The example names are illustrative; replace them with assets you control.

[
  {
    "host": "legacy.example.com",
    "expected": []
  },
  {
    "host": "help.example.com",
    "expected": ["retained.example.net"]
  }
]

Save the worker as retirement-check.mjs and the manifest as retirement.json. It requires a Node.js runtime with built-in fetch. The local limits are example job safeguards, not Ops.Tools service limits.

import { readFile, writeFile } from 'node:fs/promises';

const apiKey = process.env.OPS_TOOLS_API_KEY;
if (!apiKey) throw new Error('Set OPS_TOOLS_API_KEY');
const checks = JSON.parse(await readFile(process.argv[2] ?? 'retirement.json', 'utf8'));
const validName = (value) => typeof value === 'string' &&
  /^(?:[a-z0-9](?:[a-z0-9-]{0,61}[a-z0-9])?\.)+[a-z0-9-]{2,63}\.?$/i.test(value);
if (!Array.isArray(checks) || checks.length === 0 || checks.length > 100 ||
    !checks.every((check) => check && validName(check.host) &&
      Array.isArray(check.expected) && check.expected.every(validName))) {
  throw new Error('Use 1–100 hostname checks with explicit expected CNAME arrays');
}
const normalize = (values) => [...new Set(values.map((value) =>
  value.toLowerCase().replace(/\.$/, '')))].sort();
const results = [];

for (const check of checks) {
  const url = new URL('https://api.ops.tools/v1-dns-lookup');
  url.search = new URLSearchParams({
    address: check.host,
    type: 'CNAME',
    skipCache: 'true',
  }).toString();
  const result = { host: check.host, checkedAt: new Date().toISOString(), outcome: 'unknown' };
  try {
    const response = await fetch(url, {
      headers: { 'x-api-key': apiKey },
      signal: AbortSignal.timeout(20_000),
    });
    result.status = response.status;
    const body = await response.json();
    result.evidence = body;
    if (response.ok && body?.success === true && body.type === 'CNAME' &&
        validName(body.address) && normalize([body.address])[0] === normalize([check.host])[0] &&
        !body.error && Array.isArray(body.records) && body.records.every(validName)) {
      result.outcome = JSON.stringify(normalize(body.records)) ===
        JSON.stringify(normalize(check.expected)) ? 'review' : 'hold';
    }
  } catch {
    result.outcome = 'unknown';
  }
  results.push(result);
}
await writeFile('retirement-evidence.json', JSON.stringify(results, null, 2), { mode: 0o600 });
console.log(JSON.stringify({ checks: results.length, outcomes: results.map((item) => item.outcome) }));
if (results.some((item) => item.outcome !== 'review')) process.exitCode = 1;

This parser accepts only an explicit string-array record shape. Other shapes, missing records, and unsuccessful responses stay unknown. The public schema does not specify a complete mapping from DNS-negative answers to API outcomes, so the worker does not reinterpret an error as successful removal.

Even review means only that this observation matched the requested condition. An empty CNAME answer says nothing about remaining A or AAAA records, wildcard behavior, delegation, or other names pointing at the resource. Complete those checks against the inventory and authoritative source before approval.

5. Make CI stop at evidence review

Add the worker after the approved DNS change and before the resource-release stage. Use node retirement-check.mjs retirement.json, retain its exit status, and upload the evidence file even when the check fails. Keep the artifact access limited to the teams handling the change.

An unknown or mismatched result should hold the pipeline. A matching result should expose the owner-approval step, not execute resource deletion. Require the approver to confirm authoritative records, remaining dependencies, the observation window, and continued control of the old resource.

For recurring infrastructure monitoring, run the same checks on retired-but-retained assets. When a finding changes, your orchestration can post a notification to your own webhook receiver. Include the ticket, hostname, outcome, and a restricted evidence link. Handle signing, retries, deduplication, and routing in that customer-owned integration.

Ops.Tools pricing mentions webhook features, but the reviewed public API contract does not specify subscription endpoints or event delivery semantics. This workflow therefore relies on your existing notification system. It does not imply a native CI, SIEM, ticketing, or chat integration.

The existing CI/CD validation article addresses launch checks. Here the gate protects the opposite transition: releasing infrastructure only after approved references and obligations have been handled.

6. Keep the obligations that survive closure

A retained redirect remains a production service. Track its certificate expiration, validate its DNS destination, and assign an owner for failures. Keep domain expiration tracking in the portfolio process even if the original application has no remaining users.

Use the portfolio automation workflow for recurring reviews, but carry retirement status and retention rationale into the inventory. A future operator should understand why the domain is still renewed and which event would justify reconsidering that decision.

If observations reveal an unexpected destination or possible loss of control, preserve evidence and use the domain incident response runbook. Do not overwrite the baseline or label a suspicious association as confirmed compromise without investigation.

Close the ticket with the approved manifest, before-and-after observations, authoritative change record, exceptions, owner approval, and resource-release evidence. These records support operational and security review; they do not establish compliance certification. Review access and retention under your organization's evidence policy.

Questions operators ask

Does a failed lookup mean the hostname is safe to release?

No. Authentication problems, timeouts, resolver errors, and missing data can all prevent an observation. Keep the outcome unknown and verify the authoritative configuration. Do not turn an unsuccessful request into a deletion approval.

Does a valid certificate prove we still own the target?

No. Check the provider account and resource identity. Certificate validation addresses the observed TLS endpoint; ownership and authorization require separate evidence.

Should we let the parent domain expire after removing the service?

Make that a separate business and security decision. Review old email addresses, external links, customer expectations, and brand use. Record who will own renewal if you retain it.

Start with one approved retirement ticket and a small inventory. Use the API reference to validate the response shapes, then review pricing against your check frequency and rechecks. Professional plans starting at $6.99/month. Add the gate where your team already approves infrastructure changes, and keep the closure decision accountable.