DNS Works by IP but Not by Name

Use this when direct IP connectivity works but hostnames do not resolve or connect correctly.

Troubleshooting

DNS Works by IP but Not by Name

You can reach the destination by IP address, but hostname-based access fails.

This usually means: If IP works but names do not, the route is often fine and the failure is usually in DNS answers, local resolver state, or application hostname handling above the route layer.

Internet and Network both medium severity Field-verified
Start with first checks Confirm the same target works by IP. Do not reboot the machine as a first step.
Symptom

You can reach the destination by IP address, but hostname-based access fails.

What this usually means

If IP works but names do not, the route is often fine and the failure is usually in DNS answers, local resolver state, or application hostname handling above the route layer.

Meaning of the symptom

If IP works but the hostname does not, the route is probably fine and the failure is higher in the name-resolution layer.

Safe sequence

  1. Prove the target really works by IP.
  2. Check what address the hostname resolves to.
  3. Compare that answer with the address that actually works.
  4. Inspect the configured DNS server and local resolver behavior.
  5. If name resolution is correct, move to application-specific hostname handling.

Common branch decisions

  • If the hostname returns no answer, focus on DNS configuration or missing records.
  • If the hostname returns the wrong address, focus on stale records, split DNS, or the wrong zone.
  • If the hostname resolves correctly but the app still fails, the issue may be TLS, proxy, or application hostname configuration rather than DNS itself.
First checks
  • Confirm the same target works by IP.
  • Run a hostname resolution check such as nslookup or dig.
  • Check the configured DNS servers and local resolver state.
Common causes
  • Wrong DNS server configured.
  • Resolver cache is stale or poisoned.
  • The hostname record is missing or incorrect.
  • The application is using a different name or proxy path than you think.
What not to do
  • Do not reboot the machine as a first step.
  • Do not assume the whole network is down.
  • Do not change firewall rules before proving the issue is beyond DNS.
Recovery steps
  • Prove which exact IP address works and keep it as your known-good baseline.
  • Check the hostname with nslookup or dig and compare the answer with the working IP.
  • Inspect the configured DNS servers and local resolver cache on the current machine.
  • Fix the wrong DNS server, stale cache, or missing record before changing lower network layers.
How to verify the fix
  • Confirm the hostname now resolves to the expected address.
  • Retry the actual application or remote connection using the hostname.
  • Confirm IP and name now behave consistently.
Move on when
  • You can prove whether the failure was actually in name resolution.
  • Hostname-based access now behaves consistently with IP-based access.
  • You can explain the specific resolver or record issue that caused the symptom.
Reflect before you leave
  • What evidence told you the route was probably fine and the issue was higher in the stack?
  • How would you distinguish missing records from wrong records and from application hostname handling?

Review this troubleshooting path again in about 1, 7, 21 days.

What to do next

Best next step Learning

Study the system model behind this problem.

Open now