ClueDNSSearch

playbook · intermediate

Connect a domain to a website safely

Prepare the destination, change only the required web records, then verify DNS, TLS, redirects, HTTP, CDN, and origin behavior.

Published
Jul 28, 2026
Last verified
Review by
Risk
availability-impacting
Provider
neutral

Connecting a domain to a website changes the path for one or more hostnames. It does not require changing registrar, authoritative provider, email routing, or unrelated records. Prepare the destination first, preserve the current web RRsets, and verify from DNS through the application. DNS delegation separates administrative control of zones from the services their records identify [1].

Blast radius and owners

The blast radius includes every hostname whose A, AAAA, CNAME, or provider alias changes, plus certificate issuance, redirects, CDN routing, origin allowlists, cache behavior, and search-migration signals.

Control point Responsible owner
Authoritative web RRsets and TTLs DNS-zone owner
Provider target and hostname onboarding Web or CDN owner
Certificate issuance and edge deployment Certificate or CDN owner
Redirect, canonical host, and paths Web application owner
Origin routing, firewall, and health Origin owner
Search migration and internal navigation SEO or content owner
Window, verification, and rollback Change owner

Email and registration remain separate unless the approved scope explicitly says otherwise.

Prerequisites

  • approved production hostnames and canonical URL;
  • provider-supplied target values and exact record-type requirements;
  • access to authoritative DNS and the web/CDN service;
  • current web RRsets, TTLs, and application evidence;
  • a prepared destination that recognizes every hostname;
  • a certificate plan for every HTTPS hostname;
  • explicit rollback criteria and owner; and
  • representative URLs and user journeys.

Do not invent record values from an IP observed in a browser or from a provider example.

Inventory and export

Capture:

  • current A, AAAA, CNAME, and provider-specific web state;
  • apex and www behavior;
  • aliases and their independent TTLs;
  • current authoritative answers from every server;
  • selected recursive answers and remaining TTLs;
  • certificate subject names, validity, issuer, and chain;
  • HTTP-to-HTTPS and apex-to-www redirect chains;
  • status, headers, CDN identifiers, origin routing, and health;
  • email, verification, and other records that must not change; and
  • exact prior values for rollback.

The URL includes scheme, hostname, port, path, query, and fragment. Preserve representative exact URLs, not only the apex domain [3].

Preflight

  1. Add or verify every production hostname at the destination without changing public DNS.
  2. Confirm the provider’s exact A, AAAA, CNAME, or other supported target and whether apex handling is provider-specific.
  3. Confirm the destination can serve or obtain a matching certificate.
  4. Verify virtual-host, CDN route, origin, firewall, and health configuration.
  5. Define the intended redirect and canonical behavior for apex, www, HTTP, HTTPS, and representative paths.
  6. If reducing TTL, publish the lower value and wait at least the previous TTL before relying on it.
  7. Verify every authority publishes the same current RRset and reduced TTL.
  8. Review the DNS Lookup pathway and prepare TLS, redirect, and HTTP observations for after the change.

A cached RRset retains the lifetime learned when it was fetched [2].

Stop conditions

Stop before editing DNS if:

  • the provider target is copied from an example or not tied to the account;
  • the destination does not recognize every production hostname;
  • certificate readiness is unknown;
  • IPv4 and IPv6 destinations are not equally prepared where both will publish;
  • current RRsets or TTLs are not captured;
  • authorities already disagree;
  • redirects, origin routing, or health checks fail;
  • email or unrelated records are included in the proposed edit; or
  • the prior web values or rollback owner are unavailable.

During execution, stop after an unexplained DNS, TLS, or HTTP result.

Ordered steps

  1. Confirm the approved change ticket, owner, observers, and rollback threshold.
  2. Make the smallest coherent authoritative edit for one hostname group. Do not combine nameserver, registrar, email, or DNSSEC changes.
  3. Query every authority directly for the intended RRset and TTL.
  4. Observe named recursive resolvers and account for old cached values without describing a global propagation percentage.
  5. Verify the exact hostname against the new endpoint’s certificate. TLS service identity must match the client’s reference hostname [5].
  6. Trace HTTP-to-HTTPS and canonical-host redirects on representative paths.
  7. Check final status, headers, content, CDN, cache, and origin behavior. HTTP’s scheme and authority identify the origin and influence routing [4].
  8. Compare search-migration redirects, canonicals, and internal navigation when the public URL changed.
  9. Restore normal TTLs only after the change is stable and documented.

Verification

Verify:

  1. every authority returns the intended web RRsets;
  2. selected recursive resolvers show explainable old or new cache states;
  3. apex, www, IPv4, and IPv6 follow the approved scope;
  4. certificates validate and cover each exact hostname;
  5. redirects are finite and reach the approved canonical URL;
  6. status, headers, content, CDN, and origin are correct;
  7. important paths, regions, and representative clients work;
  8. email and unrelated DNS records remain unchanged; and
  9. search and navigation signals match the migration plan.

Use HTTPClarity after DNS and the NavSEO pathway after DNS, TLS, and HTTP are correct.

Rollback

Rollback when error rate, certificate failure, redirect loops, gateway errors, or critical user journeys cross the approved threshold.

  1. Restore the captured prior RRset once through the authoritative source of truth.
  2. Verify every authority serves the restored value.
  3. Keep both old and new destinations available for clients with different cached answers.
  4. Recheck TLS, redirects, HTTP, CDN, origin, and representative paths against the prior destination.
  5. Record which resolvers still return the new value and their observed TTLs.
  6. Preserve failure evidence before changing the destination for a later retry.

Rollback does not erase values already cached by resolvers or clients.

Next step

If the web change also requires moving the whole authoritative zone, use Switch authoritative DNS providers safely. If DNS already returns the approved destination but the site fails, use the post-DNS website diagnosis.