Learning outcomes
- Separate name resolution from cryptographic service authentication.
- Trace public, internal, split-horizon, alias, and failover answers.
- Bind TLS or another endpoint credential to the intended service name.
- Test rebinding, stale cache, wrong endpoint, and direct-origin paths.
Protocol roles
The stub resolver asks recursive and authoritative DNS systems for records. DNS returns addresses or aliases with cache lifetimes. A client connects to an endpoint. TLS or another protocol authenticates the service identity against the intended reference name. Routing and load balancing select a reachable instance.
Message flow
- Trusted application context selects the service name.
- DNS resolution returns an answer through caches and aliases.
- The client connects to one returned endpoint.
- The endpoint presents a certificate or credential.
- The client validates chain, name, time, algorithm, and revocation profile.
- The application sends the request only after endpoint authentication.
Validation and failure cases
DNS resolution alone does not authenticate the endpoint. Test poisoned or stale answers, alias changes, split-horizon differences, search suffixes, rebinding, certificate name mismatch, wildcard scope, failover to an old endpoint, and direct origin access. DNSSEC can protect DNS data authenticity and does not replace TLS service identity.
Design tradeoffs and residual risk
Short DNS lifetimes improve failover and increase query dependency. Internal names reduce public visibility and retain internal compromise risk. Wildcard certificates simplify operations and expand key impact.
Residual risk includes compromised DNS or certificate authorities, endpoint key theft, clients that skip name validation, and application redirects to another authority.
Pomerium boundary
Pomerium uses configured route names and upstream addresses. Operators own DNS publication, certificate names, upstream endpoint authentication, cache and failover behavior, and direct-path isolation. A resolved Pomerium hostname does not authenticate an upstream by itself.
Exercise
Trace one protected hostname through public and internal DNS, aliases, load balancers, Pomerium, and upstream resolution. Capture the intended reference name at each TLS hop. Test stale DNS, wrong address, certificate mismatch, alias failover, and direct origin.
Evaluation checklist
- Which trusted context selects each reference name?
- Which systems resolve, cache, alias, route, and authenticate it?
- Does each TLS client validate the intended name instead of the returned address?
- Do split-horizon and failover answers preserve the same security boundary?
- Can a DNS change create a direct or unprotected path?
Next learning unit
HTTPS and TLS
Explain HTTPS as HTTP over an authenticated, encrypted TLS channel with explicit names, endpoints, and termination boundaries.
