Overview

A DNS problem occurs when a device cannot translate a website or service name into the IP address needed to reach it. Before changing DNS servers, prove that general network connectivity works and determine whether the failure affects one hostname, one computer, or many users.

Do not change DNS servers as the first stepChanging DNS can bypass organizational controls and hide the real cause. Collect evidence first.

Why this happens

DNS resolution can fail because of a typo, stale local cache, incorrect DNS server assignment, VPN or proxy path, a broken internal DNS record, an upstream resolver outage, split-DNS design, or a record that has not propagated yet.

Before you begin

  • Record the exact hostname that fails.
  • Check whether other websites work.
  • Check whether another computer on the same network can resolve the same name.
  • Do not point a managed business computer to public DNS without approval.

Click-by-click troubleshooting

Step 1: Confirm the hostname and scope

Action: Copy the exact hostname from the browser or application. Test the same hostname on another approved computer on the same network.

Why this matters: A typo or single-device failure requires a different response than an organization-wide DNS failure.

What to look for: Determine whether one hostname, many hostnames, one device, or many devices are affected.

Expected result: You should have a clear scope before changing anything.

Step 2: Verify basic IP connectivity

Action: Open Command Prompt and run ping 1.1.1.1 or another approved known external IP test.

Why this matters: If external IP connectivity also fails, DNS may not be the primary problem.

What to look for: Compare external IP reachability with the hostname failure.

Expected result: If external IP connectivity works while names fail, DNS becomes the stronger hypothesis.

Step 3: Query DNS directly with nslookup

Action: Run nslookup hostname.example using the actual failing hostname.

Why this matters: nslookup shows whether the configured DNS server can return an answer and identifies the DNS server being queried.

What to look for: Record the DNS server, returned address, timeout, NXDOMAIN, non-existent domain, or server-failed response.

Expected result: A valid published hostname should return the expected address or addresses.

Step 4: Compare the configured DNS server with a working computer

Action: Run ipconfig /all on the affected and working computers. Compare the DNS Servers entries for the active adapter.

Why this matters: A single device can receive the wrong DNS settings even while the rest of the network functions normally.

What to look for: Look for a different DNS server, missing DNS server, unexpected VPN adapter, or stale network configuration.

Expected result: Devices in the same managed network should normally receive the intended DNS configuration for that network.

Step 5: Flush only the local DNS cache

Action: Open Command Prompt and run ipconfig /flushdns. Then repeat the nslookup test.

Why this matters: A stale negative or outdated local cache entry can survive after the authoritative DNS record has changed.

What to look for: Check whether the lookup result changes immediately after the local cache is cleared.

Expected result: The next lookup should be obtained fresh from the configured resolver.

Step 6: Check whether VPN or internal DNS is required

Action: If the hostname is an internal business system, verify whether the user is connected to the required office network or approved VPN. Do not test internal names through unapproved public DNS services.

Why this matters: Internal records may exist only on organizational DNS servers and are not supposed to resolve publicly.

What to look for: Determine whether the hostname resolves only while connected to the corporate network or VPN.

Expected result: Internal names should resolve through the organization's intended internal DNS path.

What to look for

  • External IP fails too: investigate connectivity before DNS.
  • One computer uses different DNS servers: investigate DHCP, adapter, VPN, or local configuration.
  • NXDOMAIN for a name that should exist: record may be missing or queried in the wrong DNS zone.
  • Internal name works only on VPN: likely expected split-DNS behavior.
  • Many users fail on the same hostname: investigate the DNS record or resolver service centrally.

When to stop

Do not bypass managed DNSStop before changing DNS servers, editing the hosts file, modifying DNS zones, or publishing records unless you are authorized and understand the business impact.

When to contact IT

Contact IT when the configured DNS server is wrong, an internal record is missing, many users are affected, a DNS zone change may be required, or the issue involves VPN or managed network configuration. Provide the hostname, scope, nslookup output, and DNS Servers values from ipconfig /all.

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 Group

Authoritative references

Vendor interfaces, licensing, and security guidance can change. Verify current platform behavior against the primary documentation below before making high-impact production changes.

Article KB-13.008 · Review after material vendor, licensing, interface, security, or service changes.