Stale DNS or certificate settings can keep a control plane trying to serve a hostname that no longer belongs on that path. Requests then bounce into certificate validation, fail repeatedly, and accumulate until an internal timeout clears them. The result is a predictable sawtooth in open file descriptors and worker activity, even though the underlying migration itself was otherwise successful.
Why stale DNS and certificate settings can keep hammering the old path
When traffic is moved behind reverse proxies, the application stack often changes before every dependent cache, hostname, and trust store has fully converged. If a host still resolves to the prior endpoint, or a certificate still names the old service path, clients and intermediaries continue to attempt the obsolete route. That mismatch creates repeat failures instead of a clean cutover.
The important detail is that the failure is not random. DNS TTLs, cached resolver answers, stale certificates, and pinned trust expectations can all keep directing attempts toward a hostname or endpoint that no longer matches the live routing design. Each retry consumes sockets, file descriptors, and worker time, so the system looks busy even though the migration itself may already be correct.
Certificate problems are especially noisy because they fail early and repeatedly. A hostname mismatch, expired leaf certificate, missing intermediate, or trust bundle inconsistency can cause handshake retries and validation loops before the request ever reaches the application layer. In practice, that means a routing change can be operationally successful while the connection path still generates load spikes until every stale reference ages out.
Why the spike pattern often looks like a sawtooth
The recurring spike comes from accumulation and release. Connections or handshakes begin to pile up while the system waits on validation, retry logic, or timeout expiry. Once the timeout clears the backlog, workers and open descriptors drop sharply, only to build again as the stale configuration continues to trigger the same bad path. That produces the sawtooth shape that operators notice in graphs.
This is common when reverse proxies terminate TLS but some clients, health checks, service discovery entries, or backend references still expect the pre-migration certificate or hostname. The proxy may be healthy, yet the control plane and the client path are temporarily out of sync. The result is a recurring connection storm rather than a one-time outage.
Because these symptoms are driven by timing, they can be mistaken for capacity exhaustion, when the actual problem is configuration drift. If the spike cadence aligns with resolver TTLs, handshake retries, or upstream timeouts, that is a strong clue that the environment is repeatedly attempting the wrong destination rather than failing under steady load.
What actually has to be corrected after the cutover
A successful proxy migration is not complete until every hostname, certificate chain, trust anchor, backend reference, and health check reflects the new routing model. DNS records must point to the intended entry point, and the certificate presented on that entry point must match the names that clients still use. If either side is stale, retries can continue long after the traffic move.
This is why certificate lifecycle and DNS change control belong together. Certificates are part of the connection contract, not just a security artifact. For guidance on that lifecycle view, see the Machine Identity, PKI and Certificate Lifecycle Guide. When the migration involves service-to-service paths or workload endpoints, the Guide to SPIFFE and SPIRE is also relevant because it shows how trust bundles and workload identity can reduce certificate drift.
When the issue is broader secret or certificate hygiene after a migration, the Ultimate Guide to NHIs — What are Non-Human Identities helps frame why machine-facing credentials and certificates must be rotated, retired, and tracked as part of the same operational change. On the incident side, the Sisense breach shows how exposed access material and certificate-related trust failures can compound once control of the old path is lost.
Risk and Threat Considerations
Stale DNS and certificate state can keep exposing a deprecated route even after the intended architecture change is complete. The risk is not only failed connections, but also lingering trust in an endpoint that should no longer accept traffic, which can create avoidable retry load, service instability, and a wider window for misrouting.
Failure mechanism: Cached DNS answers, old certificate subjects, or incomplete trust updates cause clients and checks to keep targeting the obsolete path, which repeatedly fails during TLS validation or backend negotiation until timeouts clear the queue.
Impact: Worker saturation, open file descriptor spikes, noisy timeout errors, and prolonged instability that can hide the fact that the proxy migration itself was otherwise correct.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST SP 800-57 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-12 — Cryptographic Key Establishment and Management | Certificate lifecycle and trust material depend on controlled key management. |
| IA-5 — Authenticator Management | Stale certificates and related trust material are authenticators whose lifecycle must be managed. | |
| CM-6 — Configuration Settings | DNS and certificate mismatches are configuration drift problems affecting runtime behaviour. | |
| Recommendation — Track certificate keys and rotation to prevent stale trust material from persisting after cutover. Rotate and retire certificate authenticators promptly when the routing path changes. Baseline and verify DNS and certificate settings after every migration change. | ||
| NIST SP 800-57 | Key Management | The subject materially concerns cryptographic certificate and key lifecycle after migration. |
| Recommendation — Apply key lifecycle discipline so certificates and trust material expire or rotate on schedule. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Stale DNS and certificate settings are a secure-configuration failure after infrastructure change. |
| Recommendation — Harden and validate configuration baselines for DNS and TLS endpoints after cutover. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Certificates and related trust material can keep old access paths alive when they outlive the migration. |
| NHI-01 — Improper Offboarding | The old hostname or certificate path should be retired cleanly when the new proxy takes over. | |
| Recommendation — Shorten certificate and secret lifetimes so stale trust material cannot keep retrying the old path. Revoke and remove deprecated endpoints and credentials as part of migration offboarding. | ||
Practitioner Guidance
What to verify: Confirm that every hostname used by clients, probes, and internal services resolves to the new proxy entry point, and that the certificate presented at that point matches the names still in circulation. Also verify that intermediate certificates, trust bundles, and any pinned certificate expectations were updated together rather than separately.
Common mistake: Treating the proxy cutover as finished once the load balancer or reverse proxy is live. In reality, you need to validate the full request path, including DNS TTL expiry, certificate presentation, and any retry or timeout behaviour that can keep the old route active for hours.
Practitioner takeaway: If the spike recurs on a predictable timer, assume path-state drift first, not capacity failure, and prove that every resolver, certificate chain, and client expectation now points to the same post-migration endpoint.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
