DNS Speed Test

How DNS Affects Remote Work

When you work from home, every tool you use — Slack, Zoom, Google Workspace, Microsoft 365, GitHub, Jira, Salesforce — depends on DNS lookups before you can interact with it. Each of these services runs across dozens of domains and subdomains. A single Slack session might touch 30 or more unique domains for webhooks, file storage, authentication, analytics, and real-time messaging. Your DNS resolver determines how quickly those connections start.

The problem is compounded by the fact that remote work tools are latency-sensitive in ways that casual browsing is not. A two-second delay loading a news article is annoying. A two-second delay joining a video call means you miss the opening of a meeting. A slow DNS lookup when authenticating with your VPN means your connection drops and reconnects, interrupting whatever you were doing. For remote workers, DNS is not a background detail — it directly affects productivity.

Most people never think about their DNS resolver. It runs silently in the background, set to whatever their ISP configured by default. ISP DNS servers are designed to serve millions of residential customers with general browsing needs. They are not optimized for the kind of persistent, multi-service, low-latency connections that remote work demands. Switching to a faster, more reliable DNS resolver is one of the simplest and most impactful changes you can make to your home office setup.

VPN and DNS Interaction

VPNs create an encrypted tunnel between your device and a corporate network. But before that tunnel can be established, your device needs to resolve the VPN server's hostname into an IP address. That initial DNS lookup is the first step in every VPN connection. If it takes 80 milliseconds with a slow resolver, your VPN connection starts 80 milliseconds later. If it fails because your ISP DNS is unreliable, you cannot connect at all.

Once the VPN tunnel is active, DNS behavior depends on how the VPN is configured. In most corporate setups, all DNS queries are redirected through the VPN tunnel to corporate DNS servers. This ensures that internal resources — file shares, intranet sites, internal APIs — resolve correctly. But this also means your DNS traffic now travels through the encrypted tunnel and out through the corporate network, adding latency to every lookup. If the corporate DNS servers are geographically distant from you, this round-trip can add 100 to 300 milliseconds to each DNS query.

Split DNS resolves this problem by routing only internal domain lookups through the VPN while sending external lookups (Google, Microsoft 365, Slack, etc.) to a fast public DNS resolver on your local network. With split DNS configured correctly, you get the best of both worlds: fast resolution for external services and correct resolution for internal corporate resources. Without split DNS, every single lookup — even for YouTube or CNN — travels through your corporate network and back, adding unnecessary delay to your browsing.

Some VPN clients handle split DNS automatically. Others require manual configuration. If you notice that your internet feels sluggish while connected to VPN, even though your bandwidth test shows good speeds, slow or poorly routed DNS is the most likely culprit. Check your VPN client settings for a "split tunneling" or "DNS routing" option and enable it if available.

Video Conferencing Optimization

Video calls are among the most demanding applications for remote workers. Zoom, Microsoft Teams, Google Meet, and Webex all use distributed media server networks to route voice and video traffic through the nearest point of presence. The quality of your call depends heavily on which media server your client connects to, and DNS determines that choice.

When you join a Zoom call, your client uses DNS to discover available media servers. A fast, well-routed DNS resolver returns the IP address of the nearest server quickly, and your client connects to it. A slow resolver delays that discovery, and in some cases, returns a stale or suboptimal server address from cache. The result is higher latency, jitter, and the familiar "Can you hear me?" moment at the start of a call.

The startup phase of a video call is where DNS matters most. During the first 3 to 5 seconds of connection, your client is performing multiple DNS lookups, establishing TLS connections, negotiating codecs, and finding the optimal media path. A slow DNS resolver can add 200 to 500 milliseconds to this startup sequence. After the call is established and media is flowing, DNS is no longer involved in the ongoing audio and video traffic. But that initial delay can be the difference between joining a meeting smoothly and fumbling with your connection while everyone waits.

For remote workers who spend hours daily on video calls, even small DNS improvements compound. If you make 5 video calls per day and save 300 milliseconds on each call startup, that is 1.5 seconds per day. Over a month, that adds up to over a minute of saved time — not dramatic, but noticeable in the feel of your setup. More importantly, a reliable DNS resolver eliminates the intermittent call connection failures that happen when ISP DNS servers are overloaded or return incorrect results.

One practical tip: if you use a VPN for work, make sure your video conferencing application's DNS lookups are not being routed through the VPN tunnel. Video call services like Zoom and Teams need to reach their media servers directly. Routing their DNS through a corporate network in another city or country can force your call through a suboptimal path, increasing latency and reducing call quality.

Cloud App Speed

Modern remote work runs on cloud applications. Google Workspace, Microsoft 365, Notion, Figma, Asana, Trello, Dropbox, Box, AWS-hosted internal tools — the list is long and growing. Each of these services depends on DNS for every API call, every file upload, every page load. A slow DNS resolver adds latency to every interaction with every cloud tool you use throughout the day.

The impact is most visible in collaborative workflows. When you open a shared Figma file, your browser needs to resolve the Figma CDN, the authentication service, the WebSocket server for real-time collaboration, and the asset server for images and fonts. That is four or more DNS lookups before you see anything on screen. With a slow resolver, each lookup adds 40 to 80 milliseconds. With a fast resolver, each adds 5 to 15 milliseconds. The difference between the two is visible in how quickly the file appears and how responsive the editing experience feels.

Cloud storage services are particularly affected because they involve frequent, short-lived connections. When you sync files through Dropbox or OneDrive, your client makes periodic check-ins with the server to look for changes. Each check-in involves a DNS lookup. With a slow resolver, these periodic lookups add up and can make syncing feel sluggish. With a fast resolver, the check-ins happen quickly and the sync process feels transparent.

API-heavy workflows — like using browser-based developer tools, running CI/CD dashboards, or working with data visualization platforms — generate even more DNS lookups per session. Each API request to a different microservice or CDN is a separate DNS lookup. For developers and data analysts working with cloud-hosted tools, DNS speed directly affects how responsive their development environment feels.

Top DNS Servers for Remote Work

Not all public DNS servers are equally suited for remote work. You need a resolver that is fast, reliable, supports DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) for privacy, and has good peering with the cloud service providers your company uses. Here are the strongest options for remote workers in 2026:

Cloudflare 1.1.1.1

Cloudflare operates one of the largest anycast DNS networks in the world, with points of presence in over 300 cities. Average response time is around 11 milliseconds globally. Cloudflare supports DoH and DoT, and their resolver does not log IP addresses. For remote workers, Cloudflare's strong peering with major cloud providers means fast lookups for Microsoft 365, Google Workspace, and AWS-hosted tools. The primary addresses are 1.1.1.1 and 1.0.0.1.

Google Public DNS 8.8.8.8

Google's DNS resolver averages around 20 milliseconds globally and has excellent uptime. Google supports DNS-over-HTTPS and has strong infrastructure in North America and Asia-Pacific. For remote workers using Google Workspace, Google's DNS resolver has a natural advantage since it shares Google's network infrastructure. The primary addresses are 8.8.8.8 and 8.8.4.4.

Quad9 9.9.9.9

Quad9 blocks known malicious domains by default, adding a layer of security without requiring additional software. For remote workers concerned about phishing and malware, Quad9 provides DNS-level threat protection. Response times average around 20 to 30 milliseconds. Quad9 supports DoH and DoT and is operated by a nonprofit. The primary addresses are 9.9.9.9 and 149.112.112.112.

NextDNS

NextDNS goes beyond basic DNS resolution. It provides ad blocking, tracker blocking, malware protection, and customizable allow/block lists. For remote workers who want fine-grained control over their DNS traffic — including per-device policies and detailed analytics — NextDNS is the most flexible option. It supports DoH and DoT and operates on a free tier with generous limits.

OpenDNS (Cisco Umbrella)

OpenDNS has been a reliable public DNS resolver for years and is backed by Cisco's security infrastructure. It provides optional content filtering and phishing protection. For remote workers in enterprise environments, OpenDNS integrates well with Cisco Umbrella's corporate security stack. The primary addresses are 208.67.222.222 and 208.67.220.220.

Run our DNS speed test to compare these providers from your specific location. The fastest resolver depends on your geography, your ISP's peering arrangements, and the time of day. What works best in New York may not be the fastest option in Singapore.

Split DNS Configuration

Split DNS is the practice of sending DNS queries for internal corporate domains to your company's DNS servers while sending all other queries to a fast public DNS resolver. Without split DNS, your VPN client routes every DNS query through the corporate network, even for unrelated services like Google, YouTube, or news sites. This adds unnecessary latency to your browsing because every lookup travels through the VPN tunnel and back.

With split DNS enabled, your device maintains two DNS configurations. When you type intranet.company.com, your device knows to send that query to the corporate DNS server through the VPN. When you type google.com, your device sends that query to Cloudflare or Google DNS on your local network. The result is fast resolution for external services and correct resolution for internal resources.

Most modern VPN clients support split DNS natively. Cisco AnyConnect, Palo Alto GlobalProtect, Fortinet FortiClient, and OpenVPN all have configuration options for split DNS. Typically, your IT department configures this when they deploy the VPN. If you are experiencing slow internet while connected to VPN, ask your IT team whether split DNS is enabled. Many corporate VPN deployments route all DNS through the tunnel by default, even when split DNS would be more appropriate.

For technically inclined remote workers, you can check your DNS routing by running nslookup internal.company.com while connected to VPN and then nslookup google.com while connected. If both resolve quickly, split DNS is likely working. If the second lookup is noticeably slower than the first, your DNS is probably being routed through the VPN tunnel unnecessarily.

Corporate DNS vs Public DNS

Corporate DNS servers are designed for one purpose: resolving internal hostnames. They know about your company's file servers, intranet applications, database clusters, and internal APIs. They do not have global anycast networks, CDN peering, or the kind of performance optimization that public DNS resolvers provide. Using corporate DNS for all your internet traffic is like using your company's internal phone system to call pizza delivery — it works, but it is not what it was built for.

Public DNS resolvers like Cloudflare and Google are built for performance. They operate thousands of servers worldwide, use anycast routing to direct queries to the nearest server, and maintain extensive peering relationships with content delivery networks. When you resolve slack.com through Cloudflare, the response comes from a server near you with minimal latency. When you resolve it through your corporate DNS server in another country, the response takes a longer path.

The security trade-off is worth discussing. Corporate DNS servers may apply security policies like blocking known malicious domains or logging DNS queries for audit purposes. Public DNS resolvers may or may not provide equivalent security features depending on which one you choose. Quad9 blocks malicious domains by default. Cloudflare and Google do not, but they support DNS-over-HTTPS which encrypts your DNS traffic and prevents your ISP from seeing which domains you visit.

The practical recommendation for most remote workers: use split DNS. Route internal corporate domains through your company's DNS server via VPN. Route everything else through a fast public DNS resolver. This gives you the internal resource access you need from corporate DNS and the performance benefits of public DNS for everything else.

Setup Guide: Configuring DNS for Remote Work

Setting up optimized DNS for remote work takes less than five minutes and requires no special tools. Here is how to configure your system for the best remote work experience.

Step 1: Run a DNS Benchmark

Before changing anything, measure your current DNS performance. Run our DNS speed test to see how your current resolver compares to alternatives. Test with and without your VPN connected to understand the full picture. Note the response times for the top-performing servers.

Step 2: Choose a Fast Public Resolver

Based on your benchmark results, pick the fastest resolver for your location. For most people, Cloudflare 1.1.1.1 or Google 8.8.8.8 are the best choices. If security is a priority, consider Quad9 9.9.9.9. If you want ad blocking and customization, look at NextDNS. You will need two addresses: primary and secondary.

Step 3: Configure Your Operating System

On Windows 10 or 11, open Settings, go to Network & Internet, click your connection (Wi-Fi or Ethernet), then click Edit next to DNS server assignment. Switch to Manual, enable IPv4, and enter your chosen DNS addresses. On macOS, open System Settings, go to Network, select your connection, click Details, then DNS, and add your chosen servers. On Linux, edit /etc/resolv.conf or use nmcli to set DNS on your network connection.

Step 4: Enable DNS-over-HTTPS

If your operating system supports it, enable DNS-over-HTTPS (DoH) for encrypted DNS queries. On Windows, this is available in the DNS settings under "Encrypted only (DNS over HTTPS)." On macOS, it is available in the DNS settings as "Limit IP address tracking." On Firefox, you can enable DoH in Preferences under Privacy & Security. Encrypted DNS prevents your ISP from seeing which domains you visit and protects against DNS manipulation.

Step 5: Configure Split DNS for VPN

If you use a VPN for work, check with your IT department about split DNS configuration. If you manage your own VPN or are technically inclined, most VPN clients allow you to specify which domains are resolved by corporate DNS and which are resolved by your local DNS. In OpenVPN, this is done with the dhcp-option DNS directive. In WireGuard, you can use the DNS directive for internal domains and leave other traffic to use your system DNS.

Step 6: Test and Verify

After making changes, run the DNS speed test again to confirm your new resolver is faster. Test your VPN connection to make sure internal resources still resolve correctly. Check that video calls connect smoothly and cloud apps load quickly. If anything breaks, revert your changes and try a different resolver or configuration.

Frequently Asked Questions