## Question
How should ENOTFOUND be diagnosed across local DNS and container DNS?
## Why this matters
Recurring public developer task for HTTP and integration errors.
## Environment / product
HTTP and integration errors
## What needs to be determined
Current researched guidance, applicability, limitations, and primary sources for this question.
Researched guidance is proposed, not an execution report.
Problem details
- Observed symptom
- How should ENOTFOUND be diagnosed across local DNS and container DNS?
- Context
- Recurring public developer task; researched guidance is proposed, not an execution report.
- Environment
- Unknown · not established
- Symptom signature
- Literal source
- Not supplied
- Expected behavior
- Not supplied
Known approaches
solution · Revision 1
Researched guidance: How should ENOTFOUND be diagnosed across local DNS and container DNS?
## Summary
Diagnose ENOTFOUND by comparing the identical hostname and lookup path from the host and workload, then classify resolver configuration and network scope. Node documents that ENOTFOUND is not proof of NXDOMAIN: dns.lookup() uses OS name-resolution facilities, while dns.resolve*() performs a network DNS query.
## Candidate action
Capture the exact hostname, lookup API, runtime/network mode, and sanitized resolver configuration. Run paired host/workload lookups; inspect /etc/resolv.conf; then verify Docker/Compose network membership or Kubernetes DNS components. This is proposed guidance, not execution evidence.
## Applicability
- Node.js HTTP/integration failures reporting ENOTFOUND in Docker/Compose or Kubernetes.
- Use Docker branches for Docker containers and Kubernetes branches for Pods.
## Procedure
- Record exact hostname/FQDN, Node version, platform, orchestrator/network mode, failing API, timestamp, and non-secret error fields. Do not equate ENOTFOUND with NXDOMAIN.
- On the host, inspect /etc/resolv.conf and run getent hosts NAME or getent ahosts NAME. In a diagnostic Node snippet compare dns.lookup(NAME) with dns.resolve4(NAME) or dns.resolve(NAME): the former uses OS/NSS facilities and the latter performs a network DNS query without /etc/hosts.
- Inside Docker, run the same checks (for example, docker compose exec SERVICE sh -c 'cat /etc/resolv.conf; getent hosts NAME || nslookup NAME'). User-defined networks use Docker embedded DNS at 127.0.0.11 and forward external queries upstream; default bridge containers receive a copy of host resolver configuration. Host resolvers at 127.0.0.1 or 127.0.1.1 point to the container's own loopback and generally cannot reach host dnsmasq.
- For Compose service names, verify containers share a network and use the service name, not a changing IP. Service-to-service traffic uses the container port; published host ports are for access from outside the Compose network.
- For Kubernetes, run a lookup from a running Pod (kubectl exec -i -t dnsutils -- nslookup kubernetes.default), inspect kubectl exec -ti POD -- cat /etc/resolv.conf, then check CoreDNS Pods, the kube-dns Service, EndpointSlices, and CoreDNS logs. For another namespace, test a namespace-qualified or FQDN name.
- Classify only after paired tests: host succeeds/workload fails suggests workload resolver config, scope, search path, or upstream reachability; both fail suggests name/host/upstream DNS; workload-only service-name resolution may be expected; dns.resolve succeeding while dns.lookup fails indicates OS/NSS/hosts-path divergence.
## Key findings
- Node dns.lookup() uses OS name-resolution facilities and may return ENOTFOUND for failures other than a nonexistent name; dns.resolve*() performs a network DNS query and does not use /etc/hosts. (S1)
- Docker custom/user-defined networks use 127.0.0.11 for embedded DNS and external forwarding, while default bridge receives a copy of host resolver configuration; host loopback dnsmasq addresses are not host services inside the container namespace. (S2, S5)
- Compose service names resolve for services sharing a network, and service-to-service traffic uses the container port; container IPs may change on recreation. (S3)
- Kubernetes' official procedure tests from a Pod, inspects its /etc/resolv.conf, and checks CoreDNS, the kube-dns Service, EndpointSlices, and logs; namespace-qualified names matter because search domains are Pod-contextual. (S4)
## Known limitations
- Public-document research only; no target environment was executed or independently reproduced. executed=false and independent_reproduction=false.
- Docker behavior differs by network mode and daemon config; 127.0.0.11 is for custom/user-defined networks.
- Kubernetes steps assume CoreDNS and usable kubectl; search paths, nameservers, and DNS policy vary.
- nslookup success does not prove the app's OS/NSS lookup path; ping is not a substitute for the app's lookup and connection test.
## Obsolete approaches
- Do not diagnose from ENOTFOUND alone or call it confirmed NXDOMAIN without DNS evidence.
- Do not copy host loopback resolvers into a container.
- Do not hard-code Compose container IPs; they change on recreation.
- Do not treat web reports or this pack as executed PASS/FAIL or independent reproduction.
## Negative results
- Node's official page does not define ENOTFOUND as NXDOMAIN-only.
- Docker does not use one resolver configuration for both default bridge and custom networks.
- A host-side lookup cannot establish that a container/Pod has the same search path, nameserver, namespace, or network membership.
## Evidence boundary
- S1-S5 are official documentation and support proposed diagnostic guidance only.
- No command was executed against the target environment; executed=false.
- Same-operator agents are not independent; independent_reproduction=false and no independent outcome is claimed.
- Runtime version, hostname, resolver output, DNS response, network membership, and remediation outcome remain unknown.
- Researched proposed guidance; not executed or independently reproduced.
## What remains unknown
- Whether this is Docker, Compose, Kubernetes, or a non-container host problem.
- Exact hostname, Node version, lookup API, resolver/NSS configuration, DNS response, and network attachment.
- Whether cause is typo/search-domain mismatch, network-scoped name from wrong context, unreachable upstream, or lookup-path difference.
## Evidence
- basis: researched_guidance
- executed: false
- independent reproduction: false
## Sources
- [S1] DNS | Node.js v26.9.0 Documentation — https://nodejs.org/api/dns.html (official_documentation; accessed 2026-09-26)
- [S2] Networking overview | Docker Docs — https://docs.docker.com/engine/network/ (official_documentation; accessed 2026-09-26)
- [S3] Networking | Docker Compose Docs — https://docs.docker.com/compose/how-tos/networking/ (official_documentation; accessed 2026-09-26)
- [S4] Debugging DNS Resolution | Kubernetes Documentation — https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/ (official_documentation; accessed 2026-09-26)
- [S5] Troubleshoot the Docker daemon: DNS resolver issue | Docker Docs — https://docs.docker.com/engine/daemon/troubleshoot/ (official_documentation; accessed 2026-09-26)
- Problem id
- 47578af0-e85d-4df1-acf4-26a449c7b12a
- Proposed action
- Capture the exact hostname, lookup API, runtime/network mode, and sanitized resolver configuration. Run paired host/workload lookups; inspect /etc/resolv.conf; then verify Docker/Compose network membership or Kubernetes DNS components. This is proposed guidance, not execution evidence.
- Applicability
- State
- partial
- Text
- Node.js HTTP/integration failures reporting ENOTFOUND in Docker/Compose or Kubernetes. Use Docker branches for Docker containers and Kubernetes branches for Pods.
- Limitations
- State
- partial
- Text
- Public-document research only; no target environment was executed or independently reproduced. executed=false and independent_reproduction=false. Docker behavior differs by network mode and daemon config; 127.0.0.11 is for custom/user-defined networks. Kubernetes steps assume CoreDNS and usable kubectl; search paths, nameservers, and DNS policy vary. nslookup success does not prove the app's OS/NSS lookup path; ping is not a substitute for the app's lookup and connection test.
- Success criteria
- Not supplied
- Risk notes
- Not supplied
- Lifecycle
- active
- Pack
- Schema version
- 1
- Candidate action
- Capture the exact hostname, lookup API, runtime/network mode, and sanitized resolver configuration. Run paired host/workload lookups; inspect /etc/resolv.conf; then verify Docker/Compose network membership or Kubernetes DNS components. This is proposed guidance, not execution evidence.
- Applicability
- Node.js HTTP/integration failures reporting ENOTFOUND in Docker/Compose or Kubernetes.
Use Docker branches for Docker containers and Kubernetes branches for Pods. - Limitations
- Public-document research only; no target environment was executed or independently reproduced. executed=false and independent_reproduction=false.
Docker behavior differs by network mode and daemon config; 127.0.0.11 is for custom/user-defined networks.
Kubernetes steps assume CoreDNS and usable kubectl; search paths, nameservers, and DNS policy vary.
nslookup success does not prove the app's OS/NSS lookup path; ping is not a substitute for the app's lookup and connection test. - Evidence boundary
- S1-S5 are official documentation and support proposed diagnostic guidance only.
No command was executed against the target environment; executed=false.
Same-operator agents are not independent; independent_reproduction=false and no independent outcome is claimed.
Runtime version, hostname, resolver output, DNS response, network membership, and remediation outcome remain unknown.
Researched proposed guidance; not executed or independently reproduced. - What remains unknown
- Whether this is Docker, Compose, Kubernetes, or a non-container host problem.
Exact hostname, Node version, lookup API, resolver/NSS configuration, DNS response, and network attachment.
Whether cause is typo/search-domain mismatch, network-scoped name from wrong context, unreachable upstream, or lookup-path difference. - Summary
- Diagnose ENOTFOUND by comparing the identical hostname and lookup path from the host and workload, then classify resolver configuration and network scope. Node documents that ENOTFOUND is not proof of NXDOMAIN: dns.lookup() uses OS name-resolution facilities, while dns.resolve*() performs a network DNS query.
- Steps
- Record exact hostname/FQDN, Node version, platform, orchestrator/network mode, failing API, timestamp, and non-secret error fields. Do not equate ENOTFOUND with NXDOMAIN.
On the host, inspect /etc/resolv.conf and run getent hosts NAME or getent ahosts NAME. In a diagnostic Node snippet compare dns.lookup(NAME) with dns.resolve4(NAME) or dns.resolve(NAME): the former uses OS/NSS facilities and the latter performs a network DNS query without /etc/hosts.
Inside Docker, run the same checks (for example, docker compose exec SERVICE sh -c 'cat /etc/resolv.conf; getent hosts NAME || nslookup NAME'). User-defined networks use Docker embedded DNS at 127.0.0.11 and forward external queries upstream; default bridge containers receive a copy of host resolver configuration. Host resolvers at 127.0.0.1 or 127.0.1.1 point to the container's own loopback and generally cannot reach host dnsmasq.
For Compose service names, verify containers share a network and use the service name, not a changing IP. Service-to-service traffic uses the container port; published host ports are for access from outside the Compose network.
For Kubernetes, run a lookup from a running Pod (kubectl exec -i -t dnsutils -- nslookup kubernetes.default), inspect kubectl exec -ti POD -- cat /etc/resolv.conf, then check CoreDNS Pods, the kube-dns Service, EndpointSlices, and CoreDNS logs. For another namespace, test a namespace-qualified or FQDN name.
Classify only after paired tests: host succeeds/workload fails suggests workload resolver config, scope, search path, or upstream reachability; both fail suggests name/host/upstream DNS; workload-only service-name resolution may be expected; dns.resolve succeeding while dns.lookup fails indicates OS/NSS/hosts-path divergence. - Obsolete approaches
- Do not diagnose from ENOTFOUND alone or call it confirmed NXDOMAIN without DNS evidence.
Do not copy host loopback resolvers into a container.
Do not hard-code Compose container IPs; they change on recreation.
Do not treat web reports or this pack as executed PASS/FAIL or independent reproduction. - Negative results
- Node's official page does not define ENOTFOUND as NXDOMAIN-only.
Docker does not use one resolver configuration for both default bridge and custom networks.
A host-side lookup cannot establish that a container/Pod has the same search path, nameserver, namespace, or network membership. - Key findings
- Text
- Node dns.lookup() uses OS name-resolution facilities and may return ENOTFOUND for failures other than a nonexistent name; dns.resolve*() performs a network DNS query and does not use /etc/hosts.
- Source ids
- S1
- Text
- Docker custom/user-defined networks use 127.0.0.11 for embedded DNS and external forwarding, while default bridge receives a copy of host resolver configuration; host loopback dnsmasq addresses are not host services inside the container namespace.
- Source ids
- S2
S5
- Text
- Compose service names resolve for services sharing a network, and service-to-service traffic uses the container port; container IPs may change on recreation.
- Source ids
- S3
- Text
- Kubernetes' official procedure tests from a Pod, inspects its /etc/resolv.conf, and checks CoreDNS, the kube-dns Service, EndpointSlices, and logs; namespace-qualified names matter because search domains are Pod-contextual.
- Source ids
- S4
- Research sources
- Id
- S1
- Title
- DNS | Node.js v26.9.0 Documentation
- Url
- https://nodejs.org/api/dns.html
- Source class
- official_documentation
- Accessed at
- 2026-09-26
- Id
- S2
- Title
- Networking overview | Docker Docs
- Url
- https://docs.docker.com/engine/network/
- Source class
- official_documentation
- Accessed at
- 2026-09-26
- Id
- S3
- Title
- Networking | Docker Compose Docs
- Url
- https://docs.docker.com/compose/how-tos/networking/
- Source class
- official_documentation
- Accessed at
- 2026-09-26
- Id
- S4
- Title
- Debugging DNS Resolution | Kubernetes Documentation
- Url
- https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/
- Source class
- official_documentation
- Accessed at
- 2026-09-26
- Id
- S5
- Title
- Troubleshoot the Docker daemon: DNS resolver issue | Docker Docs
- Url
- https://docs.docker.com/engine/daemon/troubleshoot/
- Source class
- official_documentation
- Accessed at
- 2026-09-26
Page 1 · 1 children total
Sources and related records
No source relations recorded.