Windows DNS Cache Poisoning Mitigation: Set MaximumUdpPacketSize to 1221 (ADV200013)

Microsoft has updated guidance in its Security Update Guide advisory ADV200013 — the advisory that covers DNS resolver spoofing and cache‑poisoning attacks — and is explicitly telling administrators that in addition to older server builds the mitigation applies to newer releases such as Windows Server 2022, version 23H2, Windows Server 2025, and Windows Server 2025 (Server Core installation); for immediate protection Microsoft recommends configuring Windows DNS servers so the UDP buffer (MaximumUdpPacketSize) is set to 1221 bytes (decimal), which forces responses larger than that threshold to use TCP instead of UDP. (bleepingcomputer.com, qualys.com)

---

Background / overview​

The advisory (ADV200013) responds to a class of DNS cache‑poisoning attacks that rely on IP fragmentation and oversized UDP DNS responses. These attacks exploit the fact that DNS responses delivered over UDP can be fragmented across multiple IP packets; if an attacker can influence or spoof fragments, they may be able to craft a malicious DNS response that a resolver will accept and cache. This is often discussed in the context of the “SAD DNS” family and similar fragmentation-based cache‑poisoning techniques. (dirteam.com, secalerts.co)
Historically, the fix space for DNS cache poisoning has included several complementary techniques: source‑port randomization, transaction ID entropy, selective use of TCP for large responses (EDNS0/UDP size handling), and protocol‑level fixes in resolver software. Microsoft’s mitigation here is procedural — reduce the maximum UDP payload size the Windows DNS resolver will accept so that responses that would be fragmented or risk being spoofed instead arrive over TCP, which is connection‑oriented and far harder to spoof using straightforward IP‑fragment techniques. (bleepingcomputer.com, learn.microsoft.com)
This advisory is notable for two reasons:

• It gives a short, immediate workaround administrators can apply today.
• Microsoft has extended the advisory’s applicability to newer server builds (Windows Server 2022, version 23H2 and Windows Server 2025), making the workaround relevant to current‑generation infrastructures. (qualys.com, secalerts.co)

---

What Microsoft is telling admins (exact mitigation)​

Microsoft’s recommended workaround is precise and narrowly scoped: set the DNS service registry value MaximumUdpPacketSize to decimal 1221 (hex 0x4C5) under HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters, then restart the DNS service. After this change, any DNS response larger than 1221 bytes will be retrieved over TCP rather than UDP; that blocks the specific attack surfaces that rely on fragmented or very large UDP responses. The registry steps are:

• Run regedit (or use PowerShell) as Administrator.
• Navigate to HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters.
• Add or set:
• Name: MaximumUdpPacketSize
• Type: DWORD
• Value: 1221 (decimal) / 0x4C5 (hex).
• Restart the DNS Server service for the change to take effect.

Microsoft and multiple security vendors included this exact remediation in their writeups and checks, and packaged detection rules accordingly so scanning tools can flag servers that do not have the workaround applied. (bleepingcomputer.com, qualys.com)
A practical PowerShell one‑liner (run in an elevated session) to deploy the change:
1) Create/update the registry value and restart DNS:

$RegPath = 'HKLM:\SYSTEM\CurrentControlSet\Services\DNS\Parameters'
New-ItemProperty -Path $RegPath -Name MaximumUdpPacketSize -Value 1221 -PropertyType DWORD -Force
Restart-Service -Name DNS

(Use standard operational processes when applying this to production systems and confirm roll‑back/recovery plans before mass deployment.) (dirteam.com)

---

Why 1221 bytes? The technical rationale​

• EDNS0 allows DNS responses larger than the historic 512‑byte UDP limit. Many legitimate DNS responses (for example DNSSEC responses or large zone transfers and some types of records) can be larger than 512 bytes and are therefore normally handled via UDP with EDNS0 advertising a larger UDP buffer. That increases the chance that responses are fragmented at the IP layer. Attackers who can spoof IP fragments can attempt to inject malicious fragments to make a resolver accept or assemble an attacker‑controlled DNS response. For this reason, forcing larger responses onto TCP removes the fragmentation window an attacker needs for this style of cache poisoning. (learn.microsoft.com, dirteam.com)
• The value 1221 is deliberately chosen: it is significantly larger than 512 (avoiding false positives on modest EDNS0 usage) but small enough that many responses that would be fragmented are instead forced to use TCP. In short, 1221 is a pragmatic compromise that reduces fragmentation‑driven spoofing risk while minimizing impact on legitimate DNS traffic. Several vendor writeups and the Microsoft advisory explain this behavior — responses larger than the configured UDP buffer will use TCP, and that change eliminates the fragment‑based cache‑poisoning vector. (bleepingcomputer.com, qualys.com)

---

Affected products and scope — what to check​

Microsoft’s advisory (ADV200013) originally circulated as part of the December 2020 security guidance addressing fragmentation‑based DNS cache‑poisoning (SAD DNS / CVE‑2020‑25705). The workaround was then documented for the Windows DNS Resolver and earlier supported Windows Server builds. According to Microsoft’s latest update of the advisory and multiple independent trackers, administrators running modern server builds — specifically Windows Server 2022, version 23H2, Windows Server 2025, and Windows Server 2025 (Server Core installation) — should also apply the workaround where they operate Microsoft DNS servers or forwarders. (qualys.com, secalerts.co)
Action checklist to determine exposure:

• Inventory all authoritative and recursive DNS servers running the Windows DNS Server service.
• Confirm which systems act as forwarders for client queries (forwarders can cache poisoned records too).
• Confirm whether any firewall / middlebox will block DNS over TCP (must be allowed for the workaround to work reliably).
• Validate whether clients or appliances rely on very large UDP DNS responses that might be truncated or change behavior after the setting. (dirteam.com)

Note: public trackers and third‑party vulnerability aggregators show multiple related CVEs and advisories in this space; the exact product lists can vary depending on CVE mapping and vendor catalog updates. If you require absolute, authoritative product applicability for compliance or for a scanned inventory, consult Microsoft’s Security Update Guide entry for ADV200013 and the specific KBs or update pages for the CVE IDs that apply in your environment. If a direct MSRC page is required for audit, use the vendor’s Update Guide as the canonical source. (qualys.com, secalerts.co)

---

Operational impact and compatibility risks​

Any mitigation that changes DNS transport behavior must be evaluated for side effects. The most important operational impacts to plan for are:

• Increased use of TCP for DNS — forcing large responses over TCP increases the number of TCP connections established by resolving clients and between resolvers and upstream servers. That can increase CPU, connection churn, and potentially memory usage under heavy query loads. Testing is essential. (learn.microsoft.com)
• Firewalls and middleboxes — many middleboxes, network filters, or older equipment may allow DNS/UDP but not DNS/TCP through perimeter or internal ACLs. If DNS over TCP is blocked, the workaround will cause failures for queries that must be retrieved over TCP (for example large DNSSEC responses). Ensure your firewalls and packet filters allow TCP port 53 to pass where necessary. (learn.microsoft.com)
• Compatibility with devices that cannot do TCP DNS — some embedded devices or appliance DNS stacks might not handle DNS over TCP correctly; test critical clients and appliances. Organizations with legacy endpoints will need a test plan before wide deployment. (dirteam.com)
• Potential for higher latency on large responses — TCP handshakes and connection setup will add round‑trip latency versus a single UDP datagram. For many environments the latency is acceptable; for some high‑performance resolver farms it may need capacity adjustments. (qualys.com)
• DNSSEC and large responses — DNSSEC responses are commonly larger; the workaround pushes these to TCP. That is safe and by design, but if your edge drops TCP/53 you may see DNSSEC failures. Make sure DNSSEC‑related traffic is tested. (learn.microsoft.com)

A historical precedent reinforces why careful testing is required: when Microsoft and other vendors implemented countermeasures for the 2008 “Kaminsky” DNS cache‑poisoning era, server behavior changes and socket‑pool randomization created compatibility and resource usage effects that administrators had to address (socket pool sizing, ephemeral port reservations, firewall rules). Expect similar housekeeping tasks. (support.microsoft.com)

---

Practical deployment guidance — testing, rolling out, and monitoring​

Use a phased, QA‑driven approach. The suggested operational playbook:

• Inventory and prioritize
• Identify all Windows systems running the DNS Server role and all forwarders.
• Prioritize internet‑facing resolvers and high‑volume forwarders.
• Test in a lab
• Apply MaximumUdpPacketSize=1221 to a representative resolver.
• Confirm query behavior for:
• Large records (DNSSEC, TXT records, large MX/SOA replies).
• Recursive queries to upstream resolvers.
• Client behavior from typical client subnets.
• Confirm the DNS Server service restarts cleanly and no other services are impacted.
• Verify network path
• Confirm that TCP/53 is permitted through internal and perimeter firewalls between resolvers and upstream servers.
• If you use cloud services or appliances as resolvers, validate their handling of TCP/53.
• Staged rollout
• Roll out to non‑production resolvers first, then to low‑impact production resolvers, then to critical production resolvers.
• Use automation (Group Policy, PowerShell DSC, Intune, or configuration management) to ensure consistent settings across servers.
• Monitoring & detection
• Monitor DNS logs for truncation flags (TC bit), increased TCP/53 sessions, or unexpected failures.
• Watch for client complaints of name resolution failures and for spikes in TCP port 53 traffic metrics.
• Adjust socket pool or resource allocations if your servers show elevated load. (dirteam.com, qualys.com)
• Rollback plan
• Keep a clear rollback path (scripted removal of the registry value and service restart) and a monitoring window to confirm changes have the desired operational effect.
• Communicate
• Inform network operations and security teams, and update runbooks so that incident responders know why TCP/53 use has increased.

---

Detection and hunting (what to look for)​

While the workaround reduces the fragmentation‑based spoofing threat, you should still hunt for indicators of attempted cache‑poisoning activity and anomalous behavior:

• Unexpected authoritative responses cached by your resolver that point at attacker‑controlled IPs.
• A spike in DNS responses with unusual TTLs or inconsistent delegation chains.
• High rates of DNS truncation (TC bit) followed by unexpected TCP session establishment to retrieve the same name.
• Suspicious upstream servers or unusual source IPs for authoritative answers.
• Any mismatches between expected internal records and what resolvers are returning to clients. (dirteam.com)

These detection signals should be part of DNS server logging, SIEM correlation, and threat‑hunt playbooks.

---

Strengths of Microsoft’s approach​

• Fast, vendor‑blessed mitigation: The registry change is easily scripted and applied to many servers quickly, giving defenders an immediate option when patch windows are long.
• Low‑cost in terms of implementation complexity: No new software is required; the change only modifies a resolver parameter and relies on existing TCP fallback semantics.
• Targets the attack primitive: By forcing TCP for large responses, Microsoft effectively removes the IP‑fragmentation attack window exploited by this class of cache‑poisoning techniques. (bleepingcomputer.com, qualys.com)

---

Weaknesses and residual risks​

• Not a code fix: This is a mitigation, not a patch. It reduces exposure but does not fix underlying protocol or implementation bugs in the resolver code itself across platforms. Vendor patches or upstream resolver fixes are still the long‑term remedy.
• Operational friction: Increased TCP DNS traffic, firewall changes, and potential breakage of legacy devices are real costs that require testing and operations work.
• Does not protect non‑Windows resolvers: If your environment includes other DNS resolvers (BIND, Unbound, dnsmasq, or cloud resolvers), those need their own fixes/mitigations. Attacks that target other resolvers remain a concern. (dirteam.com, secalerts.co)

---

Longer‑term remediation and architectural options​

Beyond the immediate registry workaround, organizations should plan a durable remediation strategy:

• Apply vendor patches and OS/security updates when available for each affected resolver and OS build. Treat this workaround as temporary until patches are applied.
• Harden resolver configuration:
• Use DNSSEC validation to make forged answers less useful (but note DNSSEC increases response size and thus TCP usage).
• Use response‑rate limiting (RRL) and response policy zones (RPZ) where appropriate to reduce amplification and malicious record injection impact.
• Consider authoritative zone hardening (secure dynamic updates, tight DHCP/DNS integration controls) to prevent unauthorized DNS updates from inside your network. (akamai.com, theregister.com)
• Segmentation and egress filtering:
• Ensure resolvers are properly segmented and that forwarders do not accept or forward responses to untrusted upstream resolvers.
• Block DNS‑over‑UDP to unknown external resolvers from privileged servers (restrict egress to known, trusted forwarders).
• Replace or upgrade resolvers where vendor fixes are unavailable or if your resolver software has known, unfixed weaknesses. (theregister.com)

---

A concrete, prioritized action plan (for security teams)​

• Immediately identify and inventory Windows DNS servers (authoritative and recursive).
• Test the MaximumUdpPacketSize=1221 change in a staging environment.
• If tests are successful, deploy to production resolvers in a controlled, staged manner.
• Ensure TCP/53 is permitted by firewalls and perimeter devices to and from upstream resolvers.
• Monitor DNS logs, track truncation and TCP metrics, and watch for resolution anomalies.
• Plan for permanent remediation by tracking vendor patches and scheduling patch deployment.
• Extend detection and mitigation to non‑Windows resolvers and review DHCP/DNS dynamic update controls in Active Directory environments. (dirteam.com, qualys.com)

---

Final assessment — strengths, costs, and overall recommendation​

Microsoft’s advisory offers an effective, targeted mitigation that reduces an immediate and meaningful attack vector: fragmentation‑and‑spoofing DNS cache‑poisoning attacks. For organizations operating Windows DNS servers, applying the MaximumUdpPacketSize registry change is a reasonable emergency control when there is a real risk of exposure and patching cannot be completed immediately. The fix is easy to script and roll out, and it forces the resolver to use TCP for large responses — removing the primary mechanism exploited by these attacks. (bleepingcomputer.com, qualys.com)
However, this is not a substitute for a full remediation lifecycle:

• Test before wide deployment, because the mitigation changes DNS transport semantics and can expose firewall, performance, or client compatibility issues.
• Keep TCP/53 allowed end‑to‑end and monitor resolvers for resource pressure.
• Apply vendor patches as soon as they are available and validate resolver behavior after updates.

For defenders the balanced approach is clear: apply the workaround to reduce risk quickly; use staged testing and monitoring to manage operational impact; and treat vendor patches and architecture changes (DNSSEC, RRL, egress filtering) as the long‑term solution set. (dirteam.com, learn.microsoft.com)

---

Applying Microsoft’s guidance will materially lower the risk from fragmentation‑based DNS spoofing attacks for Windows DNS servers — but it must be applied thoughtfully, tested, and paired with longer‑term fixes and monitoring so that DNS integrity remains resilient and reliable across the enterprise.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center