Summary

  • RFC 3568 describes DNS, transport-layer and application-layer request routing known on or before December 2000. Each deeper layer sees more of the client and object, but incurs more state, latency, interception and security authority.
  • “Best surrogate” is not a property of a server. It is a time-bound result of the observer, visible requester, candidate set, metric direction and age, policy weights and handoff mechanism. The decision needs receipts through actual delivery and application outcome.

The first lie in server selection is grammatical. “The best surrogate” sounds like a thing waiting to be discovered. In practice it is the output of a function whose inputs are incomplete and whose observer may be standing in the wrong place.

RFC 3568 is unusually useful because it does not hide that incompleteness. Published in July 2003 as an Informational survey, it summarizes industry techniques known and used on or before December 2000. It groups them into DNS, transport-layer and application-layer request routing. The three families are not merely alternative implementations. They are three different views of who is asking, what is being requested and what the selector is authorized to inspect.

DNS chooses from a borrowed identity

A specialized DNS server can vary A, NS or CNAME answers according to policy and measurements. A single answer can name one surrogate or a virtual address for a selected set. Multiple A records can invite a client-site resolver to cycle through options. NS and CNAME indirection can distribute a choice across several specialized decision servers.

But the DNS selector does not normally receive the client's address. It sees the client-site DNS server. If recursion occurs upstream, it may see only the address of another DNS server asking on that resolver's behalf. The observable requester has changed twice before the selection begins.

This is not a minor geolocation error. It changes the object of optimization. Round-trip time measured to a resolver is evidence about the path to that resolver. It is not evidence about the path from a surrogate to every client using it. Users behind one shared resolver also receive the same address set during the TTL interval. A choice that looked balanced at decision time can concentrate a flash crowd on one surrogate.

The receipt therefore needs two identities: the client identity available at the delivery layer and the resolver identity actually exposed to the decision layer. If recursion hides the client-site resolver, preserve the visible recursive hop too. “Nearest” without a nearest_to field is not an operational claim.

TTL is the lifetime of an old answer

Short DNS TTLs let a system respond more quickly to outages or load changes. They also increase query volume. Some implementations may not honor the advertised TTL. Within a cache interval, one decision can outlive the measurements and candidate health that produced it.

That makes TTL a governance parameter, not just a cache setting. It determines how long the selector's authority persists without reconsideration. The decision record should join the answer to the metric timestamp, candidate set, policy version, cache scope and expiry. Without that chain, operators can show that an answer was syntactically valid while being unable to show that it was still sensible when a client used it.

Multi-level resolution adds more clocks. NS redirection can let the last DNS server influence the TTL of the resolution process and can create exceptional timeouts. CNAME redirection moves the query into a new domain and adds another lookup. Each handoff can refine the choice, but each also introduces a cache, authority and latency boundary that must be visible in the trace.

Anycast finds a decision point, not the delivery answer

RFC 3568 describes advertising one anycast address from several request-routing DNS servers. Routing delivers the query to the DNS instance closest, in routing terms, to the client-site resolver. That can be a useful way to reach a decision point.

It does not establish that the selected DNS server is closest to the actual client. Routing protocols are not ordinarily load-sensitive. Routing-nearest need not mean least latency. The DNS server's own load may not be considered. Anycast has answered “which selector received this query?” before the content system has answered “which delivery node should serve this object?”

Conflating those steps creates a convenient but false end-to-end narrative. Keep the anycast route and receiving selector separate from the candidate evaluation and final surrogate choice.

DNS sees names, not objects

DNS naturally operates at domain granularity. A content system may encode an object type, object hash or identifier into a name so the selector can make a finer decision. The cost is more names and potentially several resolutions for one page. Granularity has been purchased with extra work and latency.

The alternative is to wait for a deeper layer. Transport inspection can expose client IP address, port and protocol from the first packet. That corrects part of the identity problem and can refine a coarse DNS choice. Yet the forward flow may continue through the surrogate selected first, while the larger reverse flow takes a direct path from the new delivery node. One session can therefore have different decision, forward and return topologies.

A latency number without direction is unusable here. So is a handoff record that names the new surrogate but omits whether it accepted the flow and which path actually carried the response.

Application visibility is bought with authority

At the application layer, the selector can see the requested object, URL, headers, cookies, language or user-agent. It can send a redirect, parse traffic in an in-path element, splice a connection or rewrite embedded URLs. This is the first family that can plausibly make an object-specific choice from object-specific evidence.

Every gain has a price. A 302-style redirect adds a round trip and depends on the client following it. An in-path element adds URL parsing and connection state to the traffic path. URL rewriting leaves the first request at the origin and can embed a choice in a page long after the underlying surrogate has changed. RFC 3568 warns that rewritten pages should be non-cacheable or short-lived because stale URLs can point to unavailable or no-longer-suitable nodes.

TLS draws the authority line sharply. The content network cannot see the full URL unless it terminates the TLS session. More visibility is not a free improvement in optimization; it is a transfer of cryptographic trust, certificate responsibility and access to request contents. A useful design review must ask not only what the selector can see, but why it is entitled to see it.

Measurements describe their vantage point

The RFC lists latency, hop count, BGP information, surrogate load and content availability among possible inputs. It defines proximity in its discussion as round-trip time, while noting that DNS systems commonly measure to the local resolver. It also observes that some measurements cover only one direction and that Internet paths can be asymmetric.

Active probing adds another gap. Probes are periodic, firewalls and NATs can block them, and they may trigger intrusion-detection alarms. A missing reply can mean policy rather than distance. HTTP probes to surrogates struggle to produce real-time load data; aged feedback may be inaccurate. Even BGP AS path, the document cautions, can be meaningless as a good selection metric.

Store a metric as a statement with six qualifiers: source, target, method, direction, timestamp and failure semantics. Then preserve the raw value and age used by the policy. Without those fields, a dashboard turns incomparable observations into a confident rank.

The receipt graph for “best”

A defensible selection starts with the request identity actually visible at that layer. It records the DNS resolver and recursive chain, query or object, candidates and exclusions. Each measurement carries its vantage point and freshness. The policy record supplies version, hard constraints, weights and tie-break. The selection record names the chosen surrogate and expiry.

Then the evidence must continue. Record the DNS answer, redirect, rewrite, interception or transport handoff. Record TLS termination and modification authority. Record whether the surrogate accepted the request, had the object, what load it experienced at service time, which path carried the response, and whether the application completed or retried.

No earlier receipt may impersonate a later one. DNS return is not client arrival. A redirect is not follow-through. A rewritten URL is not object delivery. A selected node is not an accepted request. HTTP completion is not the user's intended outcome.

Evidence boundary

This Article identifies no CDN, operator, resolver, client, surrogate, origin, vendor, session, incident, measured latency, cache hit, outage or performance result. RFC 3568 is an Informational survey of mechanisms used or known by the end of 2000, not a standard and not evidence of a present deployment.

RFC 3466 supplies contemporaneous content-internetworking vocabulary. RFC 3238 sets architectural considerations for intermediaries. RFC 2782, RFC 1546, RFC 1034, RFC 1035 and RFC 2181 provide DNS and anycast context; RFC 3272, RFC 2386 and RFC 3221 provide routing and traffic-engineering context. RFC 7336 and RFC 8008 are later CDNI context only and are not projected backward.

Heng Lu's Running-Code Primacy and Minimum Initial Specification essays are disclosed editorial lenses. They motivate testing the running delivery chain rather than granting a selection record authority over later layers, and keeping the common handoff contract smaller than local operating policy. They are not evidence of the RFC authors' intent or of a deployment outcome.

The bounded conclusion is simple: a request router can only choose from what its observer sees. “Best” becomes meaningful when the record names for whom, for what object, among which candidates, by which measures, at what time and with what verified delivery result.

Sources