← Problem Library
Security L6 SECURITY-1367 · 14 min

A Cilium FQDN policy allows the configured hostname and still blocks traffic because a sidecar rewrites DNS search paths and the cached query name no longer matches the app config

The policy looks right, yet the actual wire query differs from the configured hostname after the sidecar or mesh rewrites the request.

SecurityPlatform ReliabilityLevel 6Pro14 min
Scenario

A service mesh is enabled and only name-based egress policy begins failing for one dependency path.

What to check first
  • Identify the primary failure signal in the The Policy Allowed the App Config Name and the Sidecar Asked the Network for Another One scenario.
  • Separate visible symptoms from the underlying technical dependency.
  • Describe the safest recovery path and the follow-up prevention work.
Checking checklist
  1. Summarize the current impact and the last known change.
  2. Collect direct evidence from logs, runtime state, and configuration before changing anything.
  3. Separate immediate recovery from permanent prevention work.
Recovery and prevention

Capture the actual DNS queries leaving the workload stack before broadening the FQDN allowlist.

Questions worth viewing together
What should you verify first when A Cilium FQDN policy allows the configured hostname and still blocks traffic appears?

Community-field security problem inspired by Cilium community patterns where sidecar DNS rewriting broke FQDN-based egress policy. Name-based policy can fail when the app name and the wire query diverge under sidecar DNS behavior.

What usually causes A Cilium FQDN policy allows the configured hostname and still blocks traffic in production?

Teams often blame stale cache when the policy never saw the same name the app referenced.

What should you document after resolving A Cilium FQDN policy allows the configured hostname and still blocks traffic?

FQDN allowlists should be validated against sidecar or service-mesh DNS rewriting, not just app config.