Latest / The Windows Podcast with Fexingo: Microsoft, PC, and Enterprise Windows Conversations / Windows 11 Quietly Mandates Enterprise Secure DNS Configuration
Transcript
- Lucas: If you manage Windows 11 machines in an enterprise environment, there's a quiet policy change that might already be breaking your DNS resolution — and a lot of IT admins haven't noticed it yet. Luna: I'd guess we're talking about Secure DNS, right? The DoH and DoT settings that started showing up in more recent Windows 11 builds? Lucas: Exactly. Specifically, Microsoft has been gradually shifting the default behavior under Group Policy so that when you configure a DNS server via policy, Windows 11 now tries to negotiate an encrypted connection first. If the server doesn't support DoH or DoT, the fallback isn't automatic anymore. Luna: And that fallback behavior is the part that caught people off guard. I've seen forum posts where admins say DNS just stopped working on certain machines after a cumulative update. Lucas: Right. The policy path is under Computer Configuration > Administrative Templates > Network > DNS Client. There's a setting called 'Configure DNS over HTTPS name resolution policy.' It's been there for a while, but the default state changed. In earlier versions, if you didn't touch it, DoH was off. Now, if you push any DNS server address via policy — say, pointing to your internal domain controller — Windows 11 assumes you want encryption. And if that server doesn't support it, queries can time out. Luna: So it's not that Microsoft flipped a switch that says 'all DNS must be encrypted.' It's more that they changed the assumption when a policy is active. That's subtle. Lucas: Subtle and dangerous, because most on-premises DNS servers — especially domain controllers — don't support DoH or DoT out of the box. You have to enable it manually, and many enterprises haven't. So what happens is: a machine gets a policy update, tries to reach the DNS server over port 853 or via HTTPS, gets no response, and then the fallback logic waits. And during that wait, name resolution stalls. Luna: How long does the fallback take? Is it a few seconds or long enough to break user experience? Lucas: From what I've seen, it can be several seconds per query. If you're loading a page that needs ten DNS lookups, that's thirty seconds of delay. Users think the network is down. Helpdesk tickets spike. And the fix isn't obvious because the policy itself is working as designed — it's just that the design changed. Luna: So what's the recommended path for an admin who wants to avoid this? Does Microsoft expect everyone to stand up a DoH proxy in front of their domain controllers? Lucas: That's one option. You can deploy a DNS server that supports encrypted connections — Windows Server 2022 and later do support DoH natively. Or you can put a forwarder like Unbound or a commercial appliance in front. But the simpler fix is to set the policy explicitly. There are three modes: 'Allow', 'Require', and 'Disable.' If you set it to 'Disable' via policy, Windows 11 reverts to unencrypted DNS and the problem goes away. But that's a security trade-off. Luna: And I imagine some security teams are pushing for 'Require' because they see DNS encryption as a compliance checkbox. That's where the conflict with network ops starts. Lucas: Exactly. Network ops says 'our DNS infrastructure works fine.' Security says 'it's not encrypted, so it's a data leak path.' And Microsoft, by changing this default behavior, is effectively forcing that conversation. They're saying: if you're managing DNS via policy, you should also manage encryption. Luna: It reminds me of the BitLocker key escrow change they made a couple of years ago — where they started requiring recovery key backup to Azure AD if you used modern provisioning. Same pattern: Microsoft sets a new baseline, and if your environment isn't ready, things break. Lucas: That's the playbook. They quietly raise the floor. And for enterprises that are already aligned with Microsoft's security vision, it's a nudge. For others, it's a scramble. But here's the thing — DNS encryption is genuinely important. The IETF has been standardizing DoH and DoT for years, and major browsers already use it. Microsoft is just catching up on the OS side. Luna: Yeah, I think it's a good move long-term. But the rollout has been messy because they didn't communicate the change clearly. I've talked to admins who spent days debugging DNS timeouts before they found this policy. Lucas: And that's exactly why we're covering it today. If you're listening and you manage Windows 11 devices, check your DNS Client policy. Go to Computer Configuration > Administrative Templates > Network > DNS Client. Look for the DoH setting. If it's 'Not Configured' and you have DNS server addresses pushed via policy, you might already be affected. Set it explicitly — either to 'Disable' if you're not ready, or to 'Allow' if you want encryption with fallback. Luna: And if you want to test, you can look at the event logs. There's an event ID for DoH connection failures — I think it's in the microsoft windows dns client operational log. That'll tell you if queries are failing because of encryption negotiation. Lucas: Good point. The logs are your friend here. And one more thing — if you're on Windows 11 23H2 or later, this behavior is more aggressive. Microsoft has been tightening it with each feature update. So even if you tested on 22H2, the rules may have changed. Luna: It's fascinating how a single policy change can ripple through an entire organization. And it's another reminder that in enterprise IT, you can't ignore the quiet defaults. Lucas: Absolutely. And if this kind of deep-dive analysis is useful to you — the real-world implications of a policy shift — it's exactly the reason we keep this show ad-free and focused. We do it because we think these conversations matter, and listener support is what makes it possible. If you get value from episodes like this one, you can find us at buymeacoffee.com/fexingo. No pressure, just a sincere option for those who want to help. Luna: Yeah, we've had listeners tell us they've used these episodes to bring specific issues to their IT leadership. That's the kind of impact that motivates us. So thank you to everyone who's already contributed. Lucas: Alright, back to the technical weeds. One nuance I want to highlight: the policy applies per DNS server entry. So if you have multiple DNS servers in your adapter settings, Windows tries encryption on each one independently. That means a mixed environment — some servers supporting DoH, some not — can result in inconsistent behavior across the same machine. Luna: So an admin might see that one DNS server works fine, but the secondary server causes delays. That could be a nightmare to diagnose if you don't know to look at per-server encryption negotiation. Lucas: Exactly. And the fix for that is either to ensure all your DNS servers support encryption, or to disable the policy and rely on other security controls — like DNSSEC or network segmentation. There's no one-size-fits-all answer. Luna: I think the key takeaway is: don't assume 'Not Configured' means 'Disabled.' In Windows 11, 'Not Configured' increasingly means 'Default behavior,' and that default is shifting toward encryption. Lucas: That's the headline. And I'd add: test this in a pilot group before you roll out any cumulative update. Because the change isn't always in the update notes. It can be buried in a servicing stack or a configuration change that Microsoft considers 'expected behavior.' Luna: Good advice. So for next episode, are we going to look at how Windows 11 is handling certificate-based authentication for Wi-Fi? I've heard there's a new policy around that too. Lucas: That's a great idea. We'll dig into the eap tls changes and the new certificate revocation checks. Let's save that for next time.