Internal DNS resolution failure decision tree — internet works but the intranet OA won't open

Q: Why does the internet work but the internal OA does not?

The internal OA uses a company intranet domain (for example oa.corp.local) that only the internal DNS server knows how to resolve. A public DNS (114, 8.8.8.8) has no idea about that name. Once a client mistakenly picks up a public DNS, the internet keeps working while every intranet name fails — which looks exactly like "WeChat works, OA does not".

Q: Should I look at ipconfig /all or ipconfig /displaydns?

/all shows which DNS server the client currently received from DHCP — use it to judge whether the distribution is correct. /displaydns shows what the system has already cached — use it to rule out stale cache. Step one is /all to confirm the DNS server itself; step two is /flushdns to clear cache.

Q: Will the one-click fix script break a healthy network config?

The script only releases and renews the DHCP lease (ipconfig /release, /renew) and switches DNS back to the specified internal server. It does not delete drivers or touch the registry. But if your network does not rely on DHCP for DNS (static IP environments), the "renew" step can wipe the static config — in that case use GPO or manual assignment, and treat the script as emergency reference only.

I have seen this more than once on enterprise office networks: a whole department reports "WeChat chats fine, web pages open, but the internal OA system won't open". The first reflex is usually "the OA server is down" or "the OA front end has a bug", and ops spends ages checking the server — only to find the server was never the problem. The client simply could not resolve the intranet name.

What makes this failure nasty is that it looks like a server outage but the root cause sits in the client's DNS config. The decision tree below handles the "internet works, intranet name does not" class, so you do not misdiagnose it from the start.

60-second check — is it DNS?

Do not touch the server yet. Self-test with one sentence:

External sites (Baidu, web WeChat, GitHub) all open, but company intranet domains (oa.xxx.com, git.xxx.com) do not → strongly suspect a wrong DNS push.

If even the external internet fails, that is outside this page — check the gateway and physical link first.

Troubleshooting decision tree

User reports: OA page won't open, but the internet works
  │
  ├─ Confirm the scope
  │    ├─ Only one person affected? → likely that machine's DNS cache/config (check the host)
  │    └─ Multiple people at once?  → likely DHCP pushed a wrong DNS (check DHCP/network)
  │
  ├─ ping the OA IP address (use IP directly, bypass the name)
  │    ├─ IP answers, name fails → confirmed DNS resolution problem (not a dead server) ★most common entry
  │    └─ IP also fails          → not DNS, check OA server / link (out of scope here)
  │
  ├─ ipconfig /all, look at the "DNS Servers" line
  │    ├─ Shows a public DNS (114.114.114.114 / 8.8.8.8)?
  │    │     → client picked up external DNS, intranet name cannot resolve → switch back to internal DNS
  │    └─ Shows the internal DNS indeed?
  │          ├─ but nslookup oa.xxx.com still fails → internal DNS itself lacks the record / forwarder broken
  │          └─ nslookup works                 → stale client cache, just flushdns
  │
  └─ Root-cause locating (multi-user scenario)
       ├─ Rogue small router hijacking DHCP? → disable it, keep one controlled DHCP
       ├─ Option 43 misconfig pushed public DNS? → fix the scope option
       └─ Client kept old-network DNS?          → release/renew / GPO hardening

The hinge of the whole tree is one line: decide first whether the server is down or the name will not resolve, then choose whether to check the server or the DNS config. That ping IP step at the front is the pivot — IP answering proves the server is alive and the problem collapses onto DNS.

Three-step locating commands

Run them in this order and you can usually characterize the fault within five minutes.

Step 1 — confirm it is stuck on the name only

ping oa.xxx.com      :: ping by name, likely times out or fails to resolve
ping 10.20.30.40     :: replace with the real internal IP of the OA server; IP answers → DNS confirmed

Note: pinging by IP bypasses name resolution. IP answering while the name fails proves "the server is alive, the name just will not look up".

Step 2 — see which DNS the client actually received

ipconfig /all

Find the "DNS Servers" line. It should show the company internal DNS (e.g. 10.20.30.10). If it shows 114.114.114.114, 8.8.8.8, or a phone-hotspot DNS, the client wrongly took an external DNS.

Step 3 — verify resolution on purpose

nslookup oa.xxx.com                       :: query with the system default DNS; failure means default DNS rejects intranet names
nslookup oa.xxx.com 10.20.30.10           :: query the internal DNS explicitly; works → proves internal DNS is fine, client just did not use it
ipconfig /displaydns                      :: see if oa.xxx.com is stuck on a wrong cached record
ipconfig /flushdns                        :: clear cache and retry, rule out "stale cache"

One-click fix script (emergency, copy and run)

The PowerShell below is safest on clients that receive DNS via DHCP: release the old lease, renew (picking up the correct internal DNS), then clear the cache once.

# Switch back to internal DNS (emergency script, run as administrator)
# Only for clients that auto-get DNS via DHCP; do NOT use directly on static-IP machines (see note)
Write-Host ">> Releasing current IP and DNS lease..." -ForegroundColor Cyan
ipconfig /release | Out-Null
Write-Host ">> Renewing address (with correct internal DNS)..." -ForegroundColor Cyan
ipconfig /renew   | Out-Null
Write-Host ">> Flushing DNS cache..." -ForegroundColor Cyan
ipconfig /flushdns | Out-Null

# Verify result
$dns = (Get-DnsClientServerAddress -AddressFamily IPv4 | Where-Object { $_.ServerAddresses } | Select-Object -ExpandProperty ServerAddresses) -join ", "
Write-Host ">> Current DNS servers: $dns" -ForegroundColor Yellow
Write-Host ">> Try the internal OA again; if it still fails, check the DHCP Option 43 push." -ForegroundColor Green

Honest note: this script only does "release/renew DHCP + clear cache". It executes nothing on any HA/network device and does not simulate your network. It fixes the "client kept a wrong DNS" class; if the root cause is the DHCP push itself (multiple users hit at once), the script treats the symptom, not the cause — fix the DHCP side (next section).

On static-IP machines, do not run the /release /renew above — it wipes the static config. Use GPO or set the internal DNS manually in "network connection → IPv4 → DNS", then harden with Set-DnsClientServerAddress:

# Static-IP client: set internal DNS directly (example, change to your real internal addresses)
Set-DnsClientServerAddress -InterfaceIndex (Get-NetAdapter | Where-Object { $_.Status -eq 'Up' }).ifIndex `
  -ServerAddresses ("10.20.30.10","10.20.30.11")

Root cause — stop the wrong push from happening

Fixing one host is only a temporary patch. When multiple users hit at once, the cause is in DHCP or network structure. Close it off in three layers:

Layer	Action	Prevents
Network	Allow only one controlled DHCP server; disable DHCP on privately plugged-in routers	rogue devices answering first and pushing external DNS
Config	Fix DHCP scope Option 43 to push internal DNS; enforce via domain GPO where available	Option misconfig pushing public DNS as internal
Client	Baseline-check DNS on static-IP machines, bake into the imaging template	single client keeping an old-network DNS

One often-missed point: DHCP Option 43 is not only for APs/phones. Many shops write DNS into Option 43 as a convenience and accidentally put a public address there, so clients receive it wrong. Before editing Option 43, grab one healthy client's ipconfig /all and configure from its "correct line" — do not fill it from memory.

Quick decision table (use it directly)

Symptom	First reflex (misjudged)	Real root cause	Where to look
Internet works, OA won't open	OA server down	Client got wrong external DNS	Local ipconfig /all
One person only, others fine	OA front-end bug	Local DNS cache / leftover	flushdns + renew DHCP
Multiple at once	OA system broken	DHCP pushed wrong DNS	DHCP Option 43 / rogue router
IP answers, name fails	Network down	Name resolution failed	DNS server and forwarder
IP also fails	Must be DNS	Actually server / link	The OA server itself

This table is the landing version of "what it is most easily misjudged as" — in the first five failures, eight out of ten tickets open as "OA is broken", and checking against this table skips most of the wasted effort.

FAQ

Q: Why does the internet work but the internal OA does not?
A: The internal OA uses a company intranet domain (e.g. oa.corp.local) that only the internal DNS server knows how to resolve. A public DNS (114, 8.8.8.8) has no idea about that name. Once a client mistakenly picks up a public DNS, the internet keeps working while every intranet name fails — which looks exactly like "WeChat works, OA does not".

Q: Should I look at ipconfig /all or ipconfig /displaydns?
A: /all shows which DNS server the client currently received from DHCP — use it to judge whether the distribution is correct. /displaydns shows what the system has already cached — use it to rule out stale cache. Step one is /all to confirm the DNS server itself; step two is /flushdns to clear cache.

Q: Will the one-click fix script break a healthy network config?
A: The script only releases and renews the DHCP lease and switches DNS back to the specified internal server. It does not delete drivers or touch the registry. But if your network does not rely on DHCP for DNS (static IP environments), the "renew" step can wipe the static config — in that case use GPO or manual assignment, and treat the script as emergency reference only.

Q: Why would DHCP hand out the wrong DNS?
A: Three common causes: 1) an uncontrolled DHCP server joined the network (e.g. a privately plugged-in router) answering first; 2) a misconfigured Option 43/51 on the scope pushing a public DNS as if it were internal; 3) the client previously connected to another network and kept the old DNS setting. The root cause is almost always on the DHCP side, not the client.

Q: How do I stop it from coming back?
A: Three layers: network layer — only one controlled DHCP server is allowed to answer, disable DHCP on rogue access routers; config layer — fix Option 43 to push the internal DNS, or enforce it via domain GPO; client layer — baseline-check static-IP machines. Patching the DNS is treating the symptom; preventing the wrong push is the cure.