DevOps Professional · Module 5: Hybrid networks and hard integrations
DNS, TLS and Proxy Chains: The Request's Full Journey
A request crosses many hands before reaching the backend. DNS resolves, proxies forward, TLS terminates and re-originates, and each link fails differently. Diagnose link by link with per-link evidence instead of blaming the whole chain.
10 min reading
Objectives
- Trace a request through DNS, proxies, TLS termination and backends
- Separate faults per link: name, certificate, proxy, upstream
- Prove each link with its own check before blaming the next
- Keep test certificates and fixture chains out of production trust
Why this matters
HTTPS fails and the team replaces the certificate three times before discovering the proxy serves a stale chain the backends stopped sending months ago. Each replacement cost an outage window and fixed nothing, because nobody isolated the link: resolve the name, check the served chain at each hop, test the upstream directly. Chain failures punish guessing and reward procedure; the L62 lab separates a controlled proxy-plus-cert fault link by link for exactly this discipline.
Concepts
The journey has stations. DNS resolves the name per the client's view (split horizons mean the same name differs inside and out; know which view the failing client uses). Proxies forward with their own TLS to clients and to upstreams, and each proxy logs what it saw: status codes per hop separate proxy errors from upstream errors. TLS terminates at each proxy hop with its own certificate and chain; expiry, hostname mismatch and incomplete chains each produce distinct errors, and the served chain is checked at the hop, not assumed from the file on disk. The upstream answers or not, tested directly to exclude everything before it.
Per-link checks run in order from the client inward. Resolve the name from the failing vantage point. Fetch the served certificate chain at each TLS hop and verify hostname plus expiry plus completeness. Read proxy logs for the hop's status before and after. Dial the upstream directly, bypassing the chain. The first link whose check fails owns the incident until proven otherwise; fix it, re-verify outward, continue.
Test PKI stays quarantined. Fixture certificate authorities and test chains belong in labs with trust stores that never touch production; a test CA trusted by a production client is a breach waiting for a typo. Label every fixture cert with short expiry and lab-only names so leakage announces itself.
Worked example
A fixture chain (client, proxy, backend) stages a stale intermediate at the proxy. The learner checks DNS (fine), pulls the served chain at the proxy (stale intermediate quoted), dials the backend directly (healthy), replaces the chain, and re-verifies hop by hop. Four checks, one fault, no certificate replaced twice.
Common wrong move
Reissuing certificates before isolating the link. Fresh certificates on a proxy serving a stale chain change nothing except the incident's duration. Isolate first, always: name, chain, proxy, upstream, in order.
Quick check
An optional 4-question self-check. Answers never leave your device, are not stored, and never count toward any assessment.
Lesson feedback
No published feedback yet.
Log in and complete the lesson to leave feedback.
Exercise
On a fixture proxy chain with a staged cert fault, run the per-link checks in order, quote the failing link's evidence, fix it, and re-verify outward.
Pass criteria
The record shows each link's check with the failing one quoted, the fix, and the outward re-verification.