← Problem Library
Security L7 SECURITY-1377 · 15 min

A Cilium FQDN policy allows the expected hostname and traffic still fails

The destination is logically correct, yet the enforced DNS identity differs from the hostname operators think they allowed.

SecurityPlatform ReliabilityLevel 7Pro15 min
Scenario

A service mesh or sidecar rollout lands and later an egress policy stops matching destinations that look correct in application config.

What to check first
  • Identify the primary failure signal in the The Policy Named the Destination and the Sidecar Asked for a Different Name Entirely 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

Inspect the actual DNS query path before broadening FQDN policy or adding CIDR exceptions.

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

Community-field security problem inspired by Cilium and Kubernetes discussions where FQDN policy missed a sidecar-rewritten DNS query. FQDN policies operate on real DNS observations, not on the hostname string the application code appears to use.

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

Teams often blame stale DNS caches when the sidecar is rewriting the query into a different observed name.

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

Sidecar-induced name translation should be tested against DNS-observed egress policy enforcement, not just app configuration.