DNS, HTTP, and TLS answer different questions

Prerequisites: IP addressing, TCP, request-response protocols, and basic cryptography.

Learning objectives

• Explain recursive resolution and DNS caching.
• Distinguish TLS endpoint authentication from application authorization.
• Interpret HTTP method semantics and retry boundaries.

A web request involves several naming and communication contracts. DNS maps names to records, potentially including addresses. A transport connects endpoints. TLS authenticates an endpoint according to configured trust and protects data in transit. HTTP gives requests and responses meanings such as methods, status codes, and representations. Application authorization decides whether the authenticated user may perform a particular action. Success at one layer does not prove success at the next.

A client commonly asks a recursive resolver for a hostname's address. The resolver may answer from cache or follow referrals through the DNS hierarchy to authoritative servers. Cached records have time-to-live values that limit reuse under the protocol's rules. Changing an authoritative record does not instantly invalidate every cached answer. A hostname can also return several addresses, and different clients may see different appropriate answers.

For a simplified HTTPS request over TCP, the client resolves the name, connects to a selected address, negotiates TLS, then sends an HTTP request. The TLS client checks the server's certificate chain and expected hostname according to its trust configuration. Encrypting a connection to an unverified endpoint does not establish that the endpoint is the intended site. HTTP/3 uses QUIC rather than TCP, so this trace must not be presented as every HTTPS connection's transport sequence.

TLS protects the channel between its termination points. If a reverse proxy terminates TLS and forwards plaintext internally, that second link has its own protection requirements. TLS also does not prevent the server from returning malicious application content, authorize a user, or make stored data encrypted automatically. Certificate validation and application session checks answer different questions.

HTTP methods carry semantics. GET is defined as safe: the client is requesting retrieval rather than a state-changing action. Idempotence means repeating an identical request has the same intended effect as performing it once, not that every response body or status code is identical. PUT and DELETE have idempotent semantics; POST is not generally idempotent. An application can add explicit idempotency mechanisms for particular POST operations. A retry must respect what the actual endpoint implements.

Consider a profile update followed by a timeout. DNS resolution may have succeeded, TLS may be valid, and the server may have committed the update while the response vanished. None of those lower-layer observations resolves the operation's outcome. A stored request identifier and result lookup can. Similarly, an HTTP 200 response can contain an application-level error if the API is poorly designed; inspect the documented contract.

When diagnosing failures, record the hostname, resolved address, TLS identity, HTTP status, request identifier, and application result at their respective boundaries. Keep secrets out of logs. The goal is a falsifiable trace of responsibility, not a single vague label such as network error.

Practice problem

A deployment changes api.example’s address, but some clients still reach the previous server. Explain one valid DNS reason. A client then receives a valid TLS certificate but an HTTP 403 response. Explain why those observations are compatible. Finally, a POST creating a job times out after transmission; describe a retry design that prevents two jobs without assuming TCP or TLS can provide that business guarantee.

Worked solution

Clients or resolvers may still hold a previously cached DNS answer whose lifetime has not expired. A valid certificate establishes the server identity under the client’s trust checks; HTTP 403 can still mean the application refuses the requested action because the user lacks permission. For job creation, the client supplies a stable request key and the server atomically stores that key with the created job and response. A repeat with the same key and same request returns the existing result, while conflicting payload reuse is rejected. This requires durable, correctly scoped deduplication and an explicit retention policy, not merely an encrypted reliable connection.

Check your understanding

TLS certificate validation succeeds, but the server returns 403 for a user’s request. Which explanation is consistent?

• The encrypted channel guarantees the requested state change committed.
• A403 necessarily means DNS resolved the wrong address.
• The server identity was verified, but application authorization refused the action.
• TLS proved the user had permission, so the response is impossible.

Explanation

Server authentication, user authorization, and operation execution are different protocol responsibilities.

DELETE succeeds once and a repeated identical DELETE returns a different status because the resource is already absent. Can the endpoint still have idempotent semantics?

• Only if the client uses a new resource identifier each time.
• Yes, the intended effect remains the resource’s absence.
• No, idempotence applies only to read operations.
• No, all response bytes must match.

Explanation

Idempotence concerns intended state effect, not necessarily identical responses across repetitions.

Primary reading

• Domain Names: Concepts and Facilities, RFC 1034: IETF / RFC Editor
• HTTP Semantics, RFC 9110: IETF / RFC Editor
• TLS 1.3, RFC 8446: IETF / RFC Editor

Open the study and save your work →