A user can reach a service by entering its IP address, but the familiar website name fails. That pattern points toward name resolution, but it does not prove the DNS server itself is down. The client could be using the wrong resolver, receiving an outdated answer, or querying a different name than expected.
DNS turns names people use into addresses computers can route to. Networks may have internal and public zones, search suffixes, VPN-specific resolvers, and cached answers. A name that resolves on one network may intentionally return a different address on another. Check the query, resolver, and expected answer together.
Record the exact hostname, affected device, network, configured DNS servers, and result of a query. Note whether the failure is “name not found,” a timeout, or an unexpected address. Compare a working client without assuming its DNS configuration is identical.
After correcting the record or client resolver, query the hostname again from the affected device and confirm it returns the intended address. Then open the service by its normal name and verify the application, certificate, and any required redirects work as expected.
A short name may depend on a search suffix, while a fully qualified domain name is queried exactly. Test both forms if users normally type a short internal name. Confirm that the record type required by the application is present.
A timeout suggests a resolver or path issue; a valid but wrong address suggests a record, split-DNS, or stale-cache issue. A negative answer may mean the name is absent from that zone. The response details guide the next check.
Document internal and public DNS zones, resolver assignments, and VPN behavior. Monitor critical records and resolver health, use change review for address updates, and include the expected answer in application onboarding documentation.
When an IP address works but a hostname fails, check which DNS server the client is actually using rather than assuming it uses the one shown in a central configuration. VPN clients, Wi-Fi networks, security agents, and local adapters can each supply DNS settings. Compare the assigned resolver, search suffix, and response time on an affected client and a working client. Then query the exact fully qualified name so an automatic suffix search does not hide which name was requested.
Inspect both the answer and the path used to obtain it. A timeout suggests the query did not receive a timely response; a negative answer means a resolver replied that it could not find the record; and an unexpected address may point to stale data, split-horizon DNS, or a record that differs by network. Compare A and AAAA answers where relevant, and check whether the client is trying IPv6 first while the service is reachable only over IPv4. Do not infer that all DNS is broken from one hostname.
Use a known-good resolver as a controlled comparison, following the organization’s policy. If one resolver returns the expected address and another does not, investigate forwarding, zone replication, conditional forwarding, or resolver health. If the answer is correct but the connection still fails, DNS may be working and the next issue may be routing, a firewall, or the service listener. Avoid changing public DNS settings on a managed device as a quick workaround; it can bypass internal records and security controls.
After correcting the record or resolver path, account for caching. Different clients and recursive resolvers may hold old answers until their cache expires, so validate from the affected device and confirm the answer’s TTL. Record the name, resolver, query time, response code, and returned address in the incident. Monitoring important internal names from more than one location can reveal whether a future failure is limited to a resolver, a network segment, or a specific DNS zone.
Check whether the failure is limited to one device, one domain, or all hostnames. If several unrelated names fail on one network, look at resolver reachability or client DNS configuration. If one name fails everywhere, inspect the record, authoritative zone, and any recent migration. If internal names work but public names fail, forwarding or egress rules may differ. This simple scope check can save time before changing DNS settings.
Remember that a browser may use a configured secure DNS service or proxy instead of the operating system resolver. Compare the browser’s behavior with a direct, approved DNS query and check managed browser policy before changing it. If an endpoint security tool intercepts DNS, its event log may explain why a query was blocked or redirected. A successful direct query does not prove the browser used that same resolver.
After changing a record, verify it from the affected network and from a second resolver location where appropriate. Confirm that old addresses are no longer returned after the expected cache period and that the application is listening at the new address. Keep the previous record and change time in the incident so teams can understand temporary differences during propagation.
Check the hostname, the resolver that answered, and the address it returned. When those three details are clear, DNS troubleshooting becomes a sequence of verifiable checks instead of guesswork.
If an IP address works, is DNS definitely the only problem?
DNS is the first suspect, but the application may also behave differently when accessed by its hostname. Confirm the answer and test the service using its normal name.
Why can the same hostname return different addresses?
Organizations may use split-horizon DNS, where internal and public resolvers provide different answers. This is expected when the services or routing paths differ.
Should I use a public DNS resolver to fix it?
Only if that matches the network policy and the name is public. Internal service names often require corporate DNS, and changing resolvers can break access or leak queries.
When should I clear the DNS cache?
After you confirm the intended record is correct and the client is holding an outdated result. If the resolver still returns the wrong answer, a local cache clear will not solve the source problem.
Join the discussion: Which command would you run first, and what result would you look for?
For hands-on practice with real network troubleshooting, explore training with Atmic Networks.
SEO title: The Internet Works by IP Address—but Not by Name. What Next?
Meta description: Internet access works by IP but not by name? Learn how to check DNS servers, hostname records, suffixes, caches, and split DNS.
Focus keywords: IP works but hostname does not, DNS troubleshooting, name resolution, nslookup
URL slug: internet-works-by-ip-not-name
