Network, DNS and edge security

List the paths the system actually exposes

Include public hostnames, direct IP addresses, load balancers, private connections and remote administration. Record where TLS ends and how the next hop is authenticated. DNS ownership and certificate renewal also need attention because both affect whether the expected service remains reachable and trusted.

Separate ordinary user traffic, management traffic and outbound application traffic. An application may need to contact a payment provider without needing unrestricted egress. Before restricting that access, check the provider’s supported addresses and failover behavior so the required service still works.

Check the origin without going through the proxy

In a fictional deployment, the edge proxy filters requests and applies rate limits, but the origin also has a public address. Requests sent there directly avoid the proxy’s controls. The rule at the edge may be working exactly as configured while the deployment still exposes the application.

Choose an origin restriction that fits the provider and architecture, then test direct denial and successful access through the proxy. Network restrictions, authenticated origin connections and private connectivity are possible approaches. Their suitability depends on current provider behavior, which needs to be checked for the actual deployment.

Retain a result for each route

The matrix records the intended outcome and the observation needed to check it. Keep the evidence at the layer being tested; a failed connection and an application denial do not explain the same behavior.

Keep a way to recover from the change

Before changing management routing, establish how to roll back if access is lost. Test from both outside and inside the network, since the paths can differ. Confirm that health checks, certificate renewal and callbacks still work after the change.

For DNS, compare the authoritative answer with what resolvers return during the transition. A resolver may still hold a cached answer. Record that distinction before treating the old response as evidence that the authoritative change failed.

Report the routes that were tested

A blocked request shows that the tested rule acted on that request along that route. It does not establish that all malicious traffic will be blocked. Application authorization and secure implementation still matter. Use telemetry to investigate false positives and bypasses, and identify protocols, addresses and provider behavior that remain untested.