Looking at rolling out Umbrella DNS across our remote workforce. Main concern is adding latency to real-time apps like Teams, Zoom.
Has anyone actually measured the impact?
* Baseline latency to Umbrella POPs vs direct DNS
* Any noticeable packet loss or jitter introduced?
* Differences between roaming client vs on-network VA?
Our current setup is split-horizon DNS, and I'm skeptical about adding another hop. Need hard numbers before committing.
Good question. We did some ad-hoc testing with Zoom calls when we rolled it out last year.
The latency hit depends heavily on which Umbrella POP your clients get routed to. In our region, most folks got 8-12ms added for the DNS lookup itself. Not huge, but it's there. The bigger surprise was jitter - we saw occasional spikes of an extra 30-40ms, maybe from POP load or traffic steering. It wasn't enough to break calls, but people on marginal home connections sometimes complained.
Roaming clients had a worse time than our VA users, probably because their path to the POP was less predictable. If you've got split-horizon already, the added hop for internal resolution can feel like a step back. I'd run a pilot with a few typical remote users and `ping`/`dig` from their machines for a week. The numbers vary so much by location.
Clean code, happy life
The split-horizon setup is the key detail that makes this challenging. Our measurements found that the real impact wasn't the DNS latency itself, but the change in DNS resolution path for internal resources.
When a client using the Umbrella roaming module queries an internal hostname, that request often tunnels back through an Umbrella POP to your internal resolvers, rather than hitting them directly. This introduced a geographically variable round-trip before the actual connection even began. For real-time applications already establishing media streams, that initial delay and the potential for suboptimal routing mattered more than the POP's processing time.
I'd recommend you test by simulating exactly that flow. Compare `dig` times for your critical internal conferencing endpoints with and without the client, and then trace the media path after resolution. The numbers for external DNS look benign, but the internal resolution loop can be surprising.
Data is the new oil – but only if refined
The jitter point user480 mentioned is the real killer for video. We've seen that too. What surprised us was it wasn't the Umbrella DNS hop itself, but the way it influenced the actual media path after the lookup. The client gets an IP from the POP, but if that POP's routing is different than your ISP's default, you can land on a congested path for the video stream. That's where the packet loss creeps in.
Your split-horizon setup makes this even trickier. You'll now have internal queries taking a scenic route through a POP before coming home, adding a variable delay before a call even starts. That initial setup lag feels worse than a constant 10ms.
Data over dogma.