When name lookups behave strangely — a site that resolves oddly, a change that doesn't take effect, a difference between two devices on the same connection — the VPN gets blamed first, because it's the most visible recent change. But DNS behavior on a modern device has many owners, and the VPN profile is only one of them.
This is a checklist for locating which layer is actually answering, in a way that changes nothing destructive: the goal is to identify, not to tear down a working setup.
The layers that can own a DNS answer
Before checking anything, it helps to know the candidates. A name lookup on a typical device can be influenced by the device's own DNS cache (answers remembered from earlier), the browser's DNS behavior (some browsers resolve names their own way, separately from the system), a private or secure DNS setting on the device or in the browser, the router's DNS configuration on the local network, an individual app's own DNS choices, and the VPN profile's DNS handling while connected.
Any one of those can be the layer you're actually hearing from. That's why the same site can behave differently in two browsers on one laptop, or on two devices sharing one network — different layers are answering.
Start with the cheapest, least destructive checks
First, reproduce the behavior deliberately: does it happen on one site or many, in one browser or every browser, on one device or all of them? That triangulation alone often points at the layer. One browser only: suspect that browser's DNS behavior or its private-DNS setting. One device only: suspect that device's cache or settings. Everything on the network: the router's DNS configuration becomes interesting. Only while the VPN is connected: now the profile's DNS handling is a fair suspect.
Cached answers can remain after a change, but restarting a device does not clear every browser, router or upstream resolver cache. Record the hostname, query type, result and observation time first. Waiting may help a stale cache expire; persistent failures or differing resolver policies need further checks rather than repeated restarts.
Check settings by reading them, not changing them
Each layer has a place where its DNS behavior can be read. Browsers show whether a secure or private DNS mode is enabled in their settings. Devices show private DNS options in network settings. Routers show their DNS configuration in their admin pages — worth reading if the network is yours, and worth leaving alone if it isn't. Apps occasionally document their own DNS behavior in their settings or help pages.
The discipline that keeps this non-destructive: read first, note what you find, and change at most one thing at a time — on your own devices and networks only. A network you don't control, or a device your organization manages, isn't yours to reconfigure; on managed devices, the organization's IT function is the right path, and its policies stay in place.
Where the VPN profile fits
While connected, a VPN profile can handle DNS as part of the connection, and where a plan includes DNS AdBlock, some lookups may be filtered at the domain level. GeoDNS, DNS AdBlock and Custom Exit are available according to plan. Whether a given behavior comes from the profile is testable the same gentle way: does it appear only while connected, and does it appear across browsers and apps rather than in just one?
If the evidence points toward the VPN path, check the active profile and its current DNS-related settings in the Lisar panel. Follow the guide for its actual protocol and client. Preserve the exact symptom and contact support rather than changing profile contents or repeatedly reimporting a working connection.
Notes worth writing down before asking for help
Support conversations go faster with three facts: what changed and when (new network, new device, new profile, new setting); where the behavior appears (which sites, browsers, devices, networks — and whether it's VPN-connected only); and what you've already checked, layer by layer. That's the difference between "DNS is broken" and a report someone can act on — and it's exactly what the checklist above produces as a side effect.
A final word on patience: DNS behavior includes deliberate delays. Answers are cached at several layers precisely so the system doesn't ask the same question constantly, which means a recent change taking a while to appear everywhere is often the design working, not a fault. If the layered checks point nowhere and nothing else changed, giving it time — and then re-testing on one device, one browser, one site — is a legitimate step, not a shrug.
Frequently asked questions
How do I tell if the VPN is causing my DNS behavior? Compare the same hostname and type of result under controlled, permitted conditions. A difference only while connected is a useful clue, not proof of the cause. Read the browser DNS mode, system resolver and profile settings; resolver selection and the route used to reach it are separate questions.
Why do two browsers on the same laptop resolve a site differently? Some browsers handle DNS their own way, including private or secure DNS modes that resolve names separately from the system's settings. Checking each browser's DNS settings — by reading them, not changing them — usually explains the difference.
Should I reset my router or reinstall things to fix DNS issues? Not as a first step. Record the exact lookup or error, compare the relevant resolver settings and change one appropriate condition at a time. A device restart does not clear all DNS caches, and resetting a router may disrupt an otherwise working configuration.
Does DNS AdBlock change what I'll see in these checks? Where a plan includes it, DNS AdBlock may filter some lookups at the domain level while connected, so a difference between connected and disconnected behavior can be expected there. Whether it applies to a specific profile is a plan fact, checked in the Lisar Panel.
What should I include when contacting support about DNS? What changed and when, where the behavior appears (sites, browsers, devices, networks, VPN-connected or not), and which layers you've already checked. Specific observations turn a vague complaint into something support can act on.
Related guidance: DNS Ad Blocking vs Browser Ad Blocking and Why You Still See Some Ads With DNS Filtering On.