Skip to content
Latchkey

Go "lookup <host>: no such host" (getaddrinfo NXDOMAIN) in CI

A Go client asked DNS for a hostname and got NXDOMAIN: the resolver answered that the name does not exist. Unlike a temporary failure, this is a definitive negative, so retrying will not help; the name or the resolver is wrong.

What this error means

A Go tool (kubectl, terraform, a provider) fails with "dial tcp: lookup <host> on <resolver>: no such host". curl equivalent is "Could not resolve host".

Terminal
Get "https://internal-api.example.com/": dial tcp: lookup internal-api.example.com
on 127.0.0.53:53: no such host

Common causes

The hostname genuinely does not exist

A typo, or a name that was never created, returns NXDOMAIN from the resolver.

The name only resolves on a private DNS

An internal name that resolves on a corporate resolver returns "no such host" when the runner uses a public resolver instead.

How to fix it

Verify the name and the resolver

  1. Look up the name directly to confirm NXDOMAIN.
  2. Check which resolver the runner uses and whether it serves the internal zone.
  3. Fix the hostname, or point the runner at the resolver that knows the name.
Terminal
nslookup internal-api.example.com
cat /etc/resolv.conf

Use the correct private resolver

For internal names, give the container or runner the private DNS server that hosts the zone.

.github/workflows/ci.yml
container:
  image: golang:1.22
  options: --dns 10.0.0.2

How to prevent it

  • Confirm internal names resolve from the runner network before jobs depend on them.
  • Point runners at the private resolver that serves internal zones.
  • Use fully qualified names so a search domain does not produce a phantom NXDOMAIN.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →