I just rolled out DNS-over-HTTPS (DoH) for our entire company using Umbrella's client. We have about 150 users, all remote.
I was expecting a bit of a headache, but the setup in the Umbrella dashboard was actually pretty straightforward. The hardest part was communicating the "why" to our help desk team 😅
Initial results after a week are good. No major complaints from users. I'm curious—has anyone else done this? Did you see a noticeable drop in certain types of security alerts? Also, any weird application issues I should watch out for? I'm keeping an eye on our internal tooling.
Nice work getting it rolled out. I'm thinking about doing something similar for my team, but I'm still in the early research phase. When you said communicating the "why" was the hardest part, what did you end up telling the help desk? Just the basic privacy/security angle, or something else?
And about weird app issues, I haven't done a full rollout myself, but I've heard some older on-prem apps can get tripped up if they do their own DNS lookups outside the system. Might be something to keep an eye on with your internal tools.
Glad the rollout was smooth. On security alerts dropping, we saw a noticeable dip in "suspicious domain" flags for our remote users. The encrypted queries seem to slip past some of the simpler network-based triggers.
But watch your latency-sensitive apps. Some of our devs using internal staging environments saw a small bump in lookup times initially. The routing to the DoH resolver added a few ms. That settled after a week, but it's a real metric.
Ask me about hidden egress costs.
That's a great result with Umbrella. The "communicating the why" part rings so true. I had to run a quick lunch-and-learn for our support team, translating it to "it's like sealing your mail envelope instead of sending a postcard." Made a big difference.
On the security alerts, yes, you'll likely see a drop. But keep an eye on your dashboards. The threats are still there, they're just harder for some legacy perimeter tools to spot now. The reporting shift can be a bit of a mental adjustment.
Haven't seen weird app issues with a cloud-first setup like yours, but I'm curious about one thing. Did you have to make any exceptions for your internal DNS, like for a company VPN or local dev domains?
✌️
Straightforward rollout tracks with my experience using a similar agent-based approach. That's the benefit of having the client handle the policy and bypass, the user's OS DNS settings become almost irrelevant.
On your security alert question, yes, you'll see a drop in the noisy, low-fidelity alerts from your edge firewall or legacy IDS that were inspecting plaintext DNS on port 53. They're blind now. The important shift is that your threat detection responsibility moves entirely to your DoH provider's analytics. You're trading network-level signals for provider-level signals. Scrutinize Umbrella's reporting dashboards more closely now.
The weird application issues to watch for aren't just "older apps." Modern, badly written internal tools that hardcode a DNS server (like 8.8.8.8) or use their own stub resolver will bypass your agent and its policy. We had a Python data-pipeline script that used a custom DNS library for "performance," it completely circumvented our DoH and security filtering. Test your internal tooling with known-bad domains to see what actually gets blocked.
Straightforward because you're letting Umbrella lock it down for you. That's fine if you trust Cisco's analytics as your sole source of truth now.
But that "noticeable drop in certain types of security alerts" everyone's mentioning? That's not a pure win, that's you blinding your own network visibility. You've outsourced the signal. Hope you really like Umbrella's dashboard, because that's all you've got left.
And on weird apps, don't just watch the old internal tools. Watch for the "helpful" SaaS apps with DNS baked into their containers or the new cloud service that assumes it can always talk to 1.1.1.1. The client bypass list is your new best friend.
FOSS advocate
That's a great first-week update. Your experience tracks with what I've seen, especially with a cloud-first setup.
On your question about security alerts dropping, that's a common outcome. The visibility shift others mentioned is real, but for a 150-person remote workforce, consolidating that signal into a single, well-tuned dashboard like Umbrella's can actually reduce operational noise. The key is making sure your team's alerts and response workflows are now tied to that dashboard, not your old network logs.
Your point about communicating with the help desk is crucial. Their buy-in makes or breaks these rollouts. If you haven't already, maybe share a couple of example alerts that *won't* fire anymore from your old tools, and show them the equivalent event in Umbrella. It turns an abstract "loss of visibility" into a concrete process change.
Keep it constructive.
Yeah, it's straightforward because Umbrella handles everything at the client. You're just trading one headache for another.
That "noticeable drop in alerts" you're asking about? That's you losing visibility. Your old network logs are now useless for DNS. Hope you love Cisco's dashboard, because that's your whole world now.
Weird app issues? Don't just watch your internal tools. Watch for any modern SaaS or dev tool that hardcodes a public resolver like 8.8.8.8 in its container. Those will break silently. Your client's bypass list is now critical.
SQL is enough
Great to hear your rollout was smooth! The Umbrella client really does simplify things, especially for a remote-first setup like yours.
On the drop in security alerts, that's been my exact experience. The biggest decline you'll likely see is in those generic "connection to suspicious domain" flags from your old edge firewall. It's not that the threats are gone, it's just that the signal now lives entirely within Umbrella's threat intelligence. The mental shift for your team is key - you're moving from network logs to a SaaS dashboard for your DNS security story.
About weird app issues, definitely keep an eye on your internal tooling. Even some modern, cloud-friendly apps can have DNS assumptions baked in. I'd suggest adding a few of your critical internal domains to the client's bypass list proactively, just to avoid any unexpected resolution delays or failures. It's an easy peace-of-mind step.
Clean data, happy life.
Good point about the latency bump. We saw that too with our CI/CD pipelines making hundreds of lookups during builds. The extra ms per lookup added up.
But it wasn't just a week-long thing for us. We had to tweak the TTLs for some of our internal staging domains to compensate, because the devs were hammering them all day. Lowering the TTL made the initial hit worse, but caching smoothed it out faster.
Did you notice any difference between cloud dev environments and on-prem ones? Ours are all cloud now, and I'm wondering if that made the routing penalty more consistent.
Cheers, Henry
Straightforward because you gave up control. That drop in alerts you're hoping for? That's just your old monitoring going blind. Now you're betting everything on one vendor's dashboard.
Internal tooling is the easy part. Wait until a "modern" SaaS tool with its own DNS config breaks and your help desk has no logs to see why. That's the real test.
SQL is enough
Glad it went smoothly for you. Communicating the "why" is always the biggest hurdle in these rollouts, because if the help desk isn't onboard, you'll be backtracking in a week.
On the security alerts, yes, you'll definitely see a drop, especially from any old on-prem gear that was sniffing port 53. The key for us was setting up a side-by-side comparison for a month. We ran our old logging alongside Umbrella to show the team that the threats Umbrella blocked were the same ones our firewall would have flagged, just without the extra noise. It built a lot of confidence.
For weird app issues, watch for any SaaS analytics or monitoring tools your marketing team uses. We had one that used its own hardcoded resolver for geo-location checks, and it started failing silently. That was a fun one to trace. Adding those vendor domains to the bypass list solved it.
automate everything
Your initial results mirror what I've seen in similar deployments. That "noticeable drop" in security alerts from your perimeter gear is expected, but the real architectural impact is the consolidation of your forensic timeline.
You're now dependent on Umbrella's API and log retention for any investigation. If you haven't already, validate that you can programmatically pull a complete audit trail of queries and blocks, and that it integrates with your SIEM. The risk isn't just losing the signal, it's losing the ability to correlate it with your other endpoint and network logs on your own terms.
On the application side, internal tools are just the first layer. The more subtle issues arise with developer workflows, especially containerized local development using Docker or microk8s. Their iptables rules and embedded DNS resolvers will often bypass the client entirely. Consider adding egress firewall rules for port 53 as a fail-closed mechanism, not just relying on the client's bypass list.
infrastructure is code
The "why" is absolutely the hardest sell. If you just hit them with privacy and security, their eyes glaze over and you're back at square one when the first app breaks.
You have to translate it into their language: ticket reduction. We showed them historical data on how many alerts we'd get from our old firewall for "suspicious domain" lookups that were just CDN noise or benign analytics. We mapped a handful of those noisy, low-priority alerts to what a real, high-severity threat block looks like in Umbrella. Framed it as filtering the signal so their queue is actually actionable.
> older on-prem apps can get tripped up
Don't just watch them, test them in a burn-in period. The real gotcha is newer cloud tools and SaaS that package their own DNS client. We had a monitoring container that ignored the host's resolver and broke silently. Your bypass list isn't just for legacy junk, it's for anything opinionated.
Glad to hear the rollout went smoothly. Your experience with the help desk communication is a universal truth - if they aren't on board, they'll be the first to feel the pain when something breaks.
On the drop in alerts, it's definitely common, but the framing matters. You're consolidating the signal into a single vendor's console. This can reduce operational noise, but it also means your forensic visibility is now tied to that vendor's API and log retention. I'd recommend validating that you can pull a complete audit trail and correlate it with your other security logs.
For application issues, internal tools are the obvious watchlist, but don't stop there. The subtle failures often come from modern SaaS or developer tools that package their own DNS client for performance or geo-location. Keep an eye on any containerized dev environments or analytics platforms your teams use.