mediumFoundationSymptom-first#dns#search-domain#resolv.conf#ndots#fqdn

Short hostname fails to resolve while FQDN works -- missing search domain or ndots issue

ping app-server works but ping app-server.internal does not (or vice versa)

Likely source:configuration

Focused incident mode — strips away everything but this runbook.

Symptoms

  • ping app-server works but ping app-server.internal does not (or vice versa)
  • curl http://myapi returns 'Could not resolve host' but curl http://myapi.corp.local works
  • getaddrinfo returns EAI_NONAME for short names inside containers

Evidence to grab

Collect these artifacts before you change anything — they prove (or rule out) each cause.

  • Search domains in resolv.conf

    cat /etc/resolv.conf

  • ndots setting

    grep ndots /etc/resolv.conf

Diagnostic flow

Run the steps in order, marking each claim confirmed or refuted. The evidence you gather feeds the ranked causes below.

Guided decision tree is ready.

Steps with commands, expected output, and pass/fail branches.

Ranked root causes

Evidence checklist

  • resolv.conf has no 'search' or 'domain' line
  • Short name queries go directly to the root hints

Confirm before fixing

cat /etc/resolv.conf | grep -E 'search|domain'
READ

Check for search/domain entries

Fix

echo 'search corp.local internal' >> /etc/resolv.conf
CHANGE

Add the required search domains to resolv.conf

Resolution runbook

Apply from top to bottom after the cause is confirmed. Review every command before running it — risk tags are shown on each.

1
cat /etc/resolv.conf
READ

Read the current resolver config

2
dig <short-name> +short
READ

Test the failing short name

3
dig <short-name>.<search-domain> +short
READ

Test with the search domain appended

4
echo 'search <domain>' >> /etc/resolv.conf
CHANGE

Add the missing search domain

Prevention

  • Always include the full search path in /etc/resolv.conf or DHCP configuration.
  • In Kubernetes, set ndots:2 and use FQDNs in application configuration.
  • Document internal DNS suffixes in the runbook so new services get the right resolv.conf.
  • Test DNS resolution in CI with both short and FQDN names.

Related runbooks

Same stack, same failure family — worth a skim.

DNS returns NXDOMAIN for a record that exists -- stale resolver or propagation delayhigh

dig/nslookup returns NXDOMAIN for a domain that was recently updated

NetworkingIntermediate3 causes
Open runbook
DNS resolution failing inside pods — CoreDNS issuescritical

curl: Could not resolve host inside pods

KubernetesIntermediate2 causes
Open runbook

Commands marked READ CHANGE DESTRUCTIVE — never run DESTRUCTIVE commands against production data you cannot restore. Copy → verify → execute.