Defeating Egress Allowlists: DNS and Proxy Tunnelling Recipes

How an egress allowlist is built

An egress allowlist answers one question: which destinations may this workload talk to, over which protocols, at what volume? The answer is enforced at the proxy — every flow goes through it, and the proxy matches hostnames against the list — and supported by DNS policy, which pins the resolver and can rewrite or refuse queries. The three components (proxy rules, DNS policy, the list itself) are supposed to describe the same set of permissions.

They never quite do, because each component encodes the list differently. The proxy matches on SNI, Host headers, and IPs; DNS resolves names the proxy rules were written for; the list lives in a config file that drifts from the actual traffic. The mismatches are the seams. A resolver that is reachable but unmonitored answers queries the proxy never sees; a proxy rule that matches '*.trusted-cdn.example' matches every path on that domain, including user-controlled uploads; a permitted destination that itself fetches URLs — a webhook, an image proxy, a CI badge service — becomes a relay that the list author never enumerated.

The classic gaps are all the same bug in different clothes: an allowlist that permits a channel it did not account for. The channel is permitted because it was useful, and it is exploitable because usefulness and controllability were never separated.