A business website opens on mobile data but not on the office network. That comparison narrows the investigation; it does not prove the office internet connection is broken.

DNS translates a service name into the address a device uses to connect. When that lookup fails, staff may describe the symptom as “the internet is down”, even if other services work. ITZ’s office network setup and troubleshooting service can help separate name-resolution problems from connectivity, filtering and application failures.

Capture the scope before changing settings

Record the exact hostname, error message, time and affected devices. Note whether the failure occurs on wired connections, staff Wi-Fi, guest Wi-Fi or VPN. Compare an approved second device on the same network and another permitted connection. Avoid using confidential internal names in public troubleshooting sites.

If only one browser fails, investigate its proxy, secure DNS and cached state alongside the operating system. If every office device fails for one hostname, focus on shared resolver, filtering and destination factors. If all names fail but the network is connected, DNS is one possibility; the gateway, resolver reachability and upstream service still need checking.

Check the assigned network configuration

On Windows, an authorised support person can inspect ipconfig /all and record the active adapter, DNS server addresses, gateway and DNS suffix. Microsoft’s DNS-client troubleshooting guide starts with this configuration check. Compare it with the intended office setup before changing anything.

A device on the wrong Wi-Fi network or VPN may use a different resolver. If new devices cannot obtain a valid address at all, use the DHCP capacity checklist; that is a different failure from receiving an address but failing a name lookup.

Ask the resolver a specific question

The Windows nslookup command can query a hostname using the configured DNS server, or an explicitly selected server. Start with the failing full hostname rather than a vague short name. For an illustrative public test, nslookup www.example.com asks for that host’s address.

Record the server queried and complete response. A timeout, a server failure and a response saying the name does not exist are different observations. For a public hostname, an approved comparison against another resolver may help isolate the problem. Do not send private internal hostnames to a public resolver simply to see what happens.

Request an Office DNS Review if staff repeatedly lose access to a business service. Describe the affected network and hostname type; keep internal diagnostic exports in an approved support channel.

Interpret the result without overclaiming

  • No response from the configured resolver: check its reachability, service health and permitted DNS traffic.
  • An unexpected address: compare intended records, resolver answers and recent DNS changes.
  • A correct answer but a failed page: continue with connection, proxy, TLS, filtering and application checks.
  • Internal names fail after a DNS change: check whether the device has lost access to the office’s internal resolution path.

Microsoft’s DNS-server troubleshooting documentation provides a deeper administrator path for server health and upstream resolution. Query success alone is not a complete browser test: the browser may use another resolver path, and a returned address does not prove the destination accepts the connection.

Avoid the public-DNS shortcut

Changing every workstation to a public resolver may hide one symptom while breaking private applications, domain services or approved filtering. Some businesses intentionally return different answers inside and outside the office. Document that design before replacing it. A blocked destination may reflect an intentional security decision; investigate with the policy owner rather than disabling protection.

Cache clearing has a narrower role. Microsoft notes that Windows can retain a negative response locally. After confirming the underlying record or resolver issue is fixed, an authorised administrator can clear the client cache and retest. Flushing the cache is not a repair for missing authoritative records or an unreachable DNS server.

Close the incident with a repeatable test

Change one relevant setting at a time, retain the previous value and retest the affected service and internal dependencies. Record the cause, action and responsible owner. For recurring remote-user problems, discuss remote IT support. Keep guest-network isolation intact during diagnosis.

Request an Office DNS Review. Use the form below to discuss resolver configuration, public and internal name resolution, recurring failures and a documented support procedure.

Request an Office DNS Review ↗

Official Microsoft references reviewed on 15 October 2026. Commands and checks must fit your operating system, permissions and network policy.