The internet is flawless. Yet the office server, the intranet page and the accounts package all report that their names cannot be found. Those names were never on the internet to begin with — they exist only inside your office DNS. Point the PC at a public DNS server and you have thrown away the only phone book that contains them.
Every office network runs two worlds of names. Public names — websites, cloud services — live in the global DNS that anyone can ask. Internal names — the file server, the intranet portal, the printer by the accounts desk, names like server01 or intranet.company.local — live only in the office's own DNS server, usually the domain controller. Ask Google's DNS about them and it answers honestly that no such name exists, because in the public world it does not. The PC then shows ERR_NAME_NOT_RESOLVED, and the user reports the paradox: everything works except the office. This breakage usually arrives as a side effect of a home remedy — someone set 8.8.8.8 on the adapter to fix a slow-internet complaint, or to dodge a filtering DNS, and quietly amputated the office's internal world. The repair is to restore the office DNS as the PC's phone book, and to understand why half-measures like mixing both servers cause the failure to come and go.
The symptom pattern is precise and worth memorising, because it separates this fault from every other DNS problem: websites open, internal things do not. The shared drive mapped by server name disconnects while the same drive by IP address connects. The printer added by name vanishes; the intranet shortcut errors; remote desktop to the server by name fails while by number it succeeds. IPs always working while names fail is the oldest DNS signature there is — and when only office names fail, the internal phone book is the one being bypassed.
Run the shot-panel test on your own machine: ask your configured server and the office server (ask IT for its address; it is usually the domain controller) for the same internal name. Opposite answers close the case in under a minute.
The tempting compromise — office DNS as primary, public DNS as secondary, surely the PC will ask the right one — is exactly how this fault becomes haunted. Windows does not treat the list as internal questions to server A, external questions to server B. It treats it as a pool of equivalent authorities and may ask either server about any name, especially after a timeout or a slow reply.
So the intranet works at 9 in the morning and fails at noon, depending on which server happened to answer — and a negative answer from the public side can be cached and served again later. There is no configuration in which a public resolver learns your internal names. The only correct design is: the PC asks the office DNS, and the office DNS forwards public questions onward. Forwarding is the server's job, configured once by IT, invisible to every user.
ipconfig /all and read the DNS Servers line. On a healthy office PC it should show the office DNS server (often the domain controller), frequently handed out automatically by DHCPipconfig /flushdns to drop cached non-existent answers for the internal namesIf DNS already points at the office server and internal names still fail, the problem has moved upstairs: the office DNS service or the records themselves — genuinely IT's territory now, and your nslookup comparison is exactly the evidence they need. On a domain-joined machine, leave Group Policy-managed settings alone entirely; the domain is supposed to own this layer.
Remote staff meet the same error through a different door. From home, internal names resolve only while the VPN is connected, because the tunnel is what delivers the office DNS to your laptop. Disconnected VPN, dead internal names — while the home internet works beautifully. That is not a fault; it is the design.
The subtler failure is a VPN that connects but whose DNS does not take over (or a home tweak that overrides it). The test is identical: with the VPN up, nslookup an internal name and read which server answered. If the answering server is your home router or a public resolver, the tunnel's DNS is not in charge — report that sentence to IT verbatim and you have saved everyone the usual hour of reinstalling things. What you must not do is hard-code the office server's address into your adapter at home: off the VPN it is unreachable, and then every name fails, not just internal ones.
Watch the video for the live comparison — the same internal name asked through public DNS and through the office server, and the adapter setting that caused it all.
▶️ Watch Full VideoInternal names like the file server or intranet exist only in the office DNS server's records. A public DNS server has never heard of them and truthfully answers that they do not exist, while it answers public website names correctly. The PC is asking the wrong authority for office names.
No — Windows treats all configured DNS servers as interchangeable and may ask any of them about any name. When the public server is asked about an internal name it returns non-existent, sometimes intermittently as servers rotate. Office PCs should use only the office DNS, which forwards public queries onward.
Run nslookup for an internal name and read which server answered. With a healthy VPN the answering server should be the office DNS. If your home router or a public server answered, the VPN's DNS is not being applied — that exact finding is what your IT team needs to fix it.