Q: Your microservices on a custom Docker bridge network experience intermittent 5,000ms latency spikes when making external API calls to AWS S3 and payment gateways. Application logs show sporadic `getaddrinfo EAI_AGAIN` or `dns lookup timed out` errors. Direct `curl` commands to external IP addresses respond in 15ms. You must trace the container's DNS resolution path through the embedded Docker DNS server at `127.0.0.11`, identify UDP packet drops and search domain amplification, and implement a resilient DNS configuration.

On user-defined bridge networks, Docker injects an internal DNS server listening at `127.0.0.11:53`. This server intercepts DNS queries: container names are resolved via internal Docker daemon records, while external queries are forwarded to upstream DNS servers listed in the host's `/etc/resolv.conf`.

<!-- Docker DNS Path -->
Container App (getaddrinfo)
  └── Queries: 127.0.0.11:53 (Docker Embedded DNS)
        ├── Matches service name? -> Returns container IP (172.18.0.4)
        └── External domain?      -> Forwards UDP packet to Host DNS (e.g., 8.8.8.8)

Standard Linux glibc resolvers append every domain listed in the `search` directive of `/etc/resolv.conf` if the query contains fewer dots than `ndots` (default is often 5 in container environments). Querying `api.stripe.com` generates redundant queries like `api.stripe.com.default.svc.cluster.local`, causing upstream rate limiting or dropped UDP packets that trigger a 5-second timeout.

# Inspect container resolv.conf
docker exec -it my-app cat /etc/resolv.conf
# Sample output:
# nameserver 127.0.0.11
# options ndots:5

# Trace DNS resolution using dig and tcpdump
docker exec -it my-app dig +trace api.stripe.com

Use `tcpdump` inside the container or on the bridge interface. High-concurrency DNS lookups often trigger a known Linux kernel conntrack race condition where simultaneous A and AAAA DNS queries collide on the same UDP socket.

# Monitor DNS traffic on Docker bridge interface
sudo tcpdump -i br-1a2b3c4d -n "udp port 53" -vv

Fix the issue by specifying reliable upstream DNS servers and passing `single-request-reopen` via `--dns-opt` to force sequential UDP lookups, or lowering `ndots`.

# Docker run with hardened DNS options
docker run -d \
  --name resilient-api \
  --dns 1.1.1.1 \
  --dns 8.8.8.8 \
  --dns-opt ndots:2 \
  --dns-opt single-request-reopen \
  --dns-opt timeout:2 \
  my-api:v1.0

# Or globally in /etc/docker/daemon.json:
# {
#   "dns": ["1.1.1.1", "8.8.8.8"],
#   "dns-opts": ["single-request-reopen", "timeout:2"]
# }