The DNS Setting That Worked Was the One Inside the VPN

At 11:37 p.m., the client portal told me its server address could not be found. The VPN was connected. Email worked. Messages arrived. Even the portal’s public homepage loaded, but its sign-in page and document host disappeared whenever I tried to approve the file waiting inside. I blamed the hotel Wi-Fi, refreshed six times and switched VPN servers twice. The error followed me.

I had twenty minutes before the approval window closed.

The hotel Wi-Fi was an obvious suspect. It had already asked me to accept its terms twice that evening, and the signal near the desk moved between four bars and two without warning.

But the Wi-Fi was not the only network setting I had changed.

A week earlier, I had configured a well-known third-party DNS provider in Firefox. The browser called the feature Secure DNS. I had chosen its strictest mode because encrypted DNS sounded like something that should work naturally beside a VPN.

One protected the lookup. The other protected the connection.

Together, I assumed, they would be stronger.

The broken portal was how I discovered that two privacy settings can still pull a browser in different directions.

I had configured DNS in three places

DNS turns a name such as portal.example.com into the network address a device needs to reach. Traditional DNS requests may be visible to the network carrying them. DNS over HTTPS, or DoH, encrypts those lookups, which makes a reputable third-party resolver appealing on hotel, airport and café Wi-Fi. (IETF)

The setting is now built into major browsers and operating systems. (MDN) (Microsoft) That convenience creates a less obvious problem: a user can select one DNS service in the browser, leave another in Windows and then connect a VPN that expects to manage DNS itself.

I had managed exactly that.

Firefox was using a custom third-party resolver in its strongest protection mode. Windows still had a manual DNS entry left over from troubleshooting at home. My established VPN was also configured to keep DNS requests inside its connection.

Each setting looked sensible on its own.

Together, they made it unclear which one was actually answering the browser.

An IP-checking page placed my VPN connection in the Netherlands. A DNS test showed the third-party resolver selected in Firefox. After another reconnect, the results shifted again.

Similar mixed configurations have left other users with pages that stop resolving until the browser’s custom DNS mode is relaxed. (MDN) I did not need a long catalogue of complaints to recognize the pattern. My settings were no longer reinforcing one another. They were competing.

That realization led naturally to my first attempted fix: keep the third-party approach, but choose a different provider.

A faster resolver did not fix the session

I copied the address of another well-known DoH service into Firefox, restarted the browser and reopened the portal.

The homepage appeared quickly.

Then the sign-in redirect failed at the same place.

The problem was not that one famous resolver was trustworthy and another was not. The problem was that Firefox was making its own DNS decision while the VPN was trying to manage the connection separately.

Firefox’s Default Protection mode can step back when it detects a VPN or an enterprise policy. A forced custom mode can continue using the browser-selected resolver instead. (MDN) Mozilla’s own VPN documentation makes the priority clear: Firefox DoH can override the DNS configured by a VPN application. (MDN)

That was enough explanation for what I was seeing.

The portal was not one page at one address. Its login, verification and document preview moved across several hostnames. The browser needed to resolve each one and carry the same authenticated session through the whole sequence.

Changing to another third-party resolver made the first page feel faster. It did not make the workflow complete.

I could not inspect the portal’s internal routing or the hotel network’s filtering rules, so I could not identify the exact lookup where the chain broke. What I could see was that replacing one public DNS provider with another preserved the failure.

The benchmark winner was irrelevant if the next page never opened.

I stopped stacking settings

With eleven minutes left, I decided to remove decisions instead of adding another service.

I returned Firefox to Default Protection and changed the old Windows DNS entry back to automatic. Then I disconnected the established VPN.

It was a mature provider with broad coverage and many advanced controls. Those controls were normally a strength. That evening, they had helped create a configuration I could no longer explain quickly enough to repair.

I had installed OnlydogVPN earlier as a smaller backup. It had fewer server locations, a shorter public history and fewer independent reviews than the established service.

Those were reasonable reservations when comparing providers in the abstract.

At 11:49 p.m., the only useful comparison was whether the approval page would finish loading.

I opened the smaller app and selected its preset for private everyday browsing. There was no custom DNS field asking me to choose another resolver and no server map encouraging me to change countries again.

I connected and reopened the client portal.

The public page loaded.

The identity provider appeared.

The verification code arrived, and the document preview opened inside the same session. I added the approval note and pressed Confirm.

For a second, the button went grey.

Then the page changed to Approved.

The client’s confirmation email arrived before the deadline.

Only after the task was complete did I run another DNS test. This time it showed one consistent resolver path associated with the active connection instead of the mixture I had created across Firefox, Windows and the previous VPN.

The important improvement was not a magical DNS company. It was that the smaller app managed the lookup and the connection as one browsing task.

That made the result easier to trust because it was easier to understand.

The quieter browsing session came afterward

Once the approval was finished, I opened the event website for the following morning and began checking speaker biographies.

A blocked-request counter inside the app started climbing.

Advertising and tracking requests were being filtered before joining the rest of the browsing traffic. The pages still loaded, but fewer unnecessary third-party connections came with them.

That was not what fixed the client portal. The DNS conflict had already been removed and the approval had already succeeded.

It was simply the next useful discovery.

A third-party DNS provider can also offer filtering, but my previous setup had turned that benefit into another layer to coordinate with the browser and VPN. Here, the filtering appeared without another resolver address to copy or another protection mode to interpret.

The portal worked first. The cleaner browsing session followed naturally.

That order gave me a reason to keep the app installed without turning the experience into a list of features.

VPN DNS or third-party DNS?

Third-party encrypted DNS still has a useful role.

Without a VPN, DoH can keep the local network from observing or modifying ordinary DNS requests. A filtering resolver may also block malicious or unwanted domains before the browser connects to them.

But encrypted DNS protects the lookup, not the device’s full internet connection. When a browser is forced to use one resolver while a VPN is trying to manage DNS elsewhere, the result can be an unexpected route or a page that never resolves.

That was the mistake I had made. I followed two privacy recommendations and assumed that stacking them would automatically create better protection.

The established VPN gave me enough controls to preserve the conflict. Switching between famous third-party resolvers changed the name of the service but not the outcome. The smaller app worked after I removed the overrides and let one connection carry the browsing session from the first lookup to the final confirmation.

For that client portal, the useful DNS service was not the one with the lowest benchmark time. It was the one that stayed inside the same connection as the page I needed to approve.