DNS, TLS, Reverse Proxy and HSTS

1. The problem: “HTTPS opens” is not layered evidence

A web request crosses independent layers: the DNS name and answer, the resolved endpoint, TLS transport, certificate/name identity, reverse-proxy routing, the selected upstream, and HSTS policy. A request can return 200 while reaching the wrong upstream, or DNS can resolve correctly while the certificate identity is wrong.

The owned artifact is Edge Request Trust Path Record v1. It records observation, inference, unknowns, and recovery evidence separately instead of collapsing them into one vague verdict.

2. DNS answers “where,” not “who”

DNS maps names to records such as addresses. A resolver may obtain data from cache or from name servers. Successful resolution proves that a DNS answer was obtained for the name; it does not prove TLS server identity, application health, or application authorization.

Record the hostname, answer, and resolved endpoint first. Evaluate TLS independently afterward.

3. TTL is a time boundary on cached data

TTL limits how long an RR can remain cached; it is not permanent identity evidence. If TTL has expired or the fixture shows that the authoritative answer changed, the old cached conclusion must not be carried forward without re-resolution.

One lab case contains an old cached answer and a changed authoritative answer. The correct diagnosis is that DNS evidence requires re-query, not that TLS or the proxy is automatically at fault.

4. TLS 1.3 has a current specification

At lesson publication time, RFC 9846 is the current IETF TLS 1.3 specification and obsoletes RFC 8446. TLS establishes protected transport between endpoints, but it does not by itself decide every application-authorization or application-correctness question.

Record the TLS version and transport result without turning them into an application-level verdict.

5. Transport success is not the same as server identity

A synthetic handshake can be transport-successful while the expected server name does not match the supplied certificate-name evidence. TLS_CONNECTED and SERVER_IDENTITY_MATCH are therefore distinct conclusions.

In the mismatch case, DNS resolution succeeds and TLS transport is available, but identity must remain mismatched. This rejects the shortcut “DNS and TLS are green, therefore the endpoint is correct.”

6. SNI and the expected name are part of connection context

For multi-name services, the name presented in connection context influences certificate selection and identity checks. This lesson records SNI and certificate-name evidence as fixture facts; it does not teach CA operation or public PKI issuance.

Every identity conclusion must stay tied to the expected name and the evidence for that connection.

7. A reverse proxy is a routing boundary

In NGINX, proxy_pass is a concrete mechanism for forwarding requests to an upstream, and URI/path/header behavior depends on configuration. TLS success therefore says nothing about whether /api was routed to the intended upstream.

Keep the incoming Host/Path and the selected upstream in the same evidence row.

8. A 200 from the wrong upstream is still a failure

Suppose /api/orders should reach orders-service, but a bad rule sends it to admin-service, which also returns 200. A status-only check hides the failure.

The lab includes exactly this case. The proxy-route state must be a mismatch even though transport and HTTP status appear successful.

9. Do not confuse forwarded context with route proof

A proxy can modify or add Host and forwarding headers. The presence of a header alone is not route proof; configuration intent and observed upstream evidence must be compared.

The lesson treats headers only as bounded fixture evidence and does not claim one universal reverse-proxy policy.

10. HSTS is a UA/server policy received over secure transport

RFC 6797 defines HSTS through the Strict-Transport-Security response header and the associated user-agent policy. The header is processed as HSTS policy when received over secure transport.

Seeing the same header on insecure HTTP is not equivalent to establishing HSTS policy. The lab tests this as a separate failure probe.

11. HSTS does not replace TLS validation or application security

HSTS can constrain a user agent to secure transport for a known HSTS host. It does not generally solve phishing, malware, a wrong proxy route, invalid server identity, or application authorization.

Record HSTS as one layer state, not as a global security verdict.

12. Separate observation, inference, and unknowns

DNS answer = 192.0.2.10 is an observation. This is the intended service endpoint may be an inference. TLS identity has not yet been checked is a valid unknown.

Edge Request Trust Path Record keeps these categories separate so a local success cannot silently expand into an unsupported claim.

13. Recovery must re-prove the failed layer

If TTL is expired, re-querying and comparing the answer is recovery evidence. For a certificate-name mismatch, repair the fixture identity and rerun that identity check. For a proxy-route mismatch, correct the route and observe the selected upstream again.

A generic restart, indiscriminate cache clearing, or simultaneous changes to several layers are not strong recovery proof.

14. Lab and transfer

The lab is fully offline and synthetic. Eight local fixtures carry hostname, DNS answer/TTL, TLS version, certificate-name evidence, path/upstream mapping, response state, and HSTS transport. No public DNS, certificate authority, production host, credential, or external network request is used.

The transfer case changes the hostname, TTL, TLS name, proxy path, and upstream mapping. All eight states must be recomputed from changed evidence; baseline verdicts cannot be copied.

15. Sources, freshness, and claim boundaries

This package uses RFC 1034/1035 only for foundational DNS and cache/TTL concepts, RFC 9846 for current TLS 1.3 status and transport scope, RFC 6797 for HSTS, and the official NGINX proxy module documentation for proxy_pass behavior. NGINX is not presented as the only reverse proxy, and the original DNS RFCs are not presented as covering every modern DNS extension.

The volatile NGINX source is due for re-review on 2026-10-17, with earlier requalification required after material documentation or fixture changes.