DNS and TLS Failure Modes: A Verification-First Website Launch Runbook

Draft runbook v1.0 — standards and certificate-authority documentation reviewed 2026-08-10. Commands use placeholders and are intended for domains and systems you control or are authorized to test. No client incident, outage duration, or recovery result is reported.

“The SSL is broken” can describe several unrelated failures. The domain may still point to the old host. One authoritative nameserver may disagree with another. IPv4 may reach the new site while IPv6 reaches an old certificate. The correct origin may serve a default virtual host because the TLS handshake did not carry or route the expected name. Certificate issuance may fail even though the current website still loads.

Changing several DNS, CDN, hosting, and certificate settings at once makes those failures harder to isolate. This runbook starts with evidence: define the expected state, query each layer, save the outputs, and change only the layer that disagrees.

It is designed for website owners, developers, and operators coordinating a launch through a managed website, systems engineering, or infrastructure engagement.

Key Findings

1. A browser is an end-to-end symptom check, not a layer diagnosis. It combines recursive DNS, address-family selection, routing, TLS name handling, certificate validation, HTTP redirects, caching, and browser policy. Test those layers separately.
2. Authoritative truth and a recursive resolver's cached answer are different observations. Query the delegated authoritative nameservers directly, then query multiple recursive resolvers. This distinguishes an incorrect source record from a correct record that has not reached every cache.
3. IPv4 and IPv6 are independent delivery paths. A correct A record does not compensate for a stale AAAA record. Test both when both are published.
4. The hostname must be present at several boundaries. DNS must lead to the intended edge/origin, the TLS client must send the intended Server Name Indication (SNI), the served certificate must cover that hostname, and HTTP virtual-host routing must select the intended site.
5. Certificate issuance and certificate serving are separate states. ACME proves control and obtains a certificate. The web server, load balancer, or CDN must still deploy the correct chain and select it for the requested name.
6. CAA controls which certificate authorities may issue; it does not choose which certificate a server presents. An overly restrictive or inherited CAA policy can block issuance while the current certificate continues serving until it expires.

Methodology

Scope and evidence boundary

This is a standards-based operational synthesis, not a benchmark or incident postmortem. The sequence was developed by mapping a website request across these layers:

1. Registrar delegation and DNS zone authority
2. Authoritative resource records
3. Recursive resolver caching
4. IPv4/IPv6 connection target
5. HTTP host and redirect behavior
6. TLS SNI, certificate names, validity dates, issuer, and chain
7. ACME domain-control validation and CAA authorization
8. CDN, proxy, load balancer, and origin routing

The commands below are evidence-collection templates. Replace placeholders only with an authorized domain, expected address, and authoritative nameserver. Preserve raw output with an ISO 8601 timestamp and note the network from which the test ran.

Define the expected state first

Before opening a DNS dashboard, write down the intended result:

domain: www.example.com
apex_domain: example.com
expected_authoritative_nameservers:
  - ns1.provider.example
  - ns2.provider.example
expected_ipv4: [documented address or CDN-managed]
expected_ipv6: [documented address, CDN-managed, or intentionally absent]
expected_canonical_url: https://www.example.com/
expected_tls_names:
  - example.com
  - www.example.com
tls_termination: CDN | load_balancer | origin
certificate_automation: provider-managed | ACME HTTP-01 | ACME DNS-01 | other
change_ticket_or_deployment: identifier
launch_window_timezone: America/New_York

“CDN-managed” still needs a provider hostname or configuration identifier. The purpose is to prevent a troubleshooting session from treating an unfamiliar but intended address as an error.

Failure catalog

Layer	Typical symptom	Verification that isolates it	Avoid assuming
Registrar delegation	Some or all resolvers report an old/empty zone	Compare parent delegation with intended authoritative nameservers	Editing records in an undelegated dashboard will fix production
Authoritative DNS	Direct queries return the wrong A/AAAA/CNAME/CAA answer	Query every authoritative nameserver directly	All authoritative servers agree
Recursive cache	Authoritative answer is correct; public resolvers disagree	Query multiple recursive resolvers and record TTLs	“Propagation” explains a wrong authoritative answer
Address family	Site works on one network/device but fails on another	Test A/IPv4 and AAAA/IPv6 paths independently	IPv6 is unused because the operator did not configure it
TCP/network edge	DNS resolves but port 80/443 cannot be reached	Test connection from more than one authorized vantage point	A certificate change fixes firewall/routing
HTTP virtual host	Correct IP returns a default site, redirect loop, or wrong host	Pin DNS for the request while preserving the Host header	The IP uniquely identifies a website
TLS SNI selection	Wrong/default certificate is presented	Connect to the expected IP with the expected SNI hostname	The same certificate is served for every name on the IP
Certificate identity	Browser reports name mismatch	Inspect Subject Alternative Name coverage	Common Name alone describes modern hostname coverage
Validity or chain	Expired/not-yet-valid/untrusted-chain warning	Inspect dates, issuer, leaf/intermediate chain, and client trust result	Renewal means the new certificate was deployed
ACME HTTP-01	Issuance/renewal validation fails	Fetch the exact challenge path over port 80 through the public route	An HTTPS homepage proves the HTTP challenge is reachable
ACME DNS-01	Issuance cannot see the expected TXT value	Query authoritative _acme-challenge TXT records	Dashboard presence means every authoritative server answers
CAA authorization	CA refuses issuance while DNS and HTTP otherwise work	Query effective CAA at the requested name and relevant parent names	CAA changes which certificate is currently served
CDN/proxy/origin mapping	Edge serves a valid but wrong site/certificate or reports 52x	Compare edge, pinned origin, host mapping, and TLS termination configuration	Origin health and edge configuration are the same state

Verification sequence

Run read-only checks before changing production. Examples show PowerShell commands available on Windows and portable tools commonly available on macOS/Linux or through an operator toolbox.

1. Confirm delegation

PowerShell:

Resolve-DnsName example.com -Type NS

Portable:

dig +trace example.com NS
dig example.com NS

Record the nameservers returned through the parent chain. A zone can contain correct-looking records at a provider that is not actually delegated for the domain.

2. Ask every authoritative server

dig @ns1.provider.example example.com A
dig @ns1.provider.example example.com AAAA
dig @ns1.provider.example www.example.com CNAME
dig @ns1.provider.example example.com CAA

dig @ns2.provider.example example.com A
dig @ns2.provider.example example.com AAAA
dig @ns2.provider.example www.example.com CNAME
dig @ns2.provider.example example.com CAA

Do not skip the second server. A partially updated authoritative set can create location-dependent behavior even before recursive caching is considered. Save answers, flags, TTLs, CNAME chains, and response codes.

On Windows, an explicit server can be queried with:

Resolve-DnsName example.com -Type A -Server ns1.provider.example
Resolve-DnsName example.com -Type AAAA -Server ns1.provider.example
Resolve-DnsName example.com -Type CAA -Server ns1.provider.example

3. Compare recursive resolvers

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com AAAA
dig @8.8.8.8 example.com AAAA

These public resolvers are examples, not a complete global propagation test. Also query the resolver actually used by an affected network. If recursive answers differ from the now-correct authoritative answer, record the remaining TTL and wait/retest according to the change plan. Do not keep editing the authoritative record just to force caches to refresh.

4. Test IPv4 and IPv6 independently

curl -4 -I https://example.com/
curl -6 -I https://example.com/

If AAAA is published, an IPv6 failure is a real failure path. Remove or change it only when that is part of the approved design; first verify whether the CDN, load balancer, or origin is intended to serve IPv6.

5. Pin the intended address without changing DNS

curl -I --resolve example.com:443:<expected-ip> https://example.com/
curl -I --resolve www.example.com:443:<expected-ip> https://www.example.com/

--resolve lets the client connect to a chosen address while retaining the URL hostname for TLS SNI and HTTP Host routing. It is useful for testing a new edge/origin before public DNS changes. It is not a substitute for confirming the actual public DNS answer.

For plain HTTP routing and ACME HTTP-01 diagnostics:

curl -I --resolve example.com:80:<expected-ip> http://example.com/
curl --resolve example.com:80:<expected-ip> \
  http://example.com/.well-known/acme-challenge/<authorized-test-token>

Never publish a real active challenge token in an article, ticket, or public log.

6. Inspect the certificate selected by SNI

openssl s_client \
  -connect <expected-ip>:443 \
  -servername example.com \
  -showcerts </dev/null

To extract the leaf certificate details from a saved PEM file:

openssl x509 -in leaf.pem -noout \
  -subject -issuer -serial -dates -ext subjectAltName

Record:

• Hostname used for SNI
• Connected IP and port
• Subject Alternative Name entries
• Issuer and serial number
• notBefore and notAfter
• Presented intermediates and client verification result

Repeat for the apex and www names if both are public. A certificate covering one does not automatically cover the other.

7. Verify HTTP redirects as a graph

curl -sS -D - -o /dev/null http://example.com/
curl -sS -D - -o /dev/null https://example.com/
curl -sS -D - -o /dev/null http://www.example.com/
curl -sS -D - -o /dev/null https://www.example.com/

Record every Location value and final status. The intended pattern is project-specific, but each public variant should reach the documented canonical URL without a loop, unrelated host, downgrade, or path/query corruption.

8. Isolate ACME validation

For HTTP-01, Let's Encrypt documents that the token is retrieved from http://<domain>/.well-known/acme-challenge/<token> and that the challenge uses port 80. Test the exact public hostname and path. A redirect policy, access rule, proxy, or multi-origin deployment can block the challenge while the homepage still appears healthy.

For DNS-01:

dig @ns1.provider.example _acme-challenge.example.com TXT
dig @ns2.provider.example _acme-challenge.example.com TXT
dig @1.1.1.1 _acme-challenge.example.com TXT

DNS-01 supports wildcard issuance, but the TXT value must be visible through the effective authoritative path. If _acme-challenge is delegated by CNAME or NS, follow and document that delegation rather than editing the wrong zone. Use narrowly scoped DNS API credentials and an automated cleanup policy.

For CAA:

dig example.com CAA
dig www.example.com CAA

CAA records authorize certificate authorities to issue. Effective policy can be found through DNS tree processing defined by the CAA standard, so a record at a parent domain can matter when a child has none. Compare the requested certificate names and CA with the effective policy.

Change discipline

After the evidence identifies a mismatched layer:

1. Save the before-state outputs and current configuration/version.
2. Change one authoritative system under an approved change record.
3. Record the exact time, operator, old value, new value, expected effect, and rollback condition.
4. Re-run the same checks from authoritative DNS through HTTP/TLS.
5. Verify both address families and every public hostname.
6. Keep monitoring after the immediate test passes; cached and geographically distributed paths can update at different times.
7. Save the after-state and label any remaining uncertainty.

Avoid deleting old hosting, certificates, DNS zones, or CDN mappings until the rollback window and evidence-retention policy permit it. A passing homepage from one laptop is not enough to retire the previous path.

Evidence record template

# DNS/TLS change evidence

- Domain/hostnames:
- Authorized scope:
- Expected canonical URL:
- Change/deployment ID:
- Test start/end (timestamp + timezone):
- Test networks/vantage points:
- Authoritative nameservers:
- Expected A/AAAA/CNAME state:
- TLS termination point:
- Certificate automation method:

## Before state

- Delegation output:
- Authoritative outputs from every server:
- Recursive resolver outputs and TTLs:
- IPv4/IPv6 HTTP results:
- Pinned-origin result:
- SNI/certificate result:
- Redirect graph:
- ACME/CAA result:

## Diagnosis

- Failing layer:
- Evidence:
- Alternatives ruled out:
- Uncertainty remaining:

## Change

- Old value/configuration:
- New value/configuration:
- Time applied:
- Rollback condition:

## After state

- Repeat the exact before-state checks
- Monitoring window and owner:
- Final status:

This record gives a customer a readable explanation and gives an engineer enough context to reproduce the diagnosis later.

Limitations

• This runbook is a reference synthesis and has not been benchmarked against every registrar, DNS provider, CA, CDN, load balancer, browser, operating system, or hosting platform.
• DNS behavior can involve DNSSEC, split-horizon/private zones, HTTPS/SVCB records, service discovery, captive portals, enterprise filtering, and provider-specific flattening not covered here.
• Public recursive resolvers provide useful samples but do not represent every network or cache worldwide.
• curl, dig, Resolve-DnsName, and OpenSSL versions differ. Some environments require adjusted syntax or separate installation.
• A successful command from one vantage point does not prove global availability, browser trust across all clients, or future renewal success.
• Certificate trust can vary with client trust stores, algorithms, chain construction, clock accuracy, revocation behavior, and enterprise interception.
• CDN and managed-certificate providers can hide origin or automation details. Use their official logs and diagnostics in addition to these external checks.
• The runbook does not authorize scanning, bypassing access controls, changing third-party systems, or testing domains outside an approved scope.
• It is operational guidance, not a formal security assessment, compliance audit, service-level guarantee, or promise of uninterrupted availability.

What Mendola.Tech adds

Mendola.Tech's original contribution is the launch-focused failure catalog and evidence sequence that connects DNS delegation, authoritative/recursive answers, dual-stack delivery, HTTP routing, TLS SNI and certificate identity, ACME challenges, CAA, and CDN/origin mapping.

The key artifact is not another list of DNS record definitions. It is a verification order with paired commands and an evidence template. A website owner can see which layer failed and what was changed; an operator can reproduce the before/after state without relying on an ambiguous browser screenshot or a generic “wait for propagation” explanation.

See Mendola.Tech's engineering proof and case studies for additional implementation records and the Research Desk for other reproducible methods.

Sources

• RFC 1034: Domain Names — Concepts and Facilities — IETF/RFC Editor; accessed 2026-08-10. Supports the DNS hierarchy, zones, authoritative data, resolvers, and caching model.
• RFC 1035: Domain Names — Implementation and Specification — IETF/RFC Editor; accessed 2026-08-10. Supports DNS message/resource-record behavior and core record/query mechanics.
• RFC 6066: TLS Extensions — IETF/RFC Editor; accessed 2026-08-10. Supports the Server Name Indication extension used to select the intended virtual host/certificate during TLS negotiation.
• RFC 8446: The Transport Layer Security Protocol Version 1.3 — IETF/RFC Editor; accessed 2026-08-10. Supports the TLS handshake and certificate-based server authentication context.
• RFC 8555: Automatic Certificate Management Environment — IETF/RFC Editor; accessed 2026-08-10. Supports automated certificate issuance, identifier authorization, and HTTP/DNS validation challenge concepts.
• RFC 8659: DNS Certification Authority Authorization — IETF/RFC Editor; accessed 2026-08-10. Supports CAA syntax, tree processing, and CA authorization semantics.
• Challenge Types — Let's Encrypt; updated 2026-02-12 and accessed 2026-08-10. Supports current HTTP-01 port/redirect behavior, DNS-01 wildcard/delegation behavior, propagation considerations, and credential-scope cautions.