The resolver, directory and time services every segment must reach now sit behind an inspecting chokepoint, added after one segment was compromised — what does that cost you?

## Why this is the most expensive place in the estate to add a hop A chokepoint in front of a business application costs that application some latency. A chokepoint in front of the universal set costs *everything*, because the services behind it are preconditions rather than destinations: - A host cannot open any connection before it resolves a name. - It cannot authenticate before its clock is close enough to agree. - It cannot authorise before the directory answers. So added milliseconds are not paid once per flow; they are paid before every flow, often several times, and again on each dependent call. This is the compounding cost people underestimate when they draw the diagram. ## Capacity is an aggregate problem A segment boundary is sized for a segment. This hop is sized for the sum of every segment, at their coincident peaks, including the correlated bursts that happen when something else fails and thousands of clients retry at once. When it fills, it queues, and then it drops — and because everything depends on it, the observable symptom is not "the inspection device is degraded", it is "the entire estate is broken and nobody can say why". Design the capacity line from the aggregate and defend it with that number, because it is the number that gets cut in a budget review. ## The fail posture, per service, in writing The worst outcome is a single fail posture applied to all four services because a device only offers one setting. Reason about them separately: | Service | Fail-closed means | Reasonable default | |---|---|---| | Resolution | No host in the estate can start anything | Fail open; the outage is worse than the exposure | | Time | Clocks drift, then authentication fails later | Fail open, with drift alarming | | Directory | New authentications are refused | Fail closed for new sessions is defensible | | Log transport | Records are lost silently | Fail open with client-side buffering | The security point behind the table: an adversary who knows you fail closed on resolution has been handed a cheap estate-wide denial capability — they attack the chokepoint, not the estate. An adversary who knows you fail open knows the control is absent under exactly the conditions they can create. Neither is wrong in the abstract; what is wrong is not having chosen, and not having told the people who own availability which one you chose. ## The circular dependency that ruins recovery Check what the chokepoint itself depends on. If its administrators authenticate against the directory it fronts, or it resolves names through the resolver behind it, then the failure you are designing for is unrecoverable: you cannot log in to fix the thing that is preventing logins. The universal tier and anything guarding it need an out-of-band administration path and credentials that do not traverse the dependency. ## Inspection, specifically If "inspecting" means terminating TLS, you have taken on more than latency: the hop now holds a trust anchor every client accepts, which makes it a high-value target sitting on every flow. Clients that pin certificates or use mutual authentication will break, and the breakage will be attributed to anything but the new hop for the first day. Selecting on the visible handshake instead is cheaper but weaker, and encrypted client hello removes even the name you were selecting on. Decide which you are doing before you promise anyone visibility. ## What the hop actually buys Be honest about yield, because this is what separates a senior answer from a diagram. Every host in the estate is *supposed* to be talking to these services. An intruder in a compromised segment using resolution, the directory and time is producing traffic that is, by design, identical to everyone else's. Content inspection of that stream is a low-yield exercise dressed up as a control. What the position genuinely gives you: 1. **Which segment reaches which service.** Not every segment needs a directory bind. Splitting the universal permit by service is enforcement the hop can actually do. 2. **A place to see the tier's own outbound**, which is low volume and high signal, because the shared services legitimately originate almost nothing. 3. **A single place to change the policy** for a permit that otherwise lives in every segment's rule set — which is a real operational win and also a single place to make an estate-wide mistake. ## And the case where you cannot do it at all In a remote-first estate the shared services are subscriptions. Identity, log ingest and resolution terminate at a provider, at anycast addresses shared with other tenants, over a name set the provider changes without telling you. There is no place to insert a hop, an address-based allow-list cannot distinguish your tenant's endpoint from someone else's on the same infrastructure, and the total-dependency price is paid to a third party rather than to your own device. The chokepoint then has to move to the endpoint or to an identity-aware position, and the honest conclusion is that your enforcement point became authentication rather than reachability. Say that plainly instead of pretending the network diagram still describes the control.