8 August 2026

Why IP-Based Egress Steering Does Not Scale

Static IP and subnet rules become fragile when SaaS platforms and CDNs move underneath you. Domain-aware egress policy aligns network controls with application intent.

CloudflareNetworkingDNSEgressZero Trust

A very common enterprise requirement is:

Traffic to this application must leave through one of our known public IP addresses.

The reason might be partner allowlisting, legacy source-IP controls, audit requirements or simply an application that still believes network location equals identity.

The traditional answer is to steer traffic based on destination IP address.

That works until the application sits behind a CDN, cloud load balancer or SaaS platform.

Then the network rule starts describing infrastructure rather than intent.

Domain-aware egress steering

The problem with IP-based steering

Imagine an application that needs traffic to leave through a controlled egress address.

If the destination has a stable IP, the policy is simple:

Destination IP
      ↓
Egress policy
      ↓
Fixed public IP

But modern services often do not have one stable IP.

A hostname might resolve to:

The obvious reaction is to keep adding subnets.

That quickly becomes something like:

Allow / steer:
10 provider ranges
20 CDN ranges
several application addresses
plus exceptions

At that point the policy no longer says:

Send this application through controlled egress.

It says:

Send a large set of infrastructure addresses through controlled egress and hope they continue to represent only the application we care about.

That is a fundamentally weaker policy.

The collateral-routing problem

Cloud platforms reuse infrastructure.

If you steer an entire public cloud range because one application happens to use it, unrelated applications can be pulled into the same path.

That can cause:

The network has lost the original business intent.

The better policy primitive is often the hostname

What we actually know is:

app.example.com

That is the application identity the user requested.

A domain-aware system can use DNS resolution as part of the steering decision.

Conceptually:

  1. The client requests a hostname.
  2. The security resolver resolves the hostname.
  3. The platform retains the relationship between hostname and destination.
  4. Traffic is matched to the original hostname/domain context.
  5. The required egress path is selected.
  6. Traffic is forwarded to the real destination.

The exact implementation varies by platform, but the architectural idea is the important part:

Keep enough DNS context to apply network policy using the name the user intended to reach.

Why this is better

A domain-aware egress rule can express:

*.partner.example
        ↓
Controlled egress

instead of:

198.51.100.0/24
203.0.113.0/24
192.0.2.0/24
...and whichever ranges the provider adds next month

The difference is significant.

The first policy describes intent.

The second describes a constantly changing implementation.

DNS becomes part of the control plane

There is an important consequence.

If egress policy depends on hostname context, DNS is no longer just a supporting service.

It becomes part of the policy decision.

That means you need to understand:

This is where a seemingly simple egress feature becomes an architecture decision.

The fake-IP pattern

One implementation pattern is to return a synthetic address to the client.

The security platform keeps a mapping similar to:

Hostname
  app.example.com

Synthetic address
  100.x.x.x

Real destination
  203.0.113.x

When the client connects to the synthetic address, the platform already knows which hostname triggered the connection.

It can therefore apply policy using the hostname and later forward the connection to the real destination.

The advantage is that the network flow retains application context that would otherwise have been lost after DNS resolution.

The migration problem

Enabling this kind of behaviour can affect more than the single application that motivated the change.

That is why migration needs to consider:

Tools expecting real IP addresses

Some scripts and troubleshooting tools assume DNS returns the actual destination.

Private DNS

Internal domains may need to remain on local or dedicated resolvers.

Split tunnelling

Routing and DNS behaviour can interact in ways that are not obvious from the policy UI.

Direct IP connections

A connection made directly to an IP does not necessarily carry the hostname context used for domain-based steering.

A safer rollout pattern

I prefer an incremental rollout:

1. Inventory current resolver behaviour
2. Identify private / fallback domains
3. Validate DNS mode on a small cohort
4. Test key SaaS and CDN-backed applications
5. Validate egress address
6. Test troubleshooting tools and automation
7. Expand gradually

The important part is to test the whole DNS-to-egress path, not just whether the policy saved successfully.

Policy should express intent

The wider lesson is not specific to one Zero Trust platform.

Good network policy should describe what the organisation means.

Whenever possible:

Application identity
Domain
User
Device posture
Service

is preferable to:

A pile of addresses that happen to represent the service today

IP addresses still matter.

But using them as the only application identity in a cloud-first environment creates unnecessary coupling between policy and infrastructure.

That coupling gets more expensive as environments become more dynamic.

All hostnames, networks and examples in this article are synthetic and are included only to explain the design pattern.