Microsoft has updated its security advisory ADV200013 to explicitly cover Windows Server 2022, version 23H2, and the just‑released Windows Server 2025, and is again telling administrators to apply a quick registry change that blocks an entire class of DNS cache‑poisoning attacks. The mitigation—setting the DNS service’s MaximumUdpPacketSize to exactly 1221 decimal bytes—forces large responses onto TCP, eliminating the IP‑fragmentation window that attackers have exploited for years.

The move arrives as the SAD DNS family of attacks and similar fragmentation‑based spoofing techniques continue to threaten both authoritative and recursive resolvers. Microsoft first published ADV200013 in December 2020 alongside a patch for CVE‑2020‑25705, but the workaround was originally documented only for older server builds. The revised advisory now pulls Windows Server 2022 (including version 23H2) and all editions of Windows Server 2025 into scope, making it clear that even the newest platforms need the same hardening.

A straightforward registry tweak with outsized impact

The procedure is simple: open Registry Editor as Administrator, navigate to HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters, add or set a DWORD value named MaximumUdpPacketSize, and give it a decimal value of 1221 (hex 0x4C5). After a DNS service restart, any response larger than 1221 bytes will be fetched over TCP rather than UDP.

Microsoft warns that incorrect registry changes can cause serious problems, but the operation itself is trivial to script in PowerShell:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\DNS\Parameters" `
                  -Name "MaximumUdpPacketSize" -Value 1221 -Type DWord
Restart-Service DNS

The setting piggybacks on a long‑standing fallback mechanism: if a DNS response exceeds the configured UDP buffer, the resolver sets the truncation (TC) bit and the client or upstream server re‑queries over TCP. By artificially shrinking the buffer, the workaround systematically pushes every response that could be fragmented into that safe TCP channel.

Why 1221? A deliberate compromise

DNS traffic has changed dramatically since the original 512‑byte UDP limit. EDNS0 (RFC 6891) allows resolvers to advertise much larger buffers, frequently 4096 bytes or more, to carry DNSSEC signatures, long TXT records, and other fat responses in a single UDP datagram. That same flexibility, however, creates IP fragments when payloads exceed the path MTU. If an attacker can poison one fragment, the reassembled packet can carry a malicious answer straight into the cache—a core technique behind SAD DNS.

Picking 1221 bytes steers a middle course:

  • It’s well above 512, so legitimate EDNS0‑equipped responses that don’t actually require fragmentation still flow over UDP.
  • It’s low enough that any response large enough to trigger IP fragmentation on typical Ethernet networks (MTU 1500) will be forced onto TCP instead.

In effect, the threshold removes the fragmentation attack surface while keeping the vast majority of everyday DNS queries on fast, connectionless UDP.

Which systems need the change—and which don’t

Microsoft’s latest text lists these Windows Server editions as directly affected:

  • Windows Server 2022 (including version 23H2)
  • Windows Server 2025 (all installation types, including Server Core)

Earlier supported versions were already covered by the original advisory. The change is relevant for any machine running the Windows DNS Server role—whether it acts as a recursive resolver for clients, a forwarder to an upstream provider, or an authoritative server. Administrators should inventory every DNS service in their environment, including those in branch offices and DMZs, because a poisoned cache on a single forwarder can affect an entire organization.

Systems that do not run the Microsoft DNS service—BIND, Unbound, dnsmasq, cloud resolvers—are not protected by this registry key. They need their own mitigations, but the principle remains the same: force large responses over TCP wherever possible.

Operational headwinds: TCP, firewalls, and latency

Forcing traffic onto TCP is not free. The handshake adds at least one round trip, and the server must now manage TCP connection state, socket buffers, and ephemeral port exhaustion. Under heavy query loads on under‑provisioned hardware, CPU usage and memory consumption can climb noticeably.

Three practical obstacles demand attention:

  • Firewall rules. Many perimeter and internal ACLs allow UDP/53 but block TCP/53 outright, often because older guidance treated TCP DNS as rare. If your firewalls drop TCP port 53, queries that now require TCP will fail, taking DNSSEC‑protected zones and other legitimate services offline. Validate every path between your resolvers and upstream servers.
  • Client and appliance compatibility. Some legacy devices, IoT sensors, and cheap DNS appliances have never implemented TCP fallback. They will simply time out when a truncated response instructs them to retry over TCP. Run a pilot on a representative set of subnets before enterprise‑wide rollout.
  • Latency . The extra handshake adds latency that may be noticeable for geographically distant connections. For most enterprise workloads the penalty is a few tens of milliseconds, but high‑frequency trading floors, real‑time VoIP systems, or large resolver farms might need capacity adjustments.

A historical parallel is useful: when Microsoft rolled out source‑port randomisation and transaction‑ID hardening after Dan Kaminsky’s 2008 cache‑poisoning disclosure, administrators faced similar firewall and resource tuning work. The lesson is that DNS transport changes require careful pilot testing and monitoring, but they are manageable.

A phased deployment playbook

Security teams can safely apply the workaround by following a staged plan:

  1. Inventory all Windows DNS servers. Identify authoritative servers, recursive resolvers, and forwarders. Note which ones serve internet‑facing roles.
  2. Lab test. Apply MaximumUdpPacketSize=1221 to a non‑production resolver and confirm that:
    - Large DNSSEC records, long MX replies, and SOA queries succeed.
    - Recursive queries to upstream providers work over TCP.
    - DNS service restarts cleanly and no dependent services break.
  3. Verify network paths. Use telnet or Test-NetConnection to check TCP port 53 between each resolver and its upstream servers, through every firewall that sits in the path.
  4. Staged rollout. Move to one low‑impact production resolver, then to a larger group, then to critical servers. Automate the registry change with Group Policy Preferences, PowerShell DSC, or your configuration management tool.
  5. Monitor. Watch DNS debug logs for truncation flags (TC bit set), count TCP‑port‑53 session spikes, and track service response times. Correlate with client help‑desk tickets for resolution failures.
  6. Rollback script. Keep a script that deletes the registry value and restarts the DNS service, so you can revert quickly if needed.

What defenders gain—and what they still lose

The workaround excels as an immediate, low‑cost kill switch against fragmentation‑based spoofing. It requires no new software, can be applied remotely, and leverages built‑in fallback logic that has existed in DNS for decades. Several security vendors, including Qualys and Tenable, have added detection plugins that flag servers missing the registry key.

Yet it is a mitigation, not a patch. It does not fix any underlying bug in the resolver’s parsing or caching code; a code flaw that permits cache poisoning through other vectors would remain unpatched. Moreover, it does nothing for non‑Windows resolvers, nor does it protect against attacks that arrive over TCP itself (though those are far harder to execute because TCP sequence numbers add another layer of randomness).

Operational teams must also accept the increased operational complexity: firewalls must be reviewed, capacity planning may need updating, and legacy device failures are a real possibility.

Beyond the registry key—long‑term hardening

The 1221‑byte cap buys time, but permanent resilience requires layered defences:

  • Apply vendor patches. Track the specific KB articles associated with ADV200013 and CVE‑2020‑25705, and schedule them as soon as they become available for your OS builds.
  • Validate DNSSEC. When configured correctly, DNSSEC validation makes forged answers useless, even if they land in the cache. Note that DNSSEC itself produces large responses, so TCP reliance will already be high after the workaround.
  • Restrict forwarder egress. Allow DNS servers to communicate only with a tight list of trusted upstream resolvers. Block outbound UDP/53 from workstations and non‑DNS servers to prevent malware from using rogue resolvers.
  • Segment and harden the DNS tier. Place resolvers in dedicated VLANs, apply response‑rate limiting (RRL), and enforce response policy zones (RPZ) to filter malicious domains.
  • Monitor aggressively. Feed DNS logs into your SIEM and build alerts for abnormal truncation rates, unexpected authoritative answers, and traffic to unknown upstream IPs.

The bottom line

Microsoft’s updated advisory gives administrators a fast, scriptable, and effective countermeasure against a persistent threat. The MaximumUdpPacketSize workaround may be a blunt tool, but it closes the fragmentation attack vector cleanly and is backed by the vendor’s official guidance. For any organisation running Windows DNS servers—especially those that cannot immediately patch all systems—applying the 1221‑byte limit is a prudent, high‑impact step that materially reduces the risk of cache poisoning.

The workaround is not a permanent fix, and it must be paired with proper testing, network adjustments, and a long‑term plan for patching and architectural improvements. Ignoring it, however, leaves a well‑documented attack surface open. As DNS remains the phonebook of the internet, keeping it trustworthy is a battle that never really ends.