🚨 OpenTelemetry Error Guide: 'dial tcp: lookup otel-collector: no such host' — Fix OTLP DNS Resolution

Overview

The OTLP exporter must resolve the Collector’s hostname to an IP before it can connect. When DNS resolution fails, the exporter logs a no such host error and retries forever:

Exporting failed. Will retry the request after interval.
error: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing: dial tcp: lookup otel-collector on 10.96.0.10:53: no such host"

The HTTP exporter surfaces the same underlying failure:

traces export: Post "http://otel-collector:4318/v1/traces": dial tcp: lookup otel-collector: no such host

No telemetry leaves the process because the connection never gets past name resolution.

Symptoms

• Exporter retries indefinitely with no such host or lookup ... on <resolver>:53.
• The Collector is running and healthy, but senders can’t reach it.
• Works in one namespace but not another, or works by IP but not by name.
• Started after a rename, namespace move, or switch to a headless Service.
• Other pods in the same namespace also fail to resolve the name.

Common Root Causes

• Wrong hostname — typo, or using the Service short name from a different namespace.
• Missing namespace suffix — cross-namespace calls need svc.<namespace> (e.g. otel-collector.observability.svc.cluster.local).
• Service doesn’t exist / wrong name — the Collector Service is named differently than the exporter expects.
• Headless Service quirks — a clusterIP: None Service resolves to pod IPs; the exporter needs a stable name or the right per-pod DNS.
• CoreDNS failure — DNS itself is down, misconfigured, or the pod’s resolv.conf search domains are wrong.
• Scheme/port confusion — putting a URL where a host:port is expected, so the “host” includes a slash or scheme.

Diagnostic Workflow

Confirm the exact endpoint the exporter is using and that it is a resolvable host, not a malformed URL:

exporters:
  otlp:
    # Use the fully qualified Service name when crossing namespaces
    endpoint: otel-collector.observability.svc.cluster.local:4317
    tls:
      insecure: true

For SDK exporters, verify the environment variables and that the protocol matches the port:

env | grep OTEL_EXPORTER_OTLP
# grpc -> :4317, http/protobuf -> :4318 with /v1/traces path
export OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector.observability.svc.cluster.local:4318

Resolve the name from inside the sending pod to reproduce the failure:

kubectl exec deploy/my-app -- nslookup otel-collector.observability.svc.cluster.local
kubectl exec deploy/my-app -- getent hosts otel-collector.observability
kubectl get svc -n observability otel-collector -o wide

If resolution fails cluster-wide, check CoreDNS and the pod resolver:

kubectl -n kube-system get pods -l k8s-app=kube-dns
kubectl -n kube-system logs deploy/coredns --tail=50
kubectl exec deploy/my-app -- cat /etc/resolv.conf

Example Root Cause Analysis

A team split their apps into a new payments namespace while the Collector stayed in observability. Apps kept the exporter endpoint otel-collector:4317, which had worked when everything shared a namespace. After the move, every app logged lookup otel-collector: no such host, because the short name only resolves within the Collector’s own namespace.

nslookup otel-collector.observability.svc.cluster.local from a payments pod succeeded, confirming the fully qualified name resolved fine. Updating the exporter endpoint to the FQDN fixed all senders at once. The team standardized on fully qualified Service names in their config template so future namespace moves wouldn’t reintroduce the failure.

Prevention Best Practices

• Use fully qualified Service names (<svc>.<namespace>.svc.cluster.local) in exporter endpoints so resolution doesn’t depend on the caller’s namespace.
• Keep protocol and port aligned (grpc:4317, http/protobuf:4318) and never put a scheme or path in a host:port field.
• Templatize the Collector endpoint across services so a rename updates in one place, not dozens.
• Monitor CoreDNS health and alert on resolution failures; DNS outages break exporters silently.
• Add a startup connectivity check that resolves and dials the Collector before serving traffic.

Quick Command Reference

# Resolve the Collector name from the sending pod
kubectl exec deploy/my-app -- nslookup otel-collector.observability.svc.cluster.local

# Confirm the Service exists and its ports
kubectl get svc -n observability otel-collector -o wide

# Check the pod's DNS resolver config
kubectl exec deploy/my-app -- cat /etc/resolv.conf

# Inspect CoreDNS
kubectl -n kube-system logs deploy/coredns --tail=50

Conclusion

no such host is a DNS resolution failure, not a Collector outage: the exporter can’t turn the endpoint name into an IP. Almost always the fix is the hostname itself — use a fully qualified Service name with the correct namespace, keep protocol and port consistent, and verify CoreDNS is healthy. Standardizing on FQDN endpoints across the fleet makes exporters resilient to namespace and naming changes.