Networking Blog articles

Secure DNS with DoH: Public Preview for Windows DNS Server

JorgeCañas — Tue, 10 Feb 2026 20:21:45 GMT

Credit and thanks to Arif Hussain, Jay Ladhad, Kranthi Hasnabad, Sruthy TV, Manish Chaudhari and Rahul Bhadana for implementation work.

Your DNS just got a Zero Trust upgrade.

Today we’re opening the public preview of DNS over HTTPS (DoH) for Windows DNS Server, bringing encrypted, authenticated DNS to the heart of your on‑premises network. Turn it on, and the signals your business runs-on stop traveling in the clear. This is how you harden the backbone without disrupting what already works.

The Importance of Securing DNS

In today’s digital world, information is king and securing it is non-negotiable. With most data stored digitally and accessed remotely, network security is critical. At the heart of every network lies DNS, because everything depends on it.

However, the challenge is that DNS traditionally operates in the clear: queries and responses are exposed to anyone watching, giving attackers visibility into network details and user behavior, thereby creating opportunities for attacks.

How can we secure it?

IETF introduced two standards for encrypting DNS:

RFC 8484, DNS over HTTPS (DoH)
RFC 7858, DNS over TLS (DoT)

Each of these standards has pros and cons, but today we are excited to announce that we’ve introduced support for DNS over HTTPS (DoH), for client-side traffic, in Windows DNS Server, starting with the February 10^th 2026 monthly update of Windows Server 2025.

In a nutshell, DoH encapsulates DNS queries and responses inside HTTPS messages, which are encrypted via the TLS layer. This delivers two key benefits:

Authentication: Clients can verify the DNS server, preventing impersonation attacks. This is done through the server’s certificate validation process inherent to TLS clients.
Privacy: Queries and responses are encrypted in transit, shielding them from prying eyes.

DoH support in Windows DNS Server is complementary to the broader Zero Trust DNS efforts already introduced on Windows clients. Together, these capabilities enable organizations to adopt encrypted, authenticated DNS across both endpoints and on-premises infrastructure, creating a consistent security foundation aligned with modern Zero Trust principles. For U.S. Federal agencies, this end-to-end encryption model directly supports requirements in OMB Memo M-22-09, which mandates the use of encrypted DNS protocols, such as DoH, across both resolvers and endpoints to strengthen cybersecurity posture.

For more information on Zero Trust DNS, read the blog at: Zero Trust DNS is Here: Elevating Enterprise Security on Windows 11 | Microsoft Community Hub.

What behavior can I expect with DoH?

Enabling DoH on Windows DNS Server will encrypt all queries received and all responses sent on the port used for DoH (by default: 443). However, any queries sent out by the Windows DNS Server towards an upstream DNS server (e.g. conditional forwarder, authoritative server) will not be encrypted and will remain on port 53. Support for encrypting queries towards an upstream forwarder or resolver will be in preview at a later date, while encrypted queries towards an authoritative server is to be determined pending standardization by IETF.

If you decide to retain UDP/TCP port 53 enabled on Windows DNS Server, for client-side traffic, simultaneously as you have DoH enabled, the traffic on port 53 will continue to be handled as-is by the Windows DNS server (ie. unencrypted).

All the functions and capabilities administrators rely on for day-to-day management of the DNS server are retained. So, functions such as name resolution behavior, zone management, forwarding logic, etc. are intended to continue to operate exactly as they always have. The DoH feature does not change or disrupt existing Windows DNS Server functionality, but it does introduce new PowerShell commandlets, new events and new performance counters to enable management of the DoH feature.

Getting Started

Note: DNS over HTTPS (DoH) on Windows DNS Server is currently available in Public Preview and is intended for evaluation and feedback only. It is not supported for production use as bugs may be present. Functionality may also change, including potential breaking changes, before General Availability (GA).

The public preview of DNS over HTTPS (DoH) is included in the February 10^th 2026 update of Windows Server 2025 and is disabled by default.

To enable the feature during this preview period request access here. Then head over to DNS over HTTPS Overview and unlock the full story behind the feature.

Your journey into encrypted DNS starts now!

Reporting feedback

We value your feedback! Your feedback is crucial for us as we get to work towards our General Availability release.

If you have questions or general feedback on this preview we’d love to hear from you! Feel free to comment in the section below this blog. Or see below for reporting bugs and feature suggestions.

Reporting bugs or Feature suggestions

From your Windows Server 2025 machine:

Search for Feedback Hub in Start Menu and launch the app.
From the ‘Home’ section of the app, click the “Report a problem” or “Suggest a feature” button.

In the section ‘1. Enter your feedback’, find the ‘Summarize your feedback’ textbox and start your feedback by prepending the text ‘[DoH]’ to it to help our team triage feedback. Enter any additional comments and details in the ‘Explain in more detail’. Click Next.
In the left drop box of section ‘2. Choose a category’, choose Windows Server and on the right dropdown box, choose DNS Server. Click Next.

Note: If you are advised that no similar feedback could be found, Click Next again.

Fill out Section 4 and click Submit.

Resolve-DnsName vs. nslookup in Windows

JamesKehr — Thu, 08 Jan 2026 15:25:12 GMT

Oh boy, here we go again. The last time I talked about a networking tool, the infamous iPerf3 article, I kicked up a hornet’s nest online. This one should not be controversial. I hope.

The choice of tool you pick to diagnose name resolution, such as DNS, inside Windows can impact the accuracy of your troubleshooting. This article is going to discuss the option every Windows admin knows, nslookup, versus the newer kid on the block, PowerShell’s Resolve-DnsName.

nslookup: The tool we know and love!

nslookup is typically the go-to option for Windows admins when doing name resolution. It works, it works everywhere, and it works (mostly) well. But, because these articles always have a but, it has some quirks that you may not be aware of.

nslookup is a standalone executable which operates independently of the Windows DNS client resolver (DNS-CR). What does this mean?

When an application inside Windows resolves a computer or a domain name, like mapping a drive in File Explorer, it makes one of a handful of API calls. Those API calls will almost always end up at DnsQueryEx(). Nslookup does not use DnsQueryEx(). It does not make any name resolution Windows API calls. This is both good and bad.

The good part? When no Windows-centric troubleshooting is involved, and you just need to resolve an IP address from a DNS server, then nslookup is great. Or, if you suspect that the Windows DNS client resolver (DNS-CR) is acting up, use nslookup! When nslookup works but a Windows process does not, then there is a good chance that there is a Windows, DNS policy, or endpoint protection related issue.

The bad part means that nslookup does not match the name resolution behaviors used by Windows roles, features, services, apps, and most programs running on Windows. This can lead to false results, depending on the type of name resolution troubleshooting you are performing. The biggest gotcha here is that nslookup requires formal dot termination on multi-label names to signify the root domain.

I understand those are words… what do they mean in this order?

A label, in DNS terms, is a portion of a domain name. When there is only one label, it is called a single-label name. This is more commonly known as a short, NetBIOS, or host/computer name. Think of it as a device’s network name without an attached domain. A multi-label name is a DNS name with more than one label. We are imaginative with naming in the network space. This is also known as the Fully Qualified Domain Name (FQDN) or the "website" or domain part of a URL – for example, learn.microsoft.com in the URL: learn.microsoft.com/powershell/module/dnsclient/resolve-dnsname

Each label is separated by a dot, or period. And, when being super technical, a multi-label name or FQDN should be terminated by a dot. While this is no longer standard practice, nslookup expects FQDNs to be dot terminated. nslookup will append every defined DNS search suffix to an unterminated query before it tries the FQDN by itself. This is great for single-label names, and not so great for multi-label names because too many DNS suffixes can cause a timeout.

Fig. 1 – A screenshot of the Windows DNS suffixes used in this example.

Imagine you want the IP addresses used by bing.com. The system's DNS suffix search list contains contoso.com, fabrikam.com, adatum.com, and northwindtraders.com. You enter "nslookup bing.com" without dot termination and get a DNS timeout error. You start Wireshark, try again, and see the following DNS queries:

Fig. 2 - Trimmed Wireshark output of "nslookup bing.com" from this example.

Standard query 0x0002 A bing.com.contoso.com Standard query 0x0004 A bing.com.fabrikam.com Standard query 0x0006 A bing.com.adatum.com Standard query 0x0008 A bing.com.northwindtraders.com Standard query 0x000a A bing.com

Then you remember the lessons learned in this article and enter "nslookup bing.com." and you get the IP addresses you expect. The Wireshark trace now shows no unexpected queries.

Other nslookup Quirks

Here are other nslookup quirks you should know about. The first is that nslookup only uses DNS servers for name resolution. The Windows DNS-CR will use the hosts file, DNS client cache, WINS, NetBIOS Name Services, LLMNR, multicast DNS (mDNS), and DNS servers. That's quite a difference in name resolution options.

LLMNR and NetBIOS are going away in the future, in case you have not heard. As is WINS (finally!). Even so, that leaves mDNS, hosts, local cache, and any future name resolutions options added to Windows.

Second, nslookup does not support newer DNS encryption technologies like DNS over TLS (DoT), DNS over HTTPS (DoH), and so on. Therefore, using nslookup could be a security violation in certain environments as it would cause unencrypted traffic on the network. Granted, this functionality can be added in a future update, but there are currently no plans to do so. Resolve-DnsName will leverage DoT and DoH when the Window DNS client is configured to use secure DNS.

Nslookup does not honor DNS policies like the NRPT (Name Resolution Policy Table). A Windows process using DNS-CR will use all system defined DNS policies. Nslookup ignores DNS policies, queries only the system defined DNS servers, and may fail or provide inaccurate results on systems using the NRPT and other DNS policies. This does make nslookup handy when troubleshooting whether DNS policies are working.

The last quirk is DNSSEC, which has its own section later in the article.

Resolve-DnsName: The Windows-Centric Approach

Resolve-DnsName is a PowerShell cmdlet which leverages the Windows DNS-CR by making direct DnsQueryEx() API calls. The use of DnsQueryEx() is what gives the cmdlet all the name resolution options available in Windows. This means that Resolve-DnsName results are Windows accurate name resolution behavior. In other words, if you want to test how a program in Windows does name resolution, then Microsoft recommends using Resolve-DnsName.

Resolve-DnsName provides several versatile options, such as testing queries against only DNS servers (-DnsOnly), bypassing the hosts file (-NoHostsFile), using only the local cache (-CacheOnly), and using only multicast resolvers like mDNS (-LlmnrNetbiosOnly). These parameters make Resolve-DnsName the ideal choice for diagnosing complex name resolution issues in Windows environments.

No dot termination is needed; in case you were wondering. And Resolve-DnsName is much easier to use with PowerShell automation and scripting.

Examples

Here are a few examples for you. Both Resolve-DnsName and nslookup examples are provided, where applicable.

Example 1: Query using DNS only to Cloudflare's public DNS server.

Resolve-DnsName bing.com -DnsOnly -Server 1.1.1.1

nslookup.exe bing.com. 1.1.1.1

This will send a DNS query to 1.1.1.1 asking for the IP addresses of bing.com. By default, both host record types, A (IPv4) and AAAA (IPv6), are requested. Nslookup can do this by entering the DNS server's IP address after the query.

Example 2: Use Cloudflare public DNS to get bing.com AAAA (IPv6) records.

Resolve-DnsName bing.com -Server 1.1.1.1 -Type AAAA

nslookup.exe -type=AAAA bing.com. 1.1.1.1

Same as example one, but without IPv4 addresses.

Example 3: Query a printer over mDNS.

Resolve-DnsName printer01.local -LlmnrNetbiosOnly

Ignore the fact that the parameter says LLMNR. Think of it as -LocalOnly. This parameter uses all broadcast and multicast name resolution methods enabled on Windows and ignores the DNS servers, cache, and the hosts file. Nslookup has no local name resolution capabilities.

Example 4: Perform a DNSSEC query

Resolve-DnsName example.com -DnssecOk

Speaking of DNSSEC…

DNSSEC

nslookup is not DNSSEC aware. For any DNSSEC-related diagnostics, Resolve-DnsName should be your tool of choice in Windows. There are two options to enable DNSSEC: -DnssecCd and -DnssecOk.

Explaining DNSSEC is a wheel I do not intend on reinventing. Here is a series of articles for those who are interested in how DNSSEC works and how to use Resolve-DnsName to test.

https://learn.microsoft.com/en-us/windows-server/networking/dns/dnssec-overview

But It’s So Many Letters!

I know, right! These PowerShell cmdlets names can be long. Go look at some of the Microsoft Graph cmdlet names. Phew!

Let me introduce you to PowerShell profiles and aliases! An alias allows you to create a shortened command. The alias command can be stored in a PowerShell profile. The alias is then added to PowerShell automatically when the profile script runs during session start.

The alias can be rdns (short for Resolve-DnsName), dig (my favorite), or even nslookup. PowerShell can use both an nslookup alias and the nslookup program at the same time. Type nslookup.exe to use the program, and nslookup to use it as an alias of Resolve-DnsName.

Best Practices for Windows DNS Client Troubleshooting

For Windows name resolution troubleshooting, testing, and automation, Resolve-DnsName offers a Windows accurate, easier to use experience with more features and controls. Nslookup is still great for basic DNS resolution, and to test certain situations where you suspect there is a Windows DNS-CR or DNS policy issue.

Learning the fundamental differences between nslookup and Resolve-DnsName will help you avoid common pitfalls and ensure your name resolution troubleshooting efforts are efficient, accurate, and reliable.

A Note About Browsers

It turns out that nslookup is not the only independent DNS resolver on your computer. All major browsers now have a secure DNS option. Last I checked, secure DNS is enabled by default on non-managed systems. A browser with secure DNS enabled will first try to resolve a domain’s IP address by using DNS over HTTPS (DoH) or DNS over TLS (DoT). Browsers use public DNS servers when performing secure DNS.

A plain packet capture will not be able to parse the secure DNS traffic because it will be encrypted. Which is the whole point of secure DNS. The Windows DNS client cache will likewise not contain the browser's secure DNS query results. There are Active Directory and Intune policies which force the big three browsers to use Windows system DNS to avoid unauthorized DNS access.

The Windows 11 DNS client has had support for DoH and DoT for a while now. As for DNS over HTTPS support on Windows DNS Server…stay tuned to the Tech Community Networking blog. Specifically in the February 2026 timeframe.

An Ode to dig Before I Go!

Oh BIND, oh BIND, why have you forsaken Windows? I miss my dig. Yes, I do. I guess WSL2 will have to do.

Announcing General Availability for AccelNet on Windows Server 2025

Basel_Kablawi — Tue, 18 Nov 2025 16:40:29 GMT

Customers tell us two things about modernizing their datacenters: every CPU cycle counts, and predictable latency beats peak throughput.

That’s why we’re bringing Accelerated Networking (AccelNet), the same technology used in Azure, to Windows Server 2025 Datacenter. With AccelNet, you can run more VMs per host, deliver consistent performance, and free up CPU for what matters most: your workloads.

Why Accelerated Networking?

Traditional networking paths route packets through the virtual switch, consuming CPU cycles and introducing variability. This overhead can mean unpredictable performance. Accelerated Networking (SR‑IOV) for Windows Server 2025 Datacenter solves this by:

Bypassing the virtual switch for data plane traffic using SR‑IOV, reducing CPU overhead.
Lowering latency and jitter, delivering predictable performance for critical workloads.
Freeing CPU cycles for compute, so you can maximize VM density per host.

AccelNet delivers near line‑rate throughput while dramatically reducing host CPU overhead for Hyper‑V workloads. Built to work seamlessly with Hyper‑V features and Failover Clustering, AccelNet lets you modernize without sacrificing resiliency or manageability. Additionally, because it’s based on the same principles that power Azure networking, you get a consistent operational model across hybrid environments, ensuring predictable performance wherever your workloads run.

AccelNet shines in scenarios such as:

Transactional and OLTP workloads
High-speed in-memory caching layers
Traffic between VMs in scale-out architectures
Dense virtualization environments with many VMs per host

AccelNet isn’t just about enabling SR‑IOV, it’s about making it simple, scalable, and consistent across your cluster. Traditionally, configuring SR‑IOV meant manual cumbersome setup for every NIC: driver checks, NIC SR-IOV support, consistency validation across the cluster, etc. which was a process prone to errors and drift. To solve this, Accelerated Networking comes with a guided Windows Admin Center experience and matching PowerShell cmdlets. You can enable AccelNet across a cluster in a few clicks, verify which hosts and VMs are enabled, and troubleshoot with clear, actionable checks.

How to Get Started

Enabling Accelerated Networking is straightforward:

Ensure a valid Azure Arc Pay-as-you-go subscription or Software Assurance license.
Confirm your adapters support SR‑IOV, are part of a Network ATC compute intent and are certified for Windows Server 2025 Datacenter.
Navigate to the "Accelerated Networking" tab on your Windows Admin Center cluster view, then select your configured intent and node reserve.
Once the cluster is enabled, you can now enable/disable AccelNet on one or more VMs at a time!

For a full guide, please refer to our Learn documentation: Accelerated Networking for Windows Server | Microsoft Learn

Summary

Accelerated Networking brings improved performance to Windows Server, reducing CPU overhead and improving predictability for your most demanding workloads. With intent driven enablement, you can deploy SR‑IOV at scale without complexity, thus unlocking higher VM density and consistent performance across your environment.

Ready to accelerate your network? Check out the official docs and start optimizing your cluster today!

For any questions, please reach out to us a edgenetfeedback@microsoft.com

Announcing Network HUD: Operational Network Monitoring for Windows Server 2025

Basel_Kablawi — Tue, 18 Nov 2025 16:39:42 GMT

Networking issues can disrupt workloads and lead to costly downtime. Network HUD brings real-time health monitoring to Windows Server clusters, helping you catch misconfigurations and drift before they impact performance. Now you can operate with confidence and keep your networking aligned to best practices.

Why Network HUD?

Managing host networking isn’t easy. Small misconfigurations, outdated drivers, or bandwidth oversubscription can quickly lead to performance issues or outages. Network HUD simplifies this by continuously monitoring your cluster’s networking health and surfacing actionable insights. It helps you:

Detect unstable adapters and PCIe oversubscription early
Identify incompatible or outdated drivers before they cause failures
Detect inconsistent storage issues with physical network (PFC/ETS)
Detect misconfigured network configurations (VLANs)
Ensures consistent checks across the cluster
Reduce troubleshooting time and support cases

Network HUD goes beyond the host level. It parses LLDP information from physical switches to validate configurations and detect mismatches. This integration ensures your fabric configuration aligns with your host configuration, reducing the risk of connectivity issues.

To learn more about Network HUD please refer to our Learn documentation: What is Network HUD for Windows Server? | Microsoft Learn

Consider an example scenario: A VM in your Windows Server cluster is unable to connect to the Internet, as its VLAN Configuration is incorrect. Without visibility, this VM might silently fail to reach external resources, causing application downtime or degraded performance. Network HUD detects this issue by parsing and matching VLAN settings configured on your switches and VLAN settings configured on your VMs. When it finds a mismatch, Network HUD surfaces an alert and informs you so you can take corrective action or prevent further misconfigurations across the cluster.

How to Get Started

Network HUD is delivered as an Arc extension for Windows Server clusters, enabling hybrid management and scale-out deployment. For a full guide, please refer to our Learn documentation: Install Network HUD for Windows Server (preview) | Microsoft Learn

Getting Network HUD up and running is simple:

Ensure all the servers in your cluster are Arc enabled
Navigate to Azure Portal
For each server in the cluster, click on the Network HUD tile, to enable the Network HUD Arc extension.
Once Network HUD is installed and enabled, your portal UI should look like this:

How to See Alerts

Now that Network HUD is setup, Network HUD surfaces health faults in multiple places:

Windows Admin Center (WAC): Navigate to the top right corner of your WAC Cluster Manager view and click on the bell icon to view alerts and faults.

PowerShell: Use Get-HealthFault on the Windows Server machine for operational and diagnostic logs.

Get-HealthFault -Cluster $cluster | Where Reason -like '*hud*'

Summary

Network HUD is your proactive networking assistant for Windows Server. By combining host-level diagnostics with physical switch insights, it helps you maintain a stable, high-performant environment. Whether you’re deploying new clusters or managing existing ones, Network HUD ensures you stay ahead of issues...before they impact workloads.

We can't wait for you to try out Network HUD!

For any questions, reach out to us at: edgenetfeedback@microsoft.com

Zero Trust DNS is Here: Elevating Enterprise Security on Windows 11

AditiPatange — Mon, 02 Feb 2026 21:57:32 GMT

When attackers target an enterprise today, they rarely begin with a blunt smash-through-the-front-door intrusion. They begin quietly by resolving a domain.

In most cases, modern malware, phishing kits, and human-operated ransomware operators rely on DNS as the entry point to discover infrastructure, beacon command-and-control, and exfiltrate data. Thus, it is becoming even more important to secure DNS to help protect against increasingly frequent, complex, and expensive cyberattacks.

Enterprises have invested heavily in Protective DNS services with cutting-edge threat intelligence to identify and block malicious domains in real time but if an endpoint device can simply bypass them, the entire Zero Trust posture is weakened.

Today, Microsoft is closing that gap.

Introducing Zero Trust DNS (ZTDNS)

We are excited to announce that Zero Trust DNS (ZTDNS) is now generally available on Windows 11 Enterprise and Windows 11 Education editions. ZTDNS is a new enterprise security feature in Windows that helps ensure DNS policy configured on the enterprise DNS server is enforced on the device. This is an important advancement for organizations working to enable that outbound connectivity on managed Windows devices aligns with enterprise authorization and policy.

ZTDNS provides device-level enforcement of an enterprise’s DNS policy, in-box on Windows 11 helping ensure devices only communicate with destinations the organization intends. It doesn’t require installing and managing additional agents or maintaining a “best effort” block list on each endpoint device. With ZTDNS, the enterprise DNS resolver becomes the policy source of truth and Windows becomes the enforcement point. For more information, check out our documentation.

This can be particularly useful for organizations in highly regulated industries, or where compliance with NIST standards is of paramount importance.

Without ZTDNS, the system DNS client could be pointed to a network-provided malicious DNS server, which can resolve unapproved domains and return incorrect resolutions to redirect the system to attacker’s endpoint. If the malicious DNS server uses encrypted DNS, IT administrators won’t be able to analyze the DNS traffic to prevent or mitigate potential attacks. Applications can use their own DNS client to completely bypass system policies. Also, system remains vulnerable to in-network attackers.

ZTDNS protects against these attack vectors by mandating the use of Windows DNS client and only sending encrypted DNS queries to the trusted DNS servers. Since ZTDNS blocks all outbound connections and local name resolution by default, the system is protected against in-network threats.

Why is ZTDNS needed?

In enterprise scenarios, DNS is no longer just a lookup mechanism but a policy decision point. However, without device-level enforcement, attackers can hijack device DNS to:

Redirect DNS queries from the device to a malicious or compromised DNS server
Use their own encrypted DNS client and bypass system DNS client
Bypass DNS completely with direct IP connections

In such cases, organizations lose the ability to control which network destinations the endpoint is allowed to reach even if a Protective DNS service is used.

ZTDNS addresses this by only allowing outbound connections to IP addresses that were resolved by the trusted DNS server for a query issued by the Windows DNS client. More importantly, it achieves this without terminating end-to-end encryption.

How does ZTDNS work?

ZTDNS integrates the Windows DNS client with the Windows Filtering Platform to help enforce domain-name-based network lockdown using encrypted DNS. ZTDNS is off by default and can be configured on a Windows 11 device with an enterprise-approved DNS over HTTPS (DoH) or DNS over TLS (DoT) server. When enabled, ZTDNS blocks all outbound IP-based connections by default and only allows outbound connections to IP addresses resolved by the trusted DNS server or those added to the manual exception list by the IT administrator. It mandates the use of encrypted DNS (DoH or DoT) and only trusts the DNS resolutions initiated by the Windows DNS client and answered by the trusted DNS server to create outbound allow exceptions.

This helps provide a strong, enforceable control that aligns with Zero Trust principles: all destinations are untrusted by default unless specifically permitted.

In a nutshell, when configured and enabled, ZTDNS will have the following effects on your Windows 11 device:

Encrypted DNS enforcement (DoH or DoT)
Default deny for outbound IPv4 and IPv6 traffic
Dynamic allow listing of IP addresses returned by trusted DNS servers
Static allow listing of IP addresses approved by the IT administrator via manual exceptions
Centralized logging of permitted and blocked connections

Deploying ZTDNS

ZTDNS is available in the latest builds of Windows 11 Enterprise and Windows 11 Education.

To deploy ZTDNS, enterprises can configure and enable it via:

netsh commands
JSON configuration

We are also actively developing a Microsoft Intune experience for ZTDNS and we will share more information when the details are available.

For detailed deployment guidance, check out our official documentation.

Connect with us

For customers attending Microsoft Ignite 2025, please join us at session BRK258: Inside Windows Security, from client to cloud to learn more about ZTDNS. Alternatively, you can also visit the Windows Resiliency Initiative & Windows Security booth to discuss ZTDNS in depth.

For customers who are unable to attend Microsoft Ignite 2025, we would still welcome the opportunity to connect. If you have questions about Zero Trust DNS, deployment considerations, or would like to share feedback from your evaluation, please contact us at ztdnsteam@microsoft.com.

Securing the Present, Innovating for the Future

Security is a shared responsibility. Through collaboration across hardware and software ecosystems, we can build more resilient systems secure by design and by default, from Windows to the cloud, enabling trust at every layer of the digital experience.

The updated Windows Security book is available to help you understand how to stay secure with Windows. Learn more about Windows 11 and Copilot+ PCs. To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters.

Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

Windows CLAT Enters Private Preview: A Milestone for IPv6 Adoption

JimAlumbaugh — Tue, 18 Nov 2025 15:27:02 GMT

IPv6 Adoption: A Global Shift

Since its standardization in the late 1990s, IPv6 has steadily gained traction. The last 15 years, especially since World IPv6 Launch Day in 2011, have seen significant progress. Global IPv6 adoption now hovers around 43 to 48%, with countries like France (80%), Germany (75%), and India (74%) leading the charge. The United States sits just above 50%, while others like China remain below 5%.

This shift is driven by the exhaustion of IPv4 addresses - only 4.3 billion were ever available. The rise of mobile devices, IoT, and cloud services has accelerated this depletion. Governments are responding: the U.S. Office of Management and Budget (OMB) mandates that 80% of federal assets operate in IPv6-only environments by the end 2025 (OMB M-21-07), and Germany has similarly prioritized IPv6 in its digital infrastructure plans (BDBOS IPv6 Programme).

Transition Mechanisms: From Tunnels to Translation

Over the years, various IPv4-to-IPv6 transition mechanisms have emerged:

Tunneling (e.g., 6to4, Teredo): Often unreliable due to NAT and relay dependencies.
Dual Stack: Effective but resource-intensive and not sustainable long-term.
Translation Technologies: Including NAT64 and DNS64, which enable IPv6-only clients to reach IPv4 services.

Among these, CLAT (Customer-side Translator) stands out as a key enabler of IPv6-only networks. It is part of the 464XLAT architecture, defined in RFC 6877, and combines:

CLAT: Stateless translation (SIIT, RFC 7915) on the client.
PLAT: Stateful NAT64 (RFC 6146) on the provider side.

Together, they allow IPv6-only clients to communicate with IPv4-only servers without requiring IPv4 connectivity on the client.

Listening to Our Community

In early 2024, the Windows Core OS Networking team ran an IPv6 migration survey. The results were clear: CLAT was the most requested IPv6 feature for Windows. This feedback helped shape our roadmap and reinforce our commitment to delivering CLAT support.

It’s Here: Windows CLAT Private Preview

It’s been over a year since we last updated our community on CLAT and today, we’re thrilled to announce that Windows CLAT is now in private preview. See below for details on how to participate in the preview.

How CLAT Works

CLAT eases transition to IPv6 by bridging IPv6 networks and IPv4 applications and servers. It leverages 464XLAT, which combines:

CLAT (Customer-side Translator)

Performs stateless IP/ICMP translation (SIIT, RFC 7915).
Converts private IPv4 addresses to global IPv6 addresses and vice versa.
Embedded in the client, Windows in this case.

PLAT (Provider-side Translator)

Performs stateful translation (NAT64, RFC 6146).
Converts global IPv6 addresses to global IPv4 addresses and vice versa.
Typically deployed on edge devices like routers.

CLAT Activation and Packet Flow

The activation of CLAT on a Windows client follows a logical sequence designed to ensure seamless IPv4 application support over IPv6-only networks:

Figure 1: CLAT Enablement & Prefix Discovery Options

1. IPv6-only connectivity: When the Windows client device initializes its network interface, it may find that no native IPv4 connectivity is available. Or, during DHCPv4 negotiation, the network may send Option 108, signaling that the host can operate in IPv6-only mode temporarily. While DHCPv4 Option 108 (RFC 8925) does not provide a NAT64 prefix, it indicates IPv6-only preference. This triggers the system to consider IPv6-only operation.
2. Discovery of NAT64 (PLAT) availability: The host then attempts to determine whether a NAT64 translator exists on the network and what its associated NAT64 prefix is. This discovery can occur through two mechanisms:
  - Router Advertisement (RA) PREF64 option (RFC 8781): The network router sends RA messages containing the PREF64 option, explicitly informing the host of the NAT64 prefix.
  - DNS-based discovery (RFC 7050): The host performs AAAA DNS queries for ipv4only.arpa using the networks recursive resolver. The response allows the host to infer the NAT64 prefix.
3. CLAT activation: Once the host confirms the presence of a valid PREF64, it enables CLAT. This ensures that IPv4-only applications can continue functioning even in an IPv6-only environment.
4. IPv4 address synthesized: CLAT plumbs a synthetic IPv4 address and IPv4 default route. This allows legacy IPv4 applications to connect as if native IPv4 were present.
5. Stateless IPv4-to-IPv6 translation: Each IPv4 packet generated by an application is intercepted by CLAT. Using the learned NAT64 prefix and the rules defined in RFC 6052, CLAT synthesizes an IPv6 destination address that embeds the original IPv4 address.
6. Routing to NAT64 (PLAT): The newly formed IPv6 packet is routed across the IPv6-only network to the NAT64 translator. The PLAT performs stateful translation, converting the IPv6 packet back to IPv4 and forwarding it to the intended IPv4 destination.

Figure 2: One example of CLAT Activation and Packet Flow

This flow ensures that even in environments where IPv4 is no longer natively available, legacy applications can continue to operate transparently over IPv6 infrastructure.

Looking Ahead: Building the Future of IPv6 with CLAT

The private preview of Windows CLAT marks a pivotal moment in our IPv6 journey. It’s not just a technical achievement, it’s a response to community demand, a step toward government compliance, and a foundation for future-ready networking.

We’re excited to collaborate with our partners and customers as we refine CLAT for general availability. If you’re interested in testing Windows CLAT in your environment, please sign up for Private Preview at aka.ms/winclatintake. Stay tuned for updates on Public Preview and thank you for being part of this milestone.

- The Windows Core OS Networking Team

Windows Server 2025 Software Defined Datacenter: Networking Deployment Series (4/6)

cindywan — Thu, 28 Aug 2025 18:35:07 GMT

Welcome to part four of our Networking Deployment Series for Windows Server 2025! In this series, we’ve been following Contoso Medical Center’s journey to deploy Windows Server 2025 Software Defined Datacenter (SDDC) for a modern, secure, and automated environment.

Thus far, Contoso has accomplished the following:

Part 1: Laid the foundation with consistent, automated host networking using Network ATC
Part 2: Introduced proactive diagnostics and monitoring with Network HUD
Part 3: Deployed Network Controller on Failover Cluster for a resilient SDN control plane

With the SDN “brains” now in place, Contoso is ready for the next step: securing every workload from day one with microsegmentation, automated security policies, and a Zero Trust approach.

From Reactive to Proactive: Securing Every VM by Default

As Contoso rapidly expands and adopts cutting-edge technologies to enhance patient care and operational efficiency, securing virtual workloads has become their top priority. Historically, they relied on manual firewall rules and static ACLs to protect virtual workloads. However, this reactive approach left gaps—new VMs could be deployed without the proper security policies, and enforcement often varied from host to host, increasing risk of human error.

With Windows Server 2025, Contoso can shift from reactive security to proactive, automated protection. SDN enables Contoso to secure every VM with microsegmentation, enforcing granular, VM-level network policies so that workloads only communicate when necessary. This approach is central to Zero Trust principles, treating every access request as potentially risky and requiring verification before granting permission. SDN microsegmentation leverages several key technologies:

Network Security Groups (NSGs): Every VM is automatically assigned an NSG at creation, providing immediate, distributed firewall protection for both north-south and east-west traffic.

Tag-Based Segmentation: Security policies are assigned based on workload identity, allowing rules to follow VMs as they move or scale rather than relying on static IPs.

Default Network Policies: Every VM receives baseline protection from the moment it’s created, even before the operating system is deployed, ensuring no workload is ever left exposed.

For a healthcare provider like Contoso where patient data and critical applications must be protected at all times, these SDN security capabilities in Windows Server 2025 deliver the automation, consistency, and compliance needed to confidently support rapid growth, safeguard patient data, and protect critical applications from day one.

What Are NSGs, Tag-Based Segmentation, and DNP?

Network Security Groups (NSGs)

An NSG is a 5-tuple firewall (source IP, destination IP, source port, destination port, protocol) that protects both north-south and east-west flows. NSGs can be applied to individual VMs or subnets, and because they’re enforced at the vSwitch, they scale without bottlenecks.

Key Advantages:

Granular control: block lateral traffic between workloads in the same VLAN or subnet
Multitenancy: policies can be unique per VM even if IP addresses overlap
Visibility: audit logging of all processed flows for compliance

Tag-Based Segmentation

Instead of managing policies based on network segments and IP ranges, tags let you label workloads with descriptive identifiers like “App = MedicalRecords” or “Env = Prod”. NSG rules can then reference these tags, allowing policy to follow the workload wherever it runs.

Key Advantages:

Simplifies policy creation — no more chasing IP changes!
Enables reusable security templates
Supports dynamic, intent-based enforcement

Default Network Policies (DNP)

DNPs ensure no VM is ever left without protection. When a VM is created (or even after it’s running), a default NSG is automatically applied based on your chosen security level:

No protection – no restrictions (not recommended)
Open some ports – block all inbound traffic except specified management ports, and allow all outbound traffic
Use existing NSG – apply a custom policy you’ve already created

Key Advantages:

Security starts before OS deployment
Prevents accidental exposure of new workloads
Works on both VLAN (logical) and SDN virtual networks

How Contoso Implemented These Capabilities

Using the Native SDN experience in Windows Admin Center, Contoso’s IT team:

Defined baseline DNP rules for all new VMs.
Created workload-specific NSGs for their medical and IoT apps.
Assigned security tags (i.e. App = Web, App = IoT) to VMs.
Linked NSG rules to tags to block cross-app communication where not required.
Monitored enforcement through Network HUD and audit logs for compliance evidence.

As a result, Contoso achieves immediate, consistent protection for all virtual workloads!

Why This Matters for You

With NSGs, tag-based segmentation, and DNP in Windows Server 2025 SDN, you can:

Apply Zero Trust inside your datacenter
Protect both new and existing workloads automatically
Simplify policy management for hybrid and dynamic environments
Meet compliance needs with built-in logging and monitoring

For Contoso, this means patient data, imaging workloads, and administrative systems are all protected from the moment they’re provisioned without relying on manual firewall rules or additional third-party tools.

Compatibility & Tooling

These capabilities are supported in:

Windows Server 2025 (Datacenter)
Windows Admin Center (latest version)
SDNExpress v2

Check out our video walkthrough to see SDN security in action on Windows Server!

What’s Next?

With robust workload protection now in place, Contoso is preparing to move forward with the next steps of their networking journey:

Enhancing mission-critical VM performance with Accelerated Networking to deliver high-throughput, low-latency connectivity and optimized network efficiency (coming in Part 5)
Ensuring seamless connectivity and resilience across multiple clusters with SDN Multisite, supporting disaster recovery and regional failover (coming in Part 6)

Stay tuned for our next post, where we explore Accelerated Networking and how it can boost performance for your most important workloads.

Try It Today!

Interested in trying out these capabilities on Windows Server 2025? Get started by exploring our step-by-step guide on creating and configuring Network Security Groups, Tag-Based Segmentation, and Default Network Policies.

Have feedback? Email us at edgenetfeedback@microsoft.com.

Windows Server 2025 Software Defined Datacenter: Networking Deployment Series (3/6)

Kyle_Bisnett — Mon, 28 Jul 2025 13:54:02 GMT

Welcome to part three of our Networking Deployment Series for Windows Server 2025. In this deployment series, we look at Contoso Medical Center’s journey deploying and harnessing the power of Windows Server 2025 Software Defined Datacenter (SDDC) to build a next-generation environment for your VMs and applications.

So far, Contoso has:

Part 1: Laid the foundation with consistent and automated host networking using Network ATC
Part 2: Introduced proactive diagnostics and monitoring with Network HUD

Now, it’s time for Contoso to bring Software Defined Networking (SDN) into their production environment—and to do that, they need a control plane that is resilient, clustered, and enterprise-grade. That’s where Network Controller on Failover Cluster (NC on FC) comes in.

From Lab to Life-Support: Contoso’s Leap to Production-Ready SDN

As a medical center with 24/7 uptime requirements, Contoso can’t afford downtime on critical services. In the past, they explored SDN capabilities, but the VM-based deployment model didn’t meet their standards. It required patching of the VMs, installation of Security agents, and a 45-minute installation time!

Now, with Windows Server 2025, Contoso can deploy Network Controller— the brains of SDN—on Windows Failover Cluster, unlocking the ability to run SDN production workloads in under 10 minutes, no VMs to patch, and so long as the hosts are patched, Network Controller is patched.

What Is Network Controller on Failover Cluster?

Network Controller is a key component in Windows Server SDN that:

Provides top-tier VM network security such as Network Security Groups (NSGs) and Default Network Policies (DNP), i.e., No VM is ever left behind without a Network Security Group.
As you onboard optional critical SDN services such as Virtual Networks, Software Load Balancer (SLBMUX) and Gateways, it ensures the goal state remains consistent and provides policy push to your hosts.
Maintains the intent of your software-defined network across hosts

With Failover Cluster support, Network Controller becomes:

Highly available—if one node fails, another picks up instantly
Stateful—configuration and operational state is replicated across nodes
More secure and manageable—via new deployment flows in WAC and SDNExpress

How Contoso Deployed It

Using Windows Admin Center (WAC), Contoso’s IT team followed the Native SDN deployment experience:

Created a Failover Cluster with a minimum of two nodes
Selected SDN Infrastructure in Windows Admin Center > Native SDN
Validated cluster health with built-in diagnostics and event tracing
Integrated with Azure Arc for hybrid monitoring and policy enforcement as needed

The result? A resilient SDN control plane, ready for production.

Why This Matters for You

With NC on FC, you can:

Deploy SDN in environments with uptime SLAs
Ensure control plane resiliency in case of node failures
Lay the groundwork for future SDN scale-out and multi-cluster scenarios
Meet compliance and enterprise IT standards for critical infrastructure

Whether you’re managing workloads in healthcare, finance, retail, or government—high availability is non-negotiable. This enhancement in Windows Server 2025 SDN bridges that gap.

Compatibility & Tooling

Network Controller on Failover Cluster is supported in:

Windows Server 2025 (Datacenter)
Windows Admin Center (latest version)
SDNExpress v2

For an in-depth deployment walkthrough, check out our step-by-step guide and demo video walk-through.

What’s Next?

With Network Controller now deployed in a VM-less model, Contoso Medical Center is ready to:

Protect every VM workload with Network Security Groups (NSGs) (coming in Part 3)
Use Tag-based Segmentation for medical workloads so that a new Admin and your compliance team can ensure every workload gets the right NSG! (coming in Part 3)
Onboard new VMs with Default Network Policies (No VM left behind) (coming in part 3)
…and eventually connect multiple sites using SDN Multisite (coming in Part 6)

Stay tuned for our next blog, where we show how SDN protects workloads with built-in VM policies and security enforcement—no agents, no extra products.

Try It Today

Interested in trying NC on Failover Cluster?
Check out the documentation: Windows Admin Center or SDNExpress
Check out the installation walk-through

Have feedback? Email us at edgenetfeedback@microsoft.com

Announcing the preview of Software Defined Networking (SDN) enabled by Azure Arc on Azure Local

Kyle_Bisnett — Fri, 11 Jul 2025 16:23:36 GMT

Starting in Azure Local version 2506, we’re excited to announce Public Preview of Software Defined Networking (SDN) enabled by Azure Arc. This release brings cloud-native networking capability of access control at the network layer using Network Security Groups (NSGs) on Azure Local.

Some of the key highlights in this release are:

1- Centralized network management: Manage Logical networks, network interfaces, and NSGs through the Azure control plane – whether your preference is the Azure Portal, Azure Command-Line Interface (CLI) or Azure Resource Manager templates.

2- Fine-grained traffic control: Safeguard your edge workloads with policy-driven access controls by applying inbound and outbound allow/deny rules on NSGs – just as you would in Azure.

3- Seamless hybrid consistency: Reduce operational friction and accelerate your IT staff’s ramp-up on advanced networking skills by using the same familiar tools and constructs across both Azure public cloud and Azure Local.

Software Defined Networking (SDN) forms the backbone of delivering Azure-style networking on-premises. Whether you’re securing enterprise applications or extending cloud-scale agility to your on-premises infrastructure, Azure Local combined with SDN enabled by Azure Arc offers a unified and scalable solution. Try this feature today and let us know how it transforms your networking operations!

What’s New in this Preview?

Here’s what you can do today with SDN enabled by Azure Arc:

✅ Deploy logical networks — use VLAN-backed networks in your datacenter that integrate with SDN enabled by Azure Arc.

✅ Attach VM Network Interfaces — assign static or DHCP IPs to VMs from logical networks.

✅ Apply NSGs - create, attach, and manage NSGs directly from Azure on your logical networks (VLANs in your datacenter) and/or on the VM network interface. This enables a generic rule set for VLANs, with a crisper rule set for individual Azure Local VM network interface using a complete 5-tuple control: source and destination IP, port and protocol.

✅ Use Default Network Policies — apply baseline security policies during VM creation for your primary NIC. Select well known inbound ports such as HTTP (while we block everything else for you), while still allowing outbound traffic. Or select an existing NSG you already have!

✅ Run SDN Network Controller as a Failover Cluster service — no VMs required!

All of this is powered by Network Controller running on your Azure Local infrastructure!

SDN enabled by Azure Arc (Preview) vs. SDN managed by on-premises tools?

Choosing Your Path:

Some SDN features like virtual networks (vNETs), Load Balancers (SLBs), and Gateways are not yet supported in the SDN enabled by Azure Arc (Preview).

But good news: you’ve still got options.

If your workloads need those features today, you can leverage SDN managed by on-premises tools:

- SDN Express (PowerShell)

- Windows Admin Center (WAC)

The SDN managed by on-premises tools continue to provide full-stack SDN capabilities, including SLBs, Gateways, and VNET peering while we actively work on bringing this additional value to complete SDN enabled by Azure Arc feature set.

You must choose one of the modes of SDN management and cannot run in a hybrid management mode mixing the two. Please read this important consideration section before getting started!

Thank You to Our Community

This milestone was only possible because of your input, your use cases, and your edge innovation. We're beyond excited to see what you build next with SDN enabled by Azure Arc.

To try it out, head to the Azure Local documentation

Let’s keep pushing the edge forward. Together.

#AzureLocal #SDN #AzureArc #HybridCloud #EdgeComputing

Troubleshooting Zero Trust DNS

AditiPatange — Thu, 24 Apr 2025 13:28:31 GMT

By adopting Zero Trust DNS (ZTDNS), organizations can strengthen their Zero Trust deployments, ensuring that Windows 11 devices only communicate with trusted network destinations. This blog post will help ZTDNS Public Preview selfhosters retrieve and update ZTDNS configuration, find ZTDNS logs, debug ZTDNS, share feedback, and report bugs to the team. Some known issues are also listed.

Retrieving ZTDNS configuration

You can find information on the commands to retrieve trusted server information, manually allowed exceptions, state of ZTDNS, and more by running the following in command prompt:

netsh ztdns show help

Updating ZTDNS configuration

You can add new exceptions or servers while ZTDNS is running on your device using the same commands from ZTDNS deployment process. You can run the following in command prompt to get more information:

netsh ztdns add help

You can find information on the commands to delete certain configurations like trusted servers, manually allowed exceptions, and more by running the following in command prompt:

netsh ztdns delete help

Finding ZTDNS logs

When you have ZTDNS running your device, you can check Event Viewer to see logs for all attempted connections from the device.

Search for ‘Event Viewer’ in Start menu and open it.
In the left panel, go under ‘Applications and Service Logs’ -> ‘Microsoft’ -> ‘Windows’ -> ‘ZTDNS’.
You should see three logs under this folder:
- BlockedConnections – contains logs about connections blocked by ZTDNS. Each blocked connection log contains information about the time of the blocked connection, source IP address, source port, destination IP address, destination port, and name of initiating process.
- Operational – contains logs about ZTDNS configuration and service state changes.
- PermittedConnections – contains logs about connections allowed by ZTDNS. Each permitted connection log contains information about the time of the permitted connection, source IP address, source port, destination IP address, destination port, and name of initiating process. (Note: this log is disabled by default and can be enabled by right clicking on ‘PermittedConnections’ in the left panel and selecting ‘Enable Log’.)

Debugging ZTDNS

If you experience connectivity issues after enabling ZTDNS, verify that ZTDNS has at least one trusted DNS server set. To see all trusted DNS servers set for ZTDNS, run the following in command prompt:

netsh ztdns show server

Check connectivity to the trusted DNS server using ping and try resolving an allowed domain name using the trusted DNS server with Resolve-DnsName. After this, ping to the resolved IP address should succeed.

Alternatively, you can ping an allowed domain name directly which should use the Windows DNS client and trusted DNS server for name resolution. This will check connectivity to the trusted DNS server as well as the resolved endpoint.

If your issue still persists, please file a bug. You can restore network connectivity by disabling ZTDNS. In an administrator command prompt, run:

netsh ztdns set state enable=no audit=no

Reporting feedback and bugs

We value your feedback! Your feedback from testing ZTDNS in preview is crucial for us as we get ready for GA. To share your feedback or report a bug:

Search for ‘Feedback Hub’ in Start Menu and open it.
In the left panel, click ‘Feedback’.
Click ‘+ Give new feedback’ button to enter new feedback or upvote an existing entry that matches your feedback.
In section 1. ‘Summarize your feedback’ text box, enter ‘[ZTDNS]’ and then your feedback.
In section 2. ‘Choose a category’, select ‘Problem’ if you want to report a bug and ‘Suggestion’ if you want to give feedback.
For the left dropdown box, choose ‘Network and Internet’ and for the right dropdown box, choose ‘DNS’.
Fill out Section 3. and 4.
Click ‘Submit’.

Known issues

Chromium-based WebView2 applications (including new Outlook and Teams) use their own encrypted DNS clients instead of using the Windows DNS client. On a Windows 11 device with ZTDNS enabled, based on the DNS server being contacted by the WebView2 DNS client, these applications will fail to send traffic to any resolved IP addresses. We are actively working to solve this for all applications using Chromium under the hood, including our own. You can track the linked Chromium issue for the latest updates.

Announcing Public Preview of Zero Trust DNS

AditiPatange — Tue, 11 Nov 2025 21:55:13 GMT

In today's evolving cybersecurity landscape, traditional perimeter defenses are no longer sufficient . As organizations embrace the Zero Trust security model, ensuring that devices only communicate with trusted network destinations becomes paramount. We are excited to announce the public preview of Zero Trust DNS (ZTDNS), a new feature in Windows 11 Insider builds designed to enforce domain-name-based network access controls, enhancing your organization's security posture.

ZTDNS empowers enterprise IT administrators to natively apply outbound domain-name-based network access controls on Windows 11 endpoints. This helps prevent access to untrusted destinations, reducing the risk of a slew of network attacks from malware communication to data exfiltration.

What is Zero Trust DNS?

ZTDNS integrates the Windows DNS client with trusted Protective DNS (PDNS) servers to control outbound IP traffic based on domain names. When ZTDNS is configured on a Windows 11 device to use PDNS servers that support DNS over HTTPS (DoH) or DNS over TLS (DoT), ZTDNS ensures that:

The Windows DNS client forces the use of encrypted DNS and queries are only sent to the configured PDNS servers.
Outbound traffic is permitted only to IP addresses resolved by these trusted PDNS servers or to IP ranges with a manual exception plumbed by the IT administrator.
All other IPv4 and IPv6 outbound traffic is blocked by default, adhering to the "deny by default" principle of Zero Trust.
A log of attempted outbound connections is maintained on the device.

This approach reduces the need for deep packet inspection or reliance on insecure signals like plain-text DNS or Server Name Indication (SNI) when attempting to determine the domain name associated with outbound traffic. This makes ZTDNS an important tool in the Zero Trust toolbelt since DNS traffic and SNI are increasingly being encrypted. It also aligns with Zero Trust principles by assuming all destinations are untrusted by default, only allowing connections to destinations explicitly permitted through DNS resolutions provided by trusted PDNS servers.

For more information, visit our previous blog post on design of ZTDNS.

Threats Zero Trust DNS Helps Mitigate

Implementing ZTDNS can bolster your defenses against various network-based threats, including:

DNS Hijacking: By ensuring that only DNS resolutions from trusted PDNS servers are used, ZTDNS helps prevent attackers from redirecting traffic to malicious sites.
Malicious Communications: Blocking outbound connections to IP addresses not resolved through trusted DNS queries helps disrupt phishing and even non-administrative malware stagers and beacons.
Data Exfiltration: Restricting outbound traffic to approved domains reduces the risk of sensitive data being transmitted to unauthorized destinations without conducting analysis of domain name resolution patterns.

Getting Started with Zero Trust DNS

NOTE: Public Preview of ZTDNS has officially ended. The instructions below are no longer supported. We appreciate you taking the time to test out ZTDNS in Public Preview. Your valuable feedback has helped us improve ZTDNS. For further assistance, please reach out to ztdnspreview@microsoft.com.

To enable ZTDNS in your environment:

Get a supported Windows 11 build

- Enroll your device in the Windows Insider Program (Canary channel) and update to build 27766+.

Unlock ZTDNS

- In an administrator command prompt, run:reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" /v Experiment4712 /d 0xbe8261eb /t REG_DWORD

- Reboot the device.

Ensure all applications and services are configured to use the Windows DNS client

- Configure applications like Edge and Chrome to use the Windows DNS client instead of their custom client (disable BuiltInDnsClientEnabled policy).

Add manual allow exceptions

- Teleconferencing applications like Teams use WebRTC which negotiates IP addresses for peers within a TLS tunnel and has no DNS visibility. These IP subnets are also publicly documented and need manual allow exceptions for the application to work with ZTDNS.
- Add manual allow exceptions for IP addresses that are necessary for your productivity applications/services but are not discovered through DNS. Here is a sample command, for manual allow exception, which needs to run in administrator command prompt:netsh ztdns add exception name=AppName description="Description of AppName" subnets=192.0.2.128/25,198.51.100.0/24,3fff::/48, 3fff:123::/38
- Here is a link Microsoft 365 services that may need manual allow exceptions.

Set your trusted Protective DNS server (needs to be DoH/ DoT capable)

- In an administrator command prompt, replace example data in following sample commands with information about your desired DNS server before running:netsh ztdns add server type=doh address=203.0.113.0 template=https://doh.resolver.example/dns-query netsh ztdns add server type=dot address=2001:db8::1 hostname=dot.resolver.example

Enable ZTDNS

- ZTDNS can be enabled using Audit mode or Enforcement mode.
- Audit mode logs all expected ZTDNS behavior without the actual enforcement. Check out the next blog post for finding and comprehending ZTDNS logs. Enabling ZTDNS in audit mode is recommended before moving on to Enforcement mode. In an administrator command prompt, run:netsh ztdns set state enable=yes audit=yes
- Enforcement mode blocks untrusted traffic. In an administrator command prompt, run:netsh ztdns set state enable=yes audit=no
- Now you should have ZTDNS running! In a rare situation where you experience unexpected connectivity issues for some application, please restart the application. If the issue persists, please reboot the device.

Disable ZTDNS

- ZTDNS is a powerful lockdown feature. In case you lose network connectivity due to misconfiguration, you can disable ZTDNS to restore your network connectivity. In an administrator command prompt, run:netsh ztdns set state enable=no audit=no

Note: ZTDNS is currently in Public Preview and is intended for evaluation and feedback only. Do not deploy in production environments. Breaking changes may occur before General Availability (GA).

Check out the next blog post Troubleshooting Zero Trust DNS for information on ZTDNS logs, sharing feedback and bug reports with the team.

Join Me at RSAC 2025

I am excited to share that I will be attending the RSA Conference 2025! If you are planning to be there, stop by Microsoft booth N-5744 or Microsoft Security Hub and ask for Aditi Patange to discuss how ZTDNS can enhance your organization's security posture.

Securing the Present, Innovating for the Future

Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

Windows Server 2025 Software Defined Datacenter: Networking Deployment Series (2/6)

Param_Mahajan — Wed, 09 Apr 2025 17:40:40 GMT

Deploying Windows Server 2025 Clusters with Edge Networking Solutions Part 2: How Network HUD ensures optimal, healthy and smooth Networking operations and health.

Welcome to the second blog in our Networking Deployment Series for Windows Server 2025. In this deployment series, we take a look at Contoso Medical Center’s journey deploying and harnessing the power of Windows Server 2025 Software Defined Datacenter (SDDC) to build a next-generation environment for your VMs and applications. In the first blog, we deployed Contoso Medical Center’s host-networking using the uniform, automated and scalable solution offered by Network ATC. With host networking already deployed using Network ATC at Contoso Medical Center, the next challenge is ensuring everything runs as intended- day in and day out. This is where Network HUD comes in, providing real-time visibility and proactive diagnostics to keep the network healthy, aligned, and optimized.

Note: Network HUD is currently in private preview on Windows Server 2025. When it goes to Public Preview and General Availability (GA), users will need their WS machines Arc enabled. Along with that, they will need to either (1) attest to Software Assurance or (2) have a Pay-as-you-go subscription to successfully enable and manage Network HUD.

With your host-networking now deployed, Network HUD steps in to intercept any Networking health, diagnostic and operational issues. Network HUD proactively identifies and remediates operational networking issues on your Windows Server 2025 cluster. Running and maintaining a network for your business applications is a hard job. Ensuring a workload is stable and optimized requires coordination across the physical network (switch, cabling, NIC), host operating system (e.g., virtual switch, virtual NICs, etc.), and of course the application that runs inside the VMs or Containers. Each of those have their own configurations, have different capabilities, and may be managed by different teams. Even if you’ve perfectly implemented your “golden configuration”, your environment may still experience the ripple effect of a bad configuration from another part of your network that degrades your application performance.

Installing Network HUD through an Azure Arc extension is fast, easy, and efficient. With just a few clicks in the Azure Portal, you can enable powerful network health monitoring across your cluster—no manual setup, complex scripts, or extra tools required. It integrates seamlessly into your environment, letting you start monitoring in minutes.

(click on the image for a closer look)

Network HUD is cluster aware. Network HUD understands how you intend to use your adapters and as a result can manage the stability across the cluster. Imagine Node1 in your cluster has an unstable adapter. Without informing the other nodes of the issue, the healthy nodes could overwhelm Node1 and cause a larger issue (e.g., cluster crashes or Storage Spaces Direct rebuilds).

To address this, Network HUD works in tandem with Network ATC. When Network HUD identifies instability on one node, it informs Network ATC which can manage the cluster-wide configuration and ensure that the healthy nodes do not overload the degraded nodes.

Network HUD integrates with the physical network. Network HUD takes advantage of capabilities in the physical switch to ensure that your configuration matches what’s on the physical network. For example, we can determine whether the locally connected switchports have the correct data center bridging configuration required for RDMA storage traffic to function (and as previously mentioned, we know which switchports to look at because the adapters are part of a Network ATC storage intent).

To ensure Network HUD can validate the physical network, make sure the switches connected to your cluster nodes are supported with the necessary capabilities: https://learn.microsoft.com/en-us/azure-stack/hci/concepts/physical-network-requirements?tabs=overview%2C23H2reqs.

Network HUD can handle multiple scenarios, like the ones mentioned in the examples above. Here’s a brief description of each Network HUD scenario in a few lines:

Failed Network ATC Intent

Ensures that all Network ATC intents are successfully provisioned. Flags a health fault if an intent fails, which can lead to incomplete set-ups or inaccurate configurations and unwanted system drift.

Driver Consistency, Age and Stability

Network HUD checks that all network cards (called NICs – short for Network Interface Cards) in your servers are using the same version of their software, known as drivers. These drivers help the NICs talk to Windows and send data over the network. If the drivers are too old or mismatched, it can cause slow performance or connection problems—so Network HUD warns you if a driver is over 2 years old and flags a problem if it’s older than 3.

LLDP Operation Status

Validates whether LLDP is running properly, which is critical for detecting fabric misconfigurations. A non-operational LLDP service prevents other HUD scenarios from functioning accurately.

Misconfigured VLANs

Detects inconsistencies in VLAN advertisements across NICs, switches, and hosts. Ensures that VLANs required for management, compute, and storage traffic are consistently available and properly configured.

Let’s say you have VLAN 710 configured on your VMs —everything looks good on the host side. But if the switch connected to one of your nodes isn’t actually advertising VLAN 710 on the right port, your workloads could suddenly lose connectivity. This kind of mismatch is easy to miss manually, but Network HUD catches it instantly. It reads the switch information using LLDP packets, compares it with what’s expected from Network ATC on the host, and alerts you the moment something doesn’t line up—so you can fix it before your users ever notice.

Inconsistent PFC Configuration

Checks Priority Flow Control (PFC) settings between the host and top-of-rack switches. Flags mismatches or missing PFC priorities that could lead to traffic congestion, packet loss, or storage crashes.

Here’s a demonstration of how the end-to-end installation, enablement and health fault alerting for Network HUD looks like on a standard Windows Server 2025 cluster: https://youtu.be/hW47R5Knu2k.

We are very keen to receive customer feedback on Network HUD and all its scenarios. To try out Network HUD on your Windows Server 2025 Cluster, and participate in our private preview, please reach out to: edgenetfeedback@microsoft.com. If you have any additional operational or diagnostic scenarios that you think Network HUD can alert you to, please reach out to us and let us know!

Windows Server 2025 Software Defined Datacenter: Networking Deployment Series (1/6)

Param_Mahajan — Wed, 03 Sep 2025 21:44:29 GMT

Deploying Windows Server 2025 Clusters with Edge Networking Solutions Part 1: How Network ATC Simplifies Host Networking at Contoso Medical Center

In today's digital era, a reliable and secure network is the foundation of any modern organization—including our fictitious customer, Contoso Medical Center. If you're on a similar journey, deploying and harnessing the power of Windows Server 2025 Software Defined Datacenter (SDDC) to build a next-generation environment for your VMs and applications, you’re in the right place.

No need to navigate this transformation alone! We’re here to guide you through six essential steps to networking success—demonstrating how Contoso Medical Center is:

🔹 Part 1: Building a rock-solid Host Network platform with Network ATC

🔹 Part 2: Continuously monitoring operational network issues with Network HUD (In

Private Preview)

🔹 Part 3: Deploying a modern Software Defined Networking (SDN) stack with Native SDN
🔹 Part 4: Fortifying VM security with built-in SDN network protection
🔹 Part 5: Supercharging mission-critical VMs with Accelerated Networking
🔹 Part 6: Ensuring seamless connectivity between multiple clusters with SDN Multisite

Follow along as we break down each step, helping you optimize your own deployment with Windows Server 2025!

We are Contoso Medical Center, a rapidly expanding healthcare provider that relies on cutting-edge technologies to enhance patient care, streamline administrative processes, and improve overall operational efficiency. We have heard about many new innovations in Windows Server 2025 and are eager to try it out. Our IT team is particularly concerned about the networking setup; In the past, we have had connectivity issues due to storage networks not being configured correctly. We have also had incidents where some members of the team unknowingly wiped out some configuration, causing outages. As we prepare to deploy our Windows Server 2025 clusters, we are looking for the best possible solution to setup our host network —one that is fast, reliable, automated, and aligned with Microsoft’s best practices.

Enter Network ATC!!!

Why Network ATC?

Deploying and managing host networking for clusters has traditionally been a manual, complex, and error-prone process. With Network ATC, we can automate network configurations across our servers while ensuring they adhere to Microsoft’s best practices.

The key advantages for Contoso Medical Center’s IT team include:

Consistency – Ensures uniform networking across all nodes in a cluster.
Automation – Reduces the need for manual configurations.
Self-healing – Detects and corrects misconfigurations automatically.
Microsoft Best Practices – Always aligned with the latest recommendations from Microsoft.

Managing Network ATC via Windows Admin Center

One of the biggest improvements in managing Network ATC is its integration with Windows Admin Center. Previously, configuring cluster networking required PowerShell scripts and deep networking expertise. Now, through an intuitive UI-based approach, we can define and manage Network ATC intents directly from the Windows Admin Center dashboard.

By leveraging this feature, we can:

Deploy new clusters faster with pre-defined networking intents.

Easily monitor and troubleshoot network configurations.

Modify network settings dynamically without disrupting workloads.

Learn more about Network ATC in Windows Admin Center

Network ATC end to end demo

Migrating Existing Clusters to Network ATC

At Contoso, we aren’t just deploying new Windows Server 2025 clusters, we also need to bring existing clusters into the modern era. Network ATC makes this possible through its migration capabilities.

With the latest tools, we can:
🔹 Seamlessly transition existing clusters to Network ATC-managed configurations.
🔹 Ensure minimal downtime during migration.
🔹 Standardize networking policies across all deployments.

The result? A unified and efficient networking environment, whether we’re working with new or legacy clusters.

Step-by-step migration guide

Scaling Out: Deploying Hundreds of Clusters in Minutes

As Contoso expands its data center operations, we need a way to quickly deploy and manage networking across multiple clusters. Network ATC shines in large-scale deployments by reducing deployment time from hours or days to mere minutes.

By leveraging intent-based networking, we can:

Deploy hundreds of clusters at once with consistent network configurations.
Ensure all clusters follow the same networking policies without manual effort.
Reduce human errors and misconfigurations with automation.

This is a game-changer for our IT operations, allowing us to scale without worrying about network inconsistencies.

How to deploy at scale

Final Thoughts: Why Network ATC is a Must-Have for Contoso

By integrating Network ATC into our Windows Server 2025 cluster deployment strategy, Contoso Medical Center’s IT team is:

Simplifying network management across all clusters.
Improving reliability and uptime with self-healing network configurations.
Reducing deployment time with automation at scale.
Ensuring compliance with Microsoft’s best practices effortlessly.

As we move forward with our Edge Networking Solutions, Network ATC is proving to be a key enabler of operational efficiency, security, and scalability. If you’re planning to deploy Windows Server 2025 clusters, Network ATC is a must-have in your toolkit!

🚀 Stay ahead of the curve and future-proof your networking with Network ATC.

Revolutionizing Network Management and Performance with ATC, HUD and AccelNet on Windows Server 2025

AnirbanPaul — Mon, 04 Nov 2024 16:34:01 GMT

In an era where seamless network management and enhanced performance are paramount, the release of Network ATC, Network HUD, and AccelNet for Windows Server 2025 marks a significant milestone. These groundbreaking innovations are designed to optimize the way we manage, monitor, and accelerate network operations, promising unprecedented efficiency and reliability.

Network ATC

Historically, deployment and management of networking for Failover clusters has been complex and error prone. The configuration flexibility with the host networking stack means there are many moving parts that can be easily misconfigured or overlooked. Keeping up with the latest best practices is also a challenge as improvements are continuously made to the underlying technologies. Additionally, configuration consistency across failover cluster nodes is vital for reliability.

Network ATC simplifies the deployment and network configuration management for Windows Server 2025 clusters. It provides an intent-based approach to host network deployment. Customers specify one or more intents (management, compute, or storage) for a network adapter, and we automate the deployment of the intended configuration.

Network ATC helps to:

Reduce host networking deployment time, complexity, and errors
Deploy the latest Microsoft-validated and supported best practices
Ensure configuration consistency across the cluster
Eliminate configuration drift

One of the greatest benefits of Network ATC is its ability to remediate configuration drift. Have you ever wondered “who changed that?” or said, “we must have missed this node.” You’ll never worry about this again with Network ATC at the helm. Expanding the cluster to add new nodes? Simply install the feature on the new node, join the cluster and within minutes, the expected configuration will be deployed.

For more details about deploying and managing Network ATC on Windows Server 2025, please check here: Deploy host networking with Network ATC. You can manage Network ATC through Powershell cmdlets or Windows Admin Center.

Figure: Network ATC management in Windows Admin Center

Network HUD (Coming Soon)

Network HUD is an upcoming Windows Server 2025 feature that will proactively identifies and remediates operational network issues.

Managing a network for business applications is challenging. Ensuring stability and optimization requires coordination across the physical network (switches, cabling, NICs), host operating system (virtual switches, virtual NICs), and the applications running in VMs or containers. Each component has its own configurations and capabilities, often managed by different teams. Even with a perfect setup, a bad configuration elsewhere in the network can degrade performance.

The complexity of managing these components has reached an all-time high, with numerous tools and technologies involved. Windows Server OS provides a wealth of information through event logs, performance counters, and tools, but analyzing this data when issues arise requires expertise and time, often after the problem has occurred.

Network HUD excels by analyzing real-time data from event logs, performance counters, tools like Pktmon, network traffic, and physical devices to identify issues before they happen. In many cases, it prevents issues by adjusting your system to avoid exacerbating problems. When prevention isn't possible, Network HUD alerts you with actionable messages to resolve the issue.

Network HUD leverages capabilities in the physical switch to ensure that your configuration matches the physical network. For example, it can determine whether the locally connected switchports have the correct VLAN settings and the correct data center bridging configuration required for RDMA storage traffic to function.

Network HUD is built as a true cloud service that runs on-premises. It will ship as an Arc extension and will be part of Windows Server Azure Arc Management (WSAAM) services. This allows us to bring in more capabilities and make these available to you as soon as they are ready.

AccelNet

Accelerated Networking simplifies the management of single root I/O virtualization (SR-IOV) for virtual machines hosted on Windows Server 2025 clusters. SR-IOV provides a high-performance data path that bypasses the host, which reduces latency, jitter, and CPU utilization for the most demanding network workloads. This is particularly useful in High Performance Computing (HPC) environments, Real-time applications such as financial trading platforms, and virtualized network functions.

The following figure illustrates how two VMs communicate with and without SR-IOV.

Without SR-IOV, all networking traffic in and out of the VM traverses the host and the virtual switch. With SR-IOV, network traffic that arrives at VM’s network interface (NIC) is forwarded directly to VM.

SR-IOV has been available in Windows Server since 2012 R2 days. So, what benefit does AccelNet provide?

Prerequisite checking: Informs users if the Windows Server cluster hosts support SR-IOV, checking for OS version and hyperthreading status among other things.
Host Configuration: Ensures SR-IOV is enabled on the correct vSwitch that hosts virtual machine workloads and allows configuration of reserve nodes in case of failover to prevent resource over-subscription.
Simplified VM performance settings: It can be overwhelming to identify how many queue pairs may be needed for a VM that is being enabled through SR-IOV. AccelNet abstracts performance settings into “Low,” “Medium,” and “High” to simplify configuration.
Health Monitoring and Diagnostics: Leverages Network HUD to identify and remediate configuration/performance related issues. Examples include NIC SR-IOV support, Live migration management, etc. (Coming Soon)
Simplified management with Windows Admin Center: All AccelNet management functionality is available through Powershell and with an easy-to-use UI through Windows Admin Center (Latter coming Soon).

AccelNet is part of Windows Server Azure Arc Management (WSAAM) services. To learn more about Accelnet, please check here.

As organizations continue to navigate the challenges of an ever-evolving digital landscape, the integration of these advanced features into Windows Server 2025 ensures they are equipped with the tools needed to achieve excellence in network management and performance. Embrace the future of networking with Windows Server 2025 and experience the transformative power of Network ATC, Network HUD, and AccelNet.

We are excited to share all these innovations with you. Upgrade to Windows Server 2025 to try out these features, we look forward to your feedback. For any suggestions, opinions or issues, please reach out to us at edgenetfeedback@microsoft.com.

A New Dawn of Software Defined Networking (SDN) in Windows Server 2025

AnirbanPaul — Mon, 04 Nov 2024 16:32:43 GMT

A New Dawn of Software Defined Networking (SDN) in Windows Server 2025

Today is an exciting day as we unveil extensive new features and improvements for Software Defined Networking (SDN) in Windows Server 2025. We deeply appreciate your fantastic feedback and requests which have driven our team forward.

We hope you are as thrilled as we are, and we can't wait to hear how you leverage these new features. We've categorized our updates into three major areas: Manageability, Security, and Scalability.

Manageability

“Native” SDN Infrastructure: The long-awaited feature is finally here! Traditionally, the Network Controller, a crucial part of SDN infrastructure, has been hosted in virtual machines (VMs), requiring multiple VMs for high availability. This setup consumes computing resources that could otherwise be used for applications, posing a significant issue for small-scale and single node Failover Clusters. With Windows Server 2025, we have transitioned the Network Controller from VMs to being hosted directly as Failover Cluster services on Windows Server 2025 hosts. This change not only conserves resources but also simplifies deployment and management, eliminating the need to deploy, manage, and update VMs. Yes, no more patching or installing agents from various teams on these VMs. You can use PowerShell cmdlets or Windows Admin Center to deploy and manage the “native” SDN infrastructure. Native SDN empowers you to have advanced VM network security features in less than ten minutes.

Figure: Differences between Network Controller in VMs and “native” Network Controller

Simplified SDN Load Balancers (Coming Soon): Previously, setting up the SDN load balancer service involved setting up Border Gateway Protocol (BGP) peering between the load balancer virtual machines and the top-of-rack network switches to achieve external network connectivity. This process was cumbersome and incurred additional operational costs, consuming both resources and energy. This is particularly valuable for SMBs and smaller edge deployments, where advanced networking knowledge and know-how may be limited. The upcoming updates will make BGP optional, streamlining both the deployment and management process.

Security

Network security is a paramount concern for organizations today, given the rise in breaches, threats, and cybersecurity risks. SDN Network Security Groups (NSGs) offer Azure-consistent network security for Windows Server customers, protecting against both external and lateral threats. With Windows Server 2025, we are introducing new NSG capabilities to further enhance the security of your workloads.

Tag-based Segmentation: Instead of depending on cumbersome and unreliable methods for specifying IP ranges for NSG control, administrators can now use custom service tags to associate NSGs and VMs for access control. No more remembering and retyping IP ranges for your production and management machines; you can now use simple, self-explanatory labels. This allows you to tag your workload VMs with labels of your choice and apply security policies based on these tags. You can use PowerShell cmdlets or Windows Admin Center to deploy and manage network security tags. You can read more about tag-based segmentation here.

Figure: Network Security tags in Windows Admin Center

Default Network Policies: We are bringing Azure parity to our existing Network Security Groups (NSGs) on Windows Server 2025. Default Network Policies now enable you to reduce lateral attacks for workloads deployed through Windows Admin Center, offering options such as “Open some ports,” “Use existing NSG,” or “No protection.”

No protection: All ports on your VM are exposed to networks, posing a security risk.
Open some ports: The default policy denies all inbound access, allowing you to selectively open well-known inbound ports while permitting full outbound access from the VM.
Use existing NSG: Utilize an NSG you have already created.

With these options, you can ensure that your newly created VMs and applications are always protected with NSGs. You can read more about Default Network Policies here.

Figures: Default network policies in Windows Admin Center during VM creation

Scalability

SDN Multisite: Many of you deploy applications across multiple locations and need the flexibility to move parts of these applications freely without reconfiguring the application or networks. Traditionally, Windows Server only partially supported this scenario and required additional components for deployment and management. SDN Multisite addresses this by providing native Layer 2 and Layer 3 connectivity between applications across two locations without any extra components. It also offers unified network policy management for workloads, eliminating the need to update policies when a workload VM moves from one location to another. You can use PowerShell cmdlets or Windows Admin Center to deploy and manage SDN Multisite. You can read more about SDN Multisite here.

Figure: Native connectivity for workload VMs across California and Norway WS 2025 clusters with SDN multisite

High Performance SDN Gateways: SDN Layer 3 gateways are essential for SDN infrastructure, providing connectivity between workloads on SDN networks and external networks by acting as routers. Many of you have requested performance improvements for these gateways. With Windows Server 2025, we have significantly enhanced the performance of SDN Layer 3 gateways, achieving higher throughputs (~15-30% improvement) and reduced CPU cycles (~25-40% improvement). These improvements are enabled by default, so you will automatically experience better performance when you configure a SDN gateway Layer 3 connection through PowerShell cmdlets or Windows Admin Center.

Learning

Exciting news! We've just rolled out fresh learning content tailored to empower our customers and support engineers with in-depth knowledge and practice on SDN. All self-guided content is comprised of a lecture and a hands-on lab aimed to provide actionable knowledge that drives success for our customers. You can access the learning content here: Technical reference for Software Defined Networking (SDN)| Microsoft Learn.

We are excited to share all these innovations with you. Upgrade to Windows Server 2025 to try out these features, we look forward to your feedback. For any suggestions, opinions, or issues, please reach out to us at sdn_feedback@microsoft.com.

Announcing Zero Trust DNS Private Preview

tojens — Wed, 20 Nov 2024 00:27:40 GMT

In the modern world, useful network destinations are far more likely to be defined by long-lived domain names than long-lived IP addresses. However, enforcement of domain name boundaries (such as blocking traffic associated with a forbidden domain name) has always been problematic since it requires breaking encryption or relying on unreliable plain-text signals such as DNS over port 53 inspection or SNI inspection.

To support Zero Trust deployments trying to lock down devices to only access approved network destinations, we are announcing the development of Zero Trust DNS (ZTDNS) in a future version of Windows. ZTDNS was designed to be interoperable by using network protocols from open standards to satisfy Zero Trust requirements such as those found in OMB M-22-09 and NIST SP 800-207. ZTDNS will be helpful to any administrator trying to use domain names as a strong identifier of network traffic.

ZTDNS integrates the Windows DNS client and the Windows Filtering Platform (WFP) to enable this domain-name-based lockdown. First, Windows is provisioned with a set of DoH or DoT capable Protective DNS servers; these are expected to only resolve allowed domain names. This provisioning may also contain a list of IP address subnets that should always be allowed (for endpoints without domain names), expected Protective DNS server certificate identities to properly validate the connection is to the expected server, or certificates to be used for client authentication.

Next, Windows will block all outbound IPv4 and IPv6 traffic except for the connections to the Protective DNS servers as well as the DHCP, DHCPv6, and NDP traffic needed to discover network connectivity information. Note that many options from these protocols will be ignored, such as RDNSS, as only the configured Protective DNS servers will be used.

Going forward, DNS responses from one of the Protective DNS servers that contain IP address resolutions will trigger outbound allow exceptions for those IP addresses. This ensures that applications and services that use the system DNS configuration will be allowed to connect to the resolved IP addresses. This is because the destination IP address will be approved and unblocked before the domain name resolutions are returned to the caller.

When applications and services try to send IPv4 or IPv6 traffic to an IP address that was not learned through ZTDNS (and is not on the manual exceptions list), the traffic will be blocked. This is not because ZTDNS tried to identify malicious or forbidden traffic to block, but because the traffic was not proven to be allowed. This makes ZTDNS a useful tool in the Zero Trust toolbelt: it assumes traffic is forbidden by default. This will allow administrators to define domain-name-based lockdown using policy-aware Protective DNS servers. Optionally, client certs can be used to provide policy-affecting client identities to the server rather than relying on client IP addresses, which are both not secure signals and not reliably stable for work-from-anywhere devices.

By using ZTDNS to augment their Zero Trust deployments, administrators can achieve name labeling of all outbound IPv4 and IPv6 traffic without relying on intercepting plain-text DNS traffic, engaging in an arms race to identify and block encrypted DNS traffic from apps or malware, inspecting the soon-to-be encrypted SNI, or relying on vendor-specific networking protocols. Instead, administrators can block all traffic whose associated domain name or named exception cannot be identified. This renders the use of hard-coded IP addresses or unapproved encrypted DNS servers irrelevant without having to introduce TLS termination and miss out on the security benefits of end-to-end encryption.

For DNS servers to be used as Protective DNS servers for ZTDNS lockdown, the minimum requirement is to support either DNS over HTTPS (DoH) or DNS over TLS (DoT), as ZTDNS will prevent the use of plain-text DNS by Windows. Optionally, use of mTLS on the encrypted DNS connections will allow Protective DNS to apply per-client resolution policies. In all cases, ZTDNS does not introduce any novel network protocols, which makes it a promising interoperable approach to domain-name-based lockdown.

ZTDNS is entering private preview, meaning it is not yet publicly available for testing. There will be another announcement once the ZTDNS client is available to Insiders. For now, there is additional information about considerations for deploying ZTDNS in a real-world environment in this blog post.

Update, May 6th, 2024: come talk to Aditi Patange at the Microsoft RSAC booth about ZTDNS! (week of May 6th only)

Update, November 19th, 2024: Private Preview of ZTDNS is opening up for Windows 11 enterprise customers! If you are an enterprise interesting in testing ZTDNS in your environment, please sign up for Private Preview at aka.ms/ztdnsintake.

Deployment Considerations for Windows ZTDNS Client

tojens — Thu, 02 May 2024 13:00:00 GMT

This document goes over what considerations administrators should keep in mind when evaluating how ZTDNS fits into their Zero Trust deployment model. For more information about what ZTDNS is, see this feature announcement.

Zero Trust DNS (ZTDNS) is a powerful Windows feature that enables an administrator to lock down Windows outbound IP-based traffic to endpoints approved by a Protective DNS service. However, there is no such thing as a Zero Trust silver bullet or “Zero Trust on” button.

This post will help administrators understand what to consider when deploying ZTDNS:

What things ZTDNS will complicate (including alternative solutions to solving those same scenarios without violating Zero Trust principles)
What will bypass ZTDNS (defining what scenarios are out of scope for ZTDNS today)

What things ZTDNS will complicate

ZTDNS, as a Zero Trust architecture enabling feature, breaks insecure networking features in ways that may not be immediately obvious. By blocking all outbound network traffic that cannot be associated with a domain name, there are many networking protocols that simply cannot function, including (but certainly not limited to) mDNS, LLMNR, NetBIOS Name Resolution, UPnP, and WebRTC.

Some of the uses cases for these protocols can be unblocked by defining narrow IP subnet exceptions, such as allowing the well-defined IP ranges required for a vendor’s software. Others cannot know their destination IP addresses in advance and will never work unless ZTDNS is deactivated or greatly crippled with broad IP subnet exceptions.

Even when creating IP address exceptions for ZTDNS, there are two major considerations to keep in mind:

IP address exceptions should be used only when strictly necessary to prevent unmanageably long lists of exceptions, and
Only IP addresses from the globally-unique ranges should be permitted to prevent Windows from being vulnerable to attacks from other hosts using same addresses on different networks

Note: the latter can be addressed by deploying IPv6 and creating manual IP addresses exceptions for IPv6 ULA and GUA addresses, where each address type is appropriate (note that extra care must be taken with ULA address allocation to not use predictable ranges).

This page will go over several common real-world scenarios ZTDNS will impact and, if possible, how administrators can address the original need without IP address exceptions.

Printing

Using a secure printer management service such as Microsoft’s Universal Print enables enterprise administrators to configure printers securely through trusted device management. Printer endpoints are then resolved through ZTDNS instead of being discovered using mDNS, which ZTDNS would block. More information about the endpoints Universal Print uses can be found on this page.

File shares

Trying to discover file shares on the network, such as using the Network section of Windows Explorer, will be blocked by ZTDNS. However, if the Protective DNS servers ZTDNS uses are also local network DNS servers, then file shares on the local network can be discovered and used just like any other approved domain name.

Additionally, using file hosting that can be reached at DNS-discovered endpoints, such as SharePoint, OneDrive for Business, or Azure Files, will ensure no ZTDNS workarounds are needed. This also ensures that the network connection Windows 11 uses to discover and connect to the file share is not a factor in the connection’s trust in line with Zero Trust principles.

Windows Update

Windows Update will continue to function when ZTDNS is activated (so long as its required domain names are resolved by the ZTDNS-configured Protective DNS service). However, enterprises may notice a sudden increase in traffic to Windows Update services because ZTDNS will block the local network peer-to-peer traffic Windows uses to share already-downloaded updates between devices on the same network.

Enterprises should consider using MCC (in preview for enterprises) or WSUS to reduce Windows Update traffic volume when ZTDNS prevents the peer-to-peer sharing of Windows updates.

Teleconferencing apps

Programs such as Teams, Webex, Zoom, Discord, Slack, and others use protocols such as WebRTC to stream their video calls. WebRTC in turn uses IP addresses discovered through STUN and TURN. This means that ZTDNS will end up blocking WebRTC because the IP addresses were not discovered through DNS queries.

Most vendors will disclose the IP address subnets they require for functionality to inform customers about needed firewall exceptions (such as these for Microsoft Office products). Such vendor-required IP ranges should be configured as IP exceptions in ZTDNS when resolving the required domain names is not sufficient.

Media streaming

Some forms of media streaming, such as streaming from online services through a browser, will usually work when ZTDNS is active because it will use domain names to look up the destination. Other media streaming scenarios that use non-DNS endpoint discovery will end up being blocked by ZTDNS, especially local network media discovery and streaming such as sharing music libraries or streaming video from a home media server. Universal Plug and Play (UPnP) is one of many standards used for this that will not work when ZTDNS is active.

Casting to wireless displays

Browsers and other apps may wish to discover castable wireless displays, but this will not work when ZTDNS is active. Consider using physical connections to the intended display instead.

Captive portals

Most captive portals today continue to rely on plain-text DNS query interception to redirect clients to a captive portal page. When ZTDNS is active, this will never work because Windows 11 will never emit plain-text DNS traffic. While there is a standard that allows networks to advertise their captive portal properties in a structured manner (not supported in Windows), this is not compatible with the ZTDNS approach today because the network would not allow the ZTDNS client to issue a query for the captive portal URI.

In the ZTDNS private preview, navigating captive portals is an unsupported scenario.

Browsers using their own DNS clients

Most browsers can use their own encrypted DNS clients instead of using the operating system’s DNS APIs. When a browser attempts to do this on Windows 11 when ZTDNS is active, it will either fail to resolve any names, or fail to send traffic to any resolved IP addresses (depending on whether ZTDNS permits outbound traffic to the encrypted DNS server in the first place).

Customers should use the management policy provided by their browser vendor to disable the use of encrypted DNS within the browser itself, such as this Edge policy. This is generally good practice on managed devices anyway because other Windows mechanisms also expect apps to use the system DNS resolver, such as the NRPT.

Apps with hard-coded or non-DNS-discovered IP addresses

It is likely that administrators will find one or more applications in their production environment relying on hard-coded IP addresses or non-DNS name resolution mechanisms. Administrators should do a controlled roll out of ZTDNS by first enabling audit mode; this will allow discovery of apps that would break if ZTDNS were enforcing outbound blocks in the logs without actually breaking employee productivity.

Note: even when enforcement is off, ZTDNS will still disrupt any experience that directly relies on use of non-DNS name protocols by the Windows DNS client, specifically mDNS, LLMNR, and NetBIOS name resolution. This is because when ZTDNS audit mode is on, all name queries need to be sent to the Protective DNS service to test if it would have permitted the name. Use of DNS or any other name resolution protocol by other apps, such as browsers using DNS over HTTPS, will not be blocked in audit mode.

What can bypass ZTDNS

While there are features and functionality that ZTDNS will break, there is also networking functionality which can bypass ZTDNS enforcement, either because ZTDNS is still in preview and being worked on, or because of the inherent nature of the other feature.

VPN or SASE/SSE tunnels

Any form of tunneling technology, such as VPNs and SASE/SSE solutions, will work when ZTDNS is active so long as the gateway in question is looked up by allowed domain name or the IP address is manually permitted by ZTDNS. However, once that occurs, all traffic sent over the tunnel will appear to be associated with the domain name or the exception name for the gateway’s IP address, not the domain name the app sending traffic resolved for any given traffic flow through the tunnel.

Administrators should be aware of this when they deploy ZTDNS and network tunnels at the same time and ensure they conduct ZTDNS-like domain name auditing at the tunnel’s exit node in order to maintain similar lockdown-by-domain-name functionality.

Hyper-V VMs, including WSL

Any virtualization that implements its own networking stack, and therefore bypassing the Windows Filtering Platform functionality of the host TCP/IP stack, will bypass ZTDNS enforcement. Windows Subsystem for Linux (WSL) is a high-profile example of an enterprise experience that will bypass ZTDNS enforcement in the Windows Insider ZTDNS preview.

Stack bypass technologies

Any other technology that bypasses the Windows 11 host networking stack, such as XDP or DPDK, will bypass ZTDNS and any other Windows feature that enforces traffic through Windows Filtering Platform.

Local administrators

Enterprise administrators should consider whether their employees need to have administrative privilege on their Windows devices. Any administrator can deactivate ZTDNS enforcement as easily as activate it, add ZTDNS exceptions for malicious IP addresses, or even install and run software with administrative privileges which may (unbeknownst to the human user) do these things. Therefore, deploying ZTDNS to Windows 11 machines in an enterprise environment which have regular human users with administrator privileges is unsupported. The intention is for the device to be fully managed through MDM, with local controls present for debugging purposes only, in line with Zero Trust principles (grant only the absolutely necessary access or permissions).

Windows DNS Client Survey

AditiPatange — Thu, 25 Apr 2024 13:00:00 GMT

In the past few years, new standards have emerged in the DNS space, but we understand migrating a core component like DNS to adopt new standards can be difficult and challenging. As we prioritize future Windows work, we would like to know more about what customers like you are using to support your own DNS deployments. We have published the survey below to ask you a few questions that will contribute to that exercise.

Link to the survey

The survey is fairly short and anonymous (though we left a field for sharing your contact information if you would be okay with direct follow up). Thank you in advance for your responses; your experiences will help us focus on what you find most valuable in our future work.

Three Reasons Why You Should Not Use iPerf3 on Windows

JamesKehr — Mon, 22 Apr 2024 17:44:10 GMT

James Kehr here with the Microsoft Commercial Support – Windows Networking team. This article will explain why you should not use iPerf3 on Windows for synthetic network benchmarking and testing. Followed by a brief explanation of why you should use ntttcp and ctsTraffic instead.

UPDATE (22 April 2024): Various update tags were made throughout the article based on feedback in the comments.

Reason 1 – ESnet Does Not Support Windows

iPerf3 is owned and maintained by an organization called ESnet (Energy Sciences Network). They do not officially support nor recommend that iPerf3 be used on Windows. Their recommendation is to use iPerf2. More on the Microsoft recommendation later.

Here are some direct quotes from the official ESnet iPerf3 FAQ, retrieved on 18 April 2024.

I’m trying to use iperf3 on Windows, but having trouble. What should I do?

iperf3 is not officially supported on Windows, but iperf2 is. We recommend you use iperf2.

UPDATE (22 April 2024): Please read the comment(s) from rjmcmahon for details about iPerf2 vs iPerf3.

And from the ESnet “Obtaining iPerf3” article, retrieved on 18 April 2024.

Primary development for iperf3 takes place on CentOS 7 Linux, FreeBSD 11, and macOS 10.12. At this time, these are the only officially supported platforms…

Microsoft does not recommend using iPerf3 for a different reason.

Reason 2 – iPerf3 is Emulated on Windows

iPerf3 does not make Windows native API calls. It only knows how to make Linux/POSIX calls.

The iPerf3 community uses Cygwin as an emulation layer to get iPerf3 working on Windows. You can read more about Cygwin in their FAQ.

The iPerf3 calls are sent to Cygwin, which translates them to Windows APIs calls. Only then does the Windows network stack come into play. The iPerf3 on Windows maintainers do an excellent job of making it all work together, but, ultimately, there are potential issues with this approach.

Not all the iPerf3 features will work on Windows. The basic options work well, but advanced capabilities needed for certain network testing may not be available on Windows or may behave in unexpected ways.

Emulation tends to have a performance penalty. The emulation overhead on a latency sensitive operation, such as network testing, can result in lower than expected throughput.

Finally, iPerf3 uses uncommon Windows Socket (winsock) options versus native Windows applications. For generic throughput testing this is fine. For application testing the uncommon socket options will not mimic real-world Windows-native application behavior.

Reason 3 – You Are Probably Using an Old Version of iPerf3.

UPDATE (22 April 2024): iperf.fr no longer serves the old Windows iPerf3 binaries. The site now links to other sites which have actively maintained iPerf3 for Windows binaries. A big thank you to Harvester for pointing this out in comments and to the iperf.fr team for updating their site!

Go search for “iPerf3 on Windows” on the web. Go ahead, open a tab, and use your search engine of choice. Which I am certain is Bing with Copilot.

What is the top result, and thus the most likely link you will click on? I bet the site was iperf.fr.

The newest version of iPerf3 for Windows on iperf.fr is 3.1.3 from 8 June 2016. That was nearly 8 years ago at the time of writing.

The current version of iPerf3, directly from ESnet, is 3.16. A full 15 versions of missing bug fixes, features, and changes from the version people are most likely to download.

This specific copy of iPerf3, from iperf.fr, includes a version of cygwin1.dll that contains a bug which limits the socket buffer to 1MB. This will cause poor performance on high speed-high latency and high bandwidth networks because iPerf3 will not be capable of putting enough data in-flight to saturate the link, resulting in inaccurate testing.

Where should you look for iPerf3 on Windows?

From ESnet’s article, “Obtaining iPerf3” they say:

Windows: iperf3 binaries for Windows (built with Cygwin) can be found in a variety of locations, including https://files.budman.pw/ (discussion thread).

What Does Microsoft Recommend

Microsoft maintains two synthetic network benchmarking tools: ntttcp (Windows NT Test TCP) and ctsTraffic. The newest version of ntttcp is maintained on GitHub. This is a Windows native tool which utilizes Windows networking in the same way a native Windows application does.

But what about Linux?

There is a Linux version of ntttcp, too! Details can be found on the ntttcp for Linux GitHub repo. This is a separate codebase built for Linux that is compatible with ntttcp for Windows, but it is not identical to the Windows counterpart.

Ntttcp allows you to perform API native synthetic network tests between Windows and Windows, Linux and Linux, and between Windows and Linux.

ctsTraffic is Windows-to-Windows only. Where ntttcp is more iPerf3-like, ctsTraffic has a different set of options and goals. ctsTraffic focuses on end-to-end goodput scenarios, where ntttcp and iPerf3 focus more on isolating network stack throughput.

How do you use ntttcp?

The Azure team has written a great article about basic ntttcp functionality for Windows and Linux. I do not believe in reinventing the wheel, so I will simply link you to the article.

https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-bandwidth-testing?tabs=windows

There is a known interoperability limitation when testing between Windows and Linux. Details can be found in this ntttcp for Linux wiki article on GitHub.

Testing

I built a lab while preparing this article using two Windows Server 2022 VMs. The tests used the newest versions of iPerf3 (3.16), ntttcp (5.39), and ctsTraffic (2.0.3.3).

The default iPerf3 parameters are the most common configuration I see among Microsoft support customers. So, I am tuning ntttcp and ctsTraffic to better match iPerf3’s default single connection, 128KB buffer length behavior. While this is not a perfect comparison, this does make it a better comparison.

Single stream tests are used for targeted analyses since many applications do not perform multi-threaded transfers. Bandwidth and maximum throughput testing should be multi-threaded with large buffers, but that is a topic for a different day.

Don’t forget to allow the network traffic on the Windows Defender Firewall if you wish to run your own tests.

iPerf3

iPerf3 server command:

iperf3 -s

iPerf3 client command:

iperf3 -c <IP> -t 60

The average across multiple tests was about 7.5 Gbps. The top result was 8.5 Gbps, with a low of 5.26 Gbps.

ntttcp

Ntttcp server command:

ntttcp -r -m 1,*,<IP> -t 60

Ntttcp client command:

ntttcp -s -m 1,*,<IP> -l 128K -t 60

Ntttcp averaged about 12.75 Gbps across multiple tests. The top test averaged 13.5 Gbps, with a low test of 12.5 Gbps.

Ntttcp does something called pre-posting receives, which is unique to this tool. This reduces application wait time as part of network stack isolation, allowing for quicker than normal application responses to socket messages.

-r is receiver, and -s is sender.

-m is a mapping of values that are: <num threads>, <CPU affinity>, <Target IP>. In this test we use a single thread, no CPU affinity (*), and both -r and -s side uses the target IP address as the final value.

-t is test time, in seconds.

-l sets the buffer length. You can use K|M|G with ntttcp as shorthand for kilo-, mega-, and giga-bytes.

ctsTraffic

These commands are run in PowerShell to make reading values easier.

ctsTraffic server command:

.\ctstraffic.exe -listen:* -Buffer:"$(128KB)" -Transfer:"$(1TB)" -ServerExitLimit:1 -consoleverbosity:1 -TimeLimit:60000

ctsTraffic client command:

.\ctstraffic.exe -target:<IP> -Connections:1 -Buffer:"$(128KB)" -Transfer:"$(1TB)" -Iterations:1 -consoleverbosity:1 -TimeLimit:60000

The result, about 9.2 Gbps average. It is a little faster and far more consistent than iPerf3, but not quite as fast as ntttcp. The two primary reasons why ctsTraffic is slower are data integrity checks and the use of the recommended overlapped IO model. This means ctsTraffic uses a single pending receive versus pre-posting receives like ntttcp.

-Buffer is the buffer length (ntttp: -l).

-Transfer is the amount of data to send per iteration.

-Iterations/-ServerExitLimit is the number of times a data sets will be transferred.

-Connections is the number of concurrent TCP streams that will be used.

-TimeLimit is the number of milliseconds to run the test. The test stops even if the iteration transfer has not been completed when the time limit is reached.

Thank you for reading and I hope this helps improve your understanding of synthetic network benchmarking on Windows!

Windows 11 Plans to Expand CLAT Support

tojens — Thu, 07 Mar 2024 15:00:00 GMT

Thank you everyone who responded to our recent IPv6 migration survey! We want you to know that we are committed to improving your IPv6 journey and these data are helpful in shaping our future plans.

To that end, just a quick update: we are committing to expanding our CLAT support to include non-cellular network interfaces in a future version of Windows 11. This will include discovery using the relevant parts of RFC 7050 (ipv4only.arpa DNS query), RFC 8781 (PREF64 option in RAs), and RFC 8925 (DHCP Option 108) standards. Once we do have functionality available for you to test in Windows Insiders builds, we will let you know.

We are looking forward to continuing to provide support for your platform networking needs!