Skip to content
Notifications
Clear all

My results after enabling DNS encryption (DoH) for all internal users.

1 Posts
1 Users
0 Reactions
3 Views
(@migration_warrior_2024)
Trusted Member
Joined: 3 months ago
Posts: 30
Topic starter   [#1097]

Alright folks, buckle up. I just finished a six-week project to roll out DNS-over-HTTPS (DoH) for our entire internal user base (~1200 users) using Cisco Umbrella, and I have to say, the results are more nuanced than I expected. I'm a migration nut, so I dove into this wanting to replace our legacy, unencrypted DNS forwarders with something more secure and manageable. Umbrella seemed like the perfect fit, given our existing investment.

My goal was straightforward: encrypt all DNS queries leaving our corporate network to prevent snooping and manipulation, while leveraging Umbrella's security filtering. The journey, however, involved a few more twists and turns than the sales sheet might suggest.

Here's the high-level game plan I followed:

1. **Policy & Grouping:** Created specific DNS policies in Umbrella for different user groups (e.g., finance, engineering, general staff). This was crucial for granular reporting and safe-listing.
2. **Deployment Method:** We opted for the **Umbrella Roaming Client** on all managed devices. For our unmanaged/IoT devices, we pushed the DoH/DoT settings via DHCP/DNS configuration on our internal servers to point to `dns.umbrella.com`.
3. **Testing & Rollout:** Piloted with IT, then a department, then a full office location before going global. Rollback strategy was key—had GPOs and scripts ready to revert the Roaming Client settings in minutes.

### The Good (The "Win" Column)

* **Visibility is fantastic.** The Umbrella dashboard now gives us a crystal-clear, encrypted view of *everything*. No more DNS queries vanishing into the plaintext void.
* **Security policies hold.** All our blocking and allowed lists worked seamlessly over DoH. The user experience for blocked pages (with the Umbrella block page) remained consistent.
* **Performance was a net positive.** After some initial hiccups (see below), latency actually *improved* for many external domains because we're bypassing our sometimes-congested internal DNS resolvers and going directly to Umbrella's anycast network.

### The Gotchas & Pitfalls (The "Lessons Learned" Column)

This is where it gets interesting for my fellow migration warriors.

* **Internal DNS Resolution Breaks.** This is the big one. The Roaming Client, by default, will send **ALL** DNS queries, including those for your internal `corp.mycompany.com` resources, to Umbrella. Umbrella can't resolve your private IPs.
* **Fix:** You **must** configure the Roaming Client's "Split DNS" or "Internal Domain" settings. We used a GPO to push this XML configuration:
```xml

.corp.mycompany.com
.internal.net

10.1.1.10

```
* Without this, internal apps, printers, and servers become unreachable by name.

* **Application-Specific Quirks:** Some older, stubborn applications (looking at you, certain legacy Java apps) don't respect the OS's DNS settings and do their own DNS lookups. These will bypass Umbrella's DoH. You'll need firewall rules to force DNS traffic (UDP/TCP 53) only to your internal resolvers, which then forward to Umbrella.

* **The "Unknown" User Problem:** Initially, a huge chunk of our traffic showed as "Unknown" in the dashboard. This was because devices weren't properly authenticating to the Roaming Client.
* **Fix:** We had to ensure our deployment script or GPO also pushed the organization's unique token correctly and triggered a service restart. Double-check your identity collection settings.

### Data Quality & Rollback

The reporting shift is profound. You're now comparing a complete dataset (DoH) to an incomplete one (legacy DNS). It looks like a massive spike in queries to certain categories, but it's mostly just you now seeing the full picture. Deduplication in reports is still solid.

Our rollback strategy was tested once. A script that stops the Umbrella service, removes the registry/config settings, and flushes DNS caches had us back to legacy DNS in under 5 minutes per machine. **Always have an exit plan.**

**Final verdict?** A resounding success for security and visibility, but it's not a "flip-a-switch" migration. It's a proper infrastructure project with configuration nuances that will bite you if you don't plan for them. The internal DNS split is the single most critical detail to get right. Would I do it again? Absolutely—but I'd budget more time for testing those internal domain exclusions.


Backup twice, migrate once.


   
Quote