Split-horizon DNS and preview hosts

Split-horizon DNS is when the same hostname returns different answers depending on who asks. Your office resolver may hand out an internal address while the public internet gets another. A hosts file on one laptop is the same idea for a single machine. Preview hosts should use real staging names so you never mix those views while you test a move.

Prove what this machine resolves

Start on the computer that looks wrong. You need its local answer before you touch public DNS or open a ticket.

getent hosts example.com

On Linux, that command shows what this machine will use, including any hosts file entry. On macOS, try dscacheutil or getent, depending on the version. On Windows, check ipconfig /displaydns and the hosts file under System32driversetc.

If that output still shows the old IP, and dig example.com @1.1.1.1 shows the new one, public DNS is already fine. The laptop or office path is not. Flush or comment the hosts line, then test again from that same machine.

Office DNS can lag behind the public view

An internal Windows DNS server that still holds the old A record creates the same problem at company scale. People on LTE already see the new site. People on office Wi‑Fi still hit the old one. Update or remove that internal record, or wait for its TTL to expire. Take one phone off Wi‑Fi and load the site; that is closer to what customers see.

Do not change public nameservers only because the conference room is wrong. Confirm the public answer with a public resolver on purpose. Our guide on troubleshooting with dig covers authoritative answers versus cache, which is a different split than a hosts file.

Preview hosts without lying to DNS

Use a real staging hostname such as staging.example.com with its own A record, a separate vhost, and a robots noindex rule. That setup stays boring and easy to debug. A LiteSpeed or cPanel preview URL works the same way when you only need a quick look.

Editing /etc/hosts so production points at a private IP is how one laptop keeps seeing last week’s cutover. If you truly need an internal view, document it, name who owns that resolver, and keep the public view separate. When you troubleshoot, ask a public resolver on purpose so you are not debugging the wrong answer.