Overview
If a business system works by IP address but not by name, basic network routing is probably working and DNS name resolution is the primary suspect.
Why this happens
DNS may be using the wrong server, returning a stale record, failing over VPN, caching an old address, or missing the required internal record.
Before you begin
- Record the hostname and known working IP.
- Confirm whether VPN is required.
- Do not edit the Windows hosts file.
- Do not change DNS servers without IT approval.
Click-by-click troubleshooting
Step 1: Confirm the IP test really works
Action: Access the system using the approved IP-based test method and confirm the service responds.
Why this matters: This establishes that the network route and destination are reachable.
What to look for: Confirm the same application or service responds by IP.
Expected result: Successful IP access narrows the issue toward name resolution.
Step 2: Run nslookup for the hostname
Action: Open Command Prompt and run nslookup hostname.
Why this matters: This shows which DNS server answers and what address it returns.
What to look for: Look for timeout, NXDOMAIN, no answer, or an incorrect IP.
Expected result: The hostname should resolve to the expected address.
Step 3: Check configured DNS servers
Action: Run ipconfig /all and review the active adapter's DNS Servers entries. You can also open Settings > Network & internet > Advanced network settings and review the active adapter without changing it.
Why this matters: Internal names may require organizational DNS rather than public DNS.
What to look for: Confirm whether the device is using the expected DNS path for office or VPN access.
Expected result: The active connection should use DNS consistent with the organization's network design.
Step 4: Flush the local DNS cache
Action: Open Command Prompt and run ipconfig /flushdns.
Why this matters: A stale local cache can preserve an old or failed lookup.
What to look for: Retest nslookup hostname after the cache is cleared.
Expected result: A stale local entry should no longer affect the lookup.
Step 5: Compare another device on the same network
Action: Run the same nslookup from another approved device on the same office or VPN network.
Why this matters: This distinguishes one-device DNS problems from server-side DNS record problems.
What to look for: Compare returned addresses and DNS servers.
Expected result: Matching failure across devices points toward shared DNS infrastructure.
Step 6: Compare VPN connected versus disconnected only if appropriate
Action: If the hostname is internal, connect to the approved VPN and repeat nslookup.
Why this matters: Internal DNS may only be available through the secure network path.
What to look for: Check whether the hostname resolves only after VPN connects.
Expected result: Internal names should resolve when the device is on the intended network path.
What to look for
- Wrong IP returned: stale or incorrect DNS record.
- No answer only off VPN: expected internal DNS dependency.
- One device only: local DNS/cache/configuration issue.
- All devices fail: shared DNS infrastructure issue.
When to stop
When to contact IT
Contact J3 Systems Group if DNS returns the wrong address, multiple devices fail, internal DNS is unavailable over VPN, or the record appears missing. Include article code KB-15.010, hostname, working IP, and nslookup/ipconfig /all results.
Need help with this issue?
J3 Systems Group supports small businesses and nonprofits with Microsoft 365, Google Workspace, cybersecurity, devices, documentation, and day-to-day IT operations.
Contact J3 Systems GroupAuthoritative references
Vendor interfaces, licensing, and security guidance can change. Verify current platform behavior against the primary documentation below before making high-impact production changes.