Two browsers, one laptop, two answers: identify the resolver before blaming the VPN

A debugging checklist published on dev.to makes a narrow but useful point: when a hostname resolves oddly, the VPN gets blamed first because it is the most visible recent change ^[1]. That reflex skips the only step that produces an answer, which is establishing which layer replied and under what conditions ^[3].

The premise is that a modern device has no single DNS owner. A lookup can be influenced by the operating system, the browser, the router, an application, a cache, a secure-DNS setting, or the active VPN profile ^[2]. The checklist enumerates six layers that may sit in the path of a typical lookup: the device cache holding an earlier answer, the browser's own DNS behaviour, a private or secure DNS setting in the browser or OS, the router's DNS configuration, an application resolving names separately, and the VPN profile's DNS handling while connected ^[4][7]. More than one can be active at once ^[5]. That is the mechanism behind the symptom operators find most disorienting: two browsers on one laptop behaving differently, or two devices on the same network disagreeing, with an identical visible symptom and a different responsible layer ^[6].

The consequence for practice is that "DNS is broken" is close to uninvestigable, while "this hostname fails in two browsers on this device only while the VPN is connected" is actionable ^[9]. Hence the instruction to write the symptom down before touching anything: one destination or several, the exact browser error, whether it happens every time, when it began, what changed recently, and whether it happens only while the VPN is up ^[8].

The comparisons that follow are deliberately boring. Same destination in a second browser. Another destination in the original browser. Another device on the same network. Connected versus disconnected where that is permitted and safe. The same device on another network you are authorised to use ^[10]. The discipline is holding everything else constant: change browsers, devices, networks, VPN state and DNS settings together and the result will not tell you which one mattered ^[11]. The author is explicit that these patterns are diagnostic signals rather than proof, and that their value is narrowing the next check without a destructive change ^[19].

Two items are worth quoting to anyone who reaches for a factory reset. DNS answers are cached deliberately, so a recent change may take time to appear consistently, which makes waiting and retesting a legitimate step, with a device restart as a relatively gentle way to clear local state ^[12]. A router reset, a reinstall, or a broad network reset should not be the first response to a DNS-shaped symptom ^[13].

Inspection before modification: check whether a secure or private DNS mode is on in the browser, read the OS network and private-DNS settings, review an application's documented resolution behaviour, read the configured DNS values on a router you administer, and confirm in the VPN client which profile is selected and whether the connection is actually active ^[14]. If the network is not yours, do not reconfigure its router; on a managed device, organisational policy stands and IT is the escalation path ^[15].

When a change is justified, change one thing, on infrastructure you are authorised to manage, and record the original state, the change, the time, and the result of repeating the same test ^[16]. If nothing moves, restore the original state before touching another layer, which keeps the work reversible and stops undocumented changes becoming a second incident ^[17]. Then re-run the original comparisons unchanged: same destination, browser, device, network and VPN state ^[18].

What to watch is whether your own runbook names the layer. A VPN profile can participate in DNS handling while the connection is active ^[20], which makes it a suspect, not a verdict.