Follow the Request, One Boundary at a Time

A request map becomes useful when its arrows mean something precise. Drawing a browser, a DNS service, a proxy and an application in a straight line can suggest that page traffic passes through the resolver. It usually does not. A lookup supplies information used to choose a destination; the application exchange follows a separate connection. Confusing those paths sends an investigation toward the wrong component.

Start with a small question: what must succeed for this client to receive this response? Keep the model specific to one route. Record the intended hostname, the resource path, the client location and whether a corporate proxy or VPN participates. A diagram of an imagined universal internet is less helpful than a diagram whose assumptions can be checked.

Name the paths separately

For this explanatory model, a client asks its configured resolver about a service name. It then opens an HTTPS connection to an edge. That edge terminates TLS and sends a separate request to a local application. These are three exchanges with different peers, different failure modes and potentially different timing records.

Name lookup:       client -> configured resolver
Public connection: client -> HTTPS edge
Application hop:   edge   -> local HTTP application

The arrows describe an illustrative deployment, not Nedan's live infrastructure. A resolver can answer from its cache or consult other DNS servers. A client can also use an already cached answer. Do not assume a fresh lookup accompanies every request, or that a resolver's latest answer determines the destination of an existing connection.

Mark the TLS termination point on the map. In this example, the edge receives plaintext HTTP after decrypting the client connection. A second encrypted upstream connection would be a separate design choice, with its own verification rules. The client-facing certificate does not describe the confidentiality of every later hop.

Keep the different names visible

A hostname can appear in DNS, TLS and HTTP, but those appearances serve different purposes. DNS answers help find a destination. TLS uses the client's expected service identity when checking the server. HTTP authority helps the receiver choose the requested site or resource. A shared spelling does not make these checks interchangeable.

Write the expected values beside the relevant boundary. For a test service, the notebook might record a service name of example.com, a selected test address, a certificate matching example.com and an HTTP authority of example.com. If a probe connects by address while changing only the HTTP Host header, its TLS behavior can differ from a normal hostname request.

Prefer a probe that preserves the intended service name throughout the request. A controlled address override can narrow the lookup question while leaving the hostname in the URL. The TLS identity note explains that technique and the limits of what it establishes.

Add observations to the model

For each boundary, record an observation rather than an adjective such as healthy. A lookup result includes the queried name, type, resolver and time. A connection result includes the selected peer and transport. A TLS result includes the expected name, verification outcome and negotiated protocol. An HTTP result includes the status, selected resource and relevant response metadata.

Those observations support different claims. Receiving an address does not establish that the address is reachable. Completing TLS does not establish that a database query works. Receiving a successful health response does not establish that every article or API route behaves correctly. Attach each claim to the smallest observation that actually supports it.

Keep failed attempts too. A successful IPv4 connection does not explain a preceding IPv6 timeout. A second request can reuse a connection and look faster for that reason. Record the client command and relevant environment so a comparison does not silently change the path under examination.

Treat connections and requests differently

One connection can carry several HTTP requests. In a proxy deployment, the public and upstream connections also have separate lifetimes. The edge might reuse an upstream connection even when the visitor opens a new public connection. Counting requests as if each one performed a complete lookup and handshake gives misleading latency estimates.

The transport is another explicit assumption. HTTP/1.1 and HTTP/2 commonly use TCP with TLS for HTTPS. HTTP/3 uses QUIC. A TCP-only diagram is therefore a model of a selected route, not a description of every HTTPS exchange. State which protocol the probe actually negotiated before interpreting a connection failure.

For a first investigation, reduce the variables deliberately. Use one client, one hostname and one read-only resource. Keep the command bounded. Then change one assumption at a time: resolver selection, address override, protocol choice or direct access to a permitted local application listener.

Compare routes without bypassing policy

A local application response can help distinguish an application failure from an edge failure. That check belongs on the host or in the intended private network. Opening the application port to the internet merely to obtain a convenient diagnostic result changes the security boundary and invalidates the map.

Similarly, keep certificate verification enabled during the public probe. A response obtained after disabling an identity check is evidence about a different request. Write the result as such instead of promoting it to proof that the normal HTTPS route works.

Finish the notebook with the narrow conclusion: which boundary failed, what observation supports that conclusion and which boundaries remain untested. The next probe should resolve one of those open questions. A request map is a working explanation that improves with evidence, not an inventory that claims certainty about unseen systems.

References and next steps

Protocol background: DNS concepts in RFC 1034 and HTTP/3 in RFC 9114. The request-map procedure and example above are editorial models.

Continue with DNS cache boundaries, proxy trust or the bounded timeout method.