← Problem Library
Security L7 SECURITY-1357 · 15 min

A Cilium FQDN policy allows a hostname and still blocks traffic

The allowlist seems correct, yet egress fails because the actual query path on the wire differs from the app-configured hostname.

SecurityPlatform ReliabilityLevel 7Pro15 min
Scenario

A service mesh sidecar is added and later only FQDN-based egress policy starts failing for one dependency path.

What to check first
  • Identify the primary failure signal in the The Policy Allowed the Name in Config and the Sidecar Asked for Another Name First 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

Observe real DNS queries from the workload stack before broadening the FQDN allowlist.

Questions worth viewing together
What should you verify first when A Cilium FQDN policy allows a 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 is only as correct as the DNS query that actually leaves the workload path.

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

Teams often blame stale DNS cache when the policy never saw the same name the application config used.

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

FQDN policies should be validated against sidecar or mesh DNS rewrite behavior, not only app config.