Library Look up only what you need, then get back to the task.

DNS Works by IP but Not by Name

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

Troubleshooting playbook

DNS Works by IP but Not by Name

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

Networking and Remote Access medium severity both Field-verified
Open topic Open task guides
Symptom

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

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.
Likely 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.
Do not do yet
  • 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.
Verify 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.
You own this when
  • You can separate connectivity problems from name-resolution problems.
  • You can inspect local DNS configuration and test hostname answers.
  • You can choose the next branch based on no answer, wrong answer, or correct answer with app failure.
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?

Revisit this playbook in about 1, 7, 21 days.

Learn deeply
M28 - Network Model: How Networks Work

Understand the basic networking model of identity, local scope, routing, and name resolution so common network problems feel explainable instead of mysterious.

 M31 - DNS Deep Dive

Inspect DNS resolution directly so you can separate naming problems from connectivity problems and understand local overrides such as the hosts file.

 M32 - Network Diagnostics

Troubleshoot network problems layer by layer using connectivity tests, route tracing, DNS checks, and port inspection.

 M50 - Remote Access: Advanced

Use safer remote-access patterns for SSH, RDP, and PowerShell remoting, and understand why bastion hosts and VPNs reduce exposure.
Practice it
LAB-NET-02 - Ping and Reachability

Use ping to test reachability in a more structured way, separating local stack checks, gateway checks, and broader connectivity checks.

 LAB-NET-03 - DNS and Name Resolution

Query DNS directly and recognize when a hostname problem is different from a reachability problem.
See the model
DNS and Network Request Flow

Understand name resolution, routing, service reachability, and firewall checks as one layered network path.