文章总结： RFC9715提供了DNSoverUDP中避免IP分片的技术指南。文档指出IP分片会使DNS面临缓存中毒等安全风险，建议通过限制UDP响应大小(推荐最大1400字节)、配置系统防止分片、丢弃分片响应、必要时升级到TCP传输来规避风险。同时给出了针对响应者、请求者和运营商的具体操作建议，包括使用较小密钥算法、优化DNS配置等措施。 综合评分： 85 文章分类： 漏洞分析,网络安全,解决方案,技术标准,WEB安全
UDP上的DNS中的IP分片避免
衡水石头哥 衡水石头哥
铁军哥
2026年4月5日 07:37 北京
RFC 9715：IP Fragmentation Avoidance in DNS over UDP，January 2025
梗概
DNS中广泛部署的DNS扩展机制（EDNS(0)）功能使DNS接收方能够指示其接收的UDP消息大小容量，这支持DNS服务器发送大型UDP响应。大型DNS/UDP消息更容易被分片，而IP分片暴露了应用协议中的弱点。通过尽可能限制响应大小并在必要时发出从UDP升级到TCP传输的信号，可以避免DNS中的IP分片。本文档介绍了避免DNS中IP分片的技术。
本备忘录的状态
本文档不是互联网标准跟踪规范；其发布仅供参考。
本文档是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已接受公众审查，并已被互联网工程指导小组（IESG）批准发布。并非IESG批准的所有文件都是任何级别互联网标准的候选文件；请参阅RFC 7841第2节。
有关本文档当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc9715。
版权声明
版权所有（c）2025 IETF Trust和文档作者。版权所有。
本文件受本文件发布之日生效的BCP 78和IETF信托与IETF文件相关的法律规定（https://trustee.ietf.org/license-info）的约束。请仔细阅读这些文件，因为它们描述了您与本文件相关的权利和限制。从本文档中提取的代码组件必须包括《信托法律条款》第4.e节中所述的修订版BSD许可证文本，并且不提供修订版BSD许可证中所述的保证。
1、简介
本文档最初旨在成为当前最佳实践，但由于操作系统和套接字选项的限制，某些建议尚未获得实际经验；因此，本文档仅供参考。预计，随着操作系统和实施的发展，我们将获得更多建议经验，并将在未来发布更新的文档作为最佳当前实践。
DNS有一个EDNS(0)机制[RFC6891]。DNS中广泛部署的EDNS(0)功能使DNS接收方能够指示其接收的UDP消息大小容量，这支持DNS服务器发送大型UDP响应。当数据包大于数据包路径中某些网络的最大传输单元（Maximum Transmission Unit，MTU）时，基于UDP的DNS会引发IP分片。
分片的DNS UDP响应具有系统性弱点，这会使请求者遭受来自路径外攻击者的DNS缓存中毒（请参阅第7.3节以获取参考和详细信息）。
[RFC8900]指出IP分片给互联网通信带来了脆弱性。通过UDP传输DNS消息应考虑该文件中所述的观察结果。
TCP通过将数据分片为小于或等于最大分片大小（Maximum Segment Size，MSS）的数据包来避免分片。对于每个传输的段，IP和TCP报文头的大小是已知的，并且可以选择IP数据包大小以使其保持在估计的MTU和MSS范围内。这利用了TCP报文封装过程的弹性，具体取决于下一个数据段将容纳多少排队数据。相比之下，基于UDP的DNS数据报大小弹性很小，并且缺乏对IP报文头和选项大小的洞察，因此我们必须对可用UDP有效负载空间做出更保守的估计。
[RFC7766]指出所有通用DNS实现必须支持UDP和TCP传输。
DNS事务安全[RFC8945][RFC2931]确实可以防止分片的安全风险，并且可以保护委托响应。但由于密钥分发要求，[RFC8945]的适用性有限，而且[RFC2931]的部署也很少。
本文档描述了避免DNS中UDP数据包的IP分片的各种技术。本文档主要适用于全球互联网上的DNS使用。
相反，偏离推荐值的路径MTU可以通过静态配置、服务器路由提示或未来的发现协议获得。然而，解决这个问题超出了本文档的范围，并且可能是未来规范的主题。
2、术语
本文档中的关键字“必须”、“不得”、“必需”、“应”、“不应”、“应该”、“不应该”、“推荐”、“不推荐”、“可以”和“可选”当且仅当它们出现在所有内容中时，应按照BCP 14[RFC2119][RFC8174]中的描述进行解释。
“请求者”和“响应者”的定义按照[RFC6891]：
“请求方”指的是发送请求的一方。“响应方”指的是权威的、递归的解析器或其他DNS组件，它负责响应查询。
“路径MTU”的定义按照[RFC8201]：
路径 MTU 是源节点和目标节点之间路径中所有链路的最小链路 MTU。
在本文档中，术语“路径MTU发现”包括经典路径MTU发现[RFC1191][RFC8201]和分组层路径MTU发现[RFC8899]。
本文档中使用的许多专业术语均在“DNS术语”[RFC9499]中定义。
3、如何避免DNS中的IP分片
这些建议适用于Internet上具有全局IP地址的节点。专用网络或本地网络不属于本文档的范围。
下面介绍了避免DNS中IP分片的方法：
3.1、针对UDP响应者的建议
R1. UDP响应者不应使用IPv6分片[RFC8200]。
R2. UDP响应者应配置其系统，以防止发送回复时UDP数据包分片，前提是可以安全地完成。不同操作系统实现此目的的机制有所不同。
对于类似BSD的操作系统，IP不分片（Don’t Fragment，DF）标志位[RFC0791]可用于防止分片。相比之下，Linux系统不会为此目的公开直接API，并且需要使用路径MTU套接字选项（IP_MTU_DISCOVER）来管理分片设置。但是，需要注意的是，在当前Linux版本中为UDP启用IPv4路径MTU发现被认为是有害且危险的。有关详细信息，请参阅附录C。
R3. UDP响应方应编写符合所提供请求方的最大UDP负载大小[RFC6891]、接口MTU、根据网络运营商知识配置的网络MTU值以及推荐的最大DNS/UDP负载大小1400中的最小值的响应数据包。有关更多详细信息，请参阅附录A。
R4. 如果UDP响应器检测到指示UDP分组超过路径MTU大小的立即错误，则UDP响应器可以重新创建适合路径MTU大小或设置了TC位的响应分组。
TC位的原因和影响没有改变[RFC1035]。
3.2、针对UDP请求者的建议
R5. UDP请求者应限制请求者的最大UDP有效负载大小，以适应接口MTU、网络运营商配置的网络MTU值以及推荐的最大DNS/UDP有效负载大小1400的最小值。可以允许更小的限制。有关详细信息，请参阅附录A。
R6. UDP请求者应丢弃分片的DNS/UDP响应而不进行IP重组，以避免缓存中毒攻击（在防火墙功能处）。
R7. DNS响应可能会因IP分片而被丢弃。建议请求者最终尝试替代传输协议。
4、对DNS运营商的建议
大型DNS响应通常是区域配置的结果。在DNS中发布信息的人应该寻求导致较小响应的配置。例如：
R8. 使用较少数量的名称服务器。
R9. 对域名使用较少数量的A/AAAA RR。
R10. 使用最小响应配置：某些实现具有“最小响应”配置选项，该选项使DNS服务器通过仅包含强制和必需的数据来缩小响应数据包（附录B）。
R11. 对DNSSEC使用较小的签名/公钥大小算法。值得注意的是，椭圆曲线数字签名算法（Elliptic Curve Digital Signature Algorithm，ECDSA）和爱德华兹曲线数字签名算法（Edwards-curve Digital Signature Algorithm，EdDSA）的签名大小小于使用RSA的同等加密强度的签名大小。
很难确定R8、R9和R11的具体上限，但如果来自DNS服务器的所有响应都低于R3和R5的大小就足够了。
5、协议合规性注意事项
一些权威服务器偏离DNS标准，如下所示：
* 一些权威服务器忽略EDNS(0)请求者的最大UDP有效负载大小并返回较大的UDP响应[Fujiwara2018]。
* 某些权威服务器不支持TCP传输。
此类不合规行为不能成为DNS其余部分的实施或配置限制。如果导致故障，则必须将该故障定位到不合规的服务器。
6、IANA考虑因素
本文档没有IANA行动。
7、安全考虑
7.1、IPv4上的路径分片
如果未设置不分片（DF）标志位，则IPv4上可能会发生路径分片，并可能导致第7.3节中所示的漏洞。为了避免这种情况，需要使用R6丢弃分片响应并使用TCP重试。
7.2、小MTU网络
在避免分片时，小型MTU网络后面的DNS/UDP请求方可能会遇到UDP超时，这会降低性能并可能导致TCP回退。这表明先前对IP分片的依赖，这被认为对应用程序、端点和网关的性能和稳定性有害。避免IP分片将改善整体运行状况，DNS/TCP的性能已经并将继续提高。
如果UDP响应数据包在传输过程中被丢弃，直至并包括发起者的网络堆栈，则会增加毒害请求者缓存的攻击窗口。
7.3、IP分片的弱点
“分片被认为是投毒”[Herzberg2013]指出使用IP分片的有效路径外DNS缓存中毒攻击媒介。“DNS上的IP分片攻击”[Hlavacek2013]和“MitM-Resilient PKI的域验证++”[Brandt2018]指出，偏离路径的攻击者可以干预路径MTU发现[RFC1191]，导致权威服务器产生分片响应。[RFC7739]阐述了可预测分片标识值的安全含义。
[RFC8085]的第3.2节指出“应用程序不应发送导致IP数据包沿着到目的地的路径超过最大传输单元（MTU）的UDP数据报”。
DNS消息接收方无法信任分片的UDP数据报，主要是因为UDP端口号和DNS消息标识符提供的熵很少，每个字段的大小只有16位，并且如果发生分片，两者都可能位于数据包的第一个分片中。相比之下，TCP协议栈控制数据包大小并避免ICMP NEEDFRAG攻击下的IP分片。在TCP中，出于性能原因应避免分片，而对于UDP，出于弹性和真实性原因应避免分片。
7.4、DNS安全保护
DNSSEC是针对使用IP分片的缓存中毒攻击的对策。但是，DNS委托响应未使用DNSSEC进行签名，并且DNSSEC没有机制在注入不正确的委托时获取正确的响应。这是一个拒绝服务漏洞，可能会导致名称解析失败。如果可以避免缓存中毒攻击，则可以避免DNSSEC验证失败。
7.5、解析器操作员可能采取的行动
由于本文档作为信息发布，而不是当前最佳实践，因此本节介绍解析器操作员可以采取的步骤，以避免与IP分片相关的漏洞。
为了避免与IP分片相关的漏洞，请实施R5和R6。
具体来说，将保护全服务解析器的防火墙功能配置为丢弃IPv4上具有非零分片偏移（Fragment Offset，FO）或更多分片（More Fragments，MF）标志位1的传入DNS响应数据包，并丢弃具有IPv6分片报文头的数据包。（如果解析器的IP地址不是专用于DNS解析器，并且使用依赖于IP分片的UDP通信来实现DNS以外的目的，则仅丢弃包含来自端口53的UDP报文头的第一个分片。）
最新的解析器软件被认为实现了R7。
即使不实施R7，也只会导致名称解析错误，从而防止攻击进入恶意站点。
8、参考文献
8.1、规范性参考文献
[RFC1035]Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.[RFC1191]Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/info/rfc1191>.[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.[RFC2931]Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 2000, <https://www.rfc-editor.org/info/rfc2931>.[RFC6891]Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <https://www.rfc-editor.org/info/rfc6891>.[RFC7739]Gont, F., "Security Implications of Predictable Fragment Identification Values", RFC 7739, DOI 10.17487/RFC7739, February 2016, <https://www.rfc-editor.org/info/rfc7739>.[RFC7766]Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, <https://www.rfc-editor.org/info/rfc7766>.[RFC8085]Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.[RFC8174]Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.[RFC8200]Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.[RFC8201]McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.[RFC8899]Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. Völker, "Packetization Layer Path MTU Discovery for Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, September 2020, <https://www.rfc-editor.org/info/rfc8899>.[RFC8945]Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D., Gudmundsson, O., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", STD 93, RFC 8945, DOI 10.17487/RFC8945, November 2020, <https://www.rfc-editor.org/info/rfc8945>.[RFC9499]Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, March 2024, <https://www.rfc-editor.org/info/rfc9499>.
8.2、参考资料
[Brandt2018]Brandt, M., Dai, T., Klein, A., Shulman, H., and M. Waidner, "Domain Validation++ For MitM-Resilient PKI", Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, pp. 2060-2076, DOI 10.1145/3243734.3243790, October 2018, <https://dl.acm.org/doi/10.1145/3243734.3243790>.[DNSFlagDay2020]"DNS flag day 2020", <https://dnsflagday.net/2020/>.[Fujiwara2018]Fujiwara, K., "Measures against DNS cache poisoning attacks using IP fragmentation", OARC 30 Workshop, 2019, <https://indico.dnsoarc.net/event/31/contributions/692/attachments/660/1115/ fujiwara-5.pdf>.[Herzberg2013]Herzberg, A. and H. Shulman, "Fragmentation Considered Poisonous, or: One-domain-to-rule-them-all.org", IEEE Conference on Communications and Network Security (CNS), DOI 10.1109/CNS.2013.6682711, 2013, <https://ieeexplore.ieee.org/document/6682711>.[Hlavacek2013]Hlavacek, T., "IP fragmentation attack on DNS", RIPE 67 Meeting, 2013, <https://ripe67.ripe.net/ presentations/240-ipfragattack.pdf>.[Huston2021]Huston, G. and J. Damas, "Measuring DNS Flag Day 2020", OARC 34 Workshop, February 2021, <https://indico.dnsoarc.net/event/37/contributions/806/ attachments/782/1366/2021-02-04-dns-flag.pdf>.[RFC0791]Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.[RFC2308]Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, <https://www.rfc-editor.org/info/rfc2308>.[RFC2671]Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, DOI 10.17487/RFC2671, August 1999, <https://www.rfc-editor.org/info/rfc2671>.[RFC2782]Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <https://www.rfc-editor.org/info/rfc2782>.[RFC4035]Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <https://www.rfc-editor.org/info/rfc4035>.[RFC5155]Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, <https://www.rfc-editor.org/info/rfc5155>.[RFC8900]Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., and F. Gont, "IP Fragmentation Considered Fragile", BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, <https://www.rfc-editor.org/info/rfc8900>.[RFC9460]Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, November 2023, <https://www.rfc-editor.org/info/rfc9460>.[RFC9471]Andrews, M., Huque, S., Wouters, P., and D. Wessels, "DNS Glue Requirements in Referral Responses", RFC 9471, DOI 10.17487/RFC9471, September 2023, <https://www.rfc-editor.org/info/rfc9471>.
附录A、请求者最大UDP有效负载大小讨论的详细信息
关于默认路径MTU大小和请求者的最大UDP负载大小有很多讨论。
* IPv6接口的最小MTU为1280个八位字节（请参阅[RFC8200]的第5节）。因此，它可以用作IPv6的默认路径MTU值。IPv4接口相应的最小MTU为68（60 + 8）[RFC0791]。
* [RFC4035]规定“具有安全意识的名称服务器必须支持EDNS0（[RFC2671]）消息大小扩展，[并且它]必须支持至少1220个八位位组的消息大小”。那么，最大DNS/UDP负载大小的最小数字是1220。
* 为了避免IP分片，[DNSFlagDay2020]建议UDP请求者将请求者的有效负载大小设置为1232，UDP响应者组成UDP响应，以便它们适合1232个八位字节。大小1232基于IPv6规范[RFC8200]所要求的MTU 1280，减去IPv6和UDP报文头的48个八位字节。
* 大多数Internet，尤其是内核，具有至少1500个八位位组的MTU。MTU 1500以太网上IPv6的最大DNS/UDP负载大小为1452（1500减40（IPv6报文头大小）减8（UDP报文头大小））。为了考虑到可能的IP选项和远程隧道开销，建议默认最大DNS/UDP负载大小为1400。
* [Huston2021]分析了[DNSFlagDay2020]的结果，并报告说，他们的测量结果表明，在递归解析器和权威服务器之间的互联网内部，普遍的MTU为1500，并且在互联网的这一部分中没有使用较小MTU的可测量信号。他们提出，他们的测量建议将EDNS(0)请求者的UDP有效负载大小设置为IPv4的1472个八位位组和IPv6的1452个八位位组。
根据这些讨论的结果，本文档建议值为1400，也允许使用更小的值。
附录B、最低限度的回应
一些实现具有“最小响应”配置设置/选项，其导致DNS服务器使响应数据包更小，仅包含强制和必需的数据。
在最小响应配置下，DNS服务器组成仅包含必要资源记录（RR）的响应。对于委托，请参阅[RFC9471]。如果域名不存在或类型不存在，则authority部分将包含SOA记录，而answer部分为空（参见[RFC2308]的第2节）。
某些资源记录（MX、SRV、SVCB和HTTPS）需要[RFC1035]、[RFC2782]和[RFC9460]中定义的附加部分中的附加A、AAAA和服务绑定（Service Binding，SVCB）记录。
此外，如果区域经过DNSSEC签名并且查询具有DNSSEC OK位，则在应答部分中添加签名，或者在权限部分中添加相应的DS RRSet和签名。详细信息在[RFC4035]和[RFC5155]中定义。
附录C、已知实现
本节记录第3节中描述的拟议建议的已知实施状态。
请注意，此处列出的任何单独实现并不意味着IETF的认可。此外，我们没有努力验证IETF贡献者提供的信息以及此处提供的信息。
C.1、BIND 9
BIND 9未实现R1和R2。
Linux上的BIND 9将IP_MTU_DISCOVER设置为IP_PMTUDISC_OMIT，并回退到IP_PMTUDISC_DONT。
当BIND 9在具有IP_DONTFRAG的系统（例如FreeBSD）上时，IP_DONTFRAG被禁用。
接受UDP的路径MTU发现被认为是有害且危险的。BIND 9的设置可避免对路径MTU发现的攻击。
对于R3，BIND 9将尊重请求者的大小，直至配置的限制（max-udp-size）。UDP响应数据包绑定在512到4096字节之间，默认设置为1232。BIND 9支持请求者的大小高达配置的限制（max-udp-size）。
在R4的情况下，发送因EMSGSIZE失败，BIND 9设置TC位并尝试再次发送最小应答。
对于R5，BIND 9使用edns-buf-size选项，默认值为1232。
对于R7，两次UDP超时后，BIND 9将回退到TCP。
C.2、Knot DNS和Knot解析器
两个Knot服务器都设置IP_PMTUDISC_OMIT以避免路径MTU欺骗。默认情况下，UDP大小限制为1232。
如果分片通过Linux XDP接口到达，则会被忽略。
在重复的UDP超时后尝试TCP。
返回最少的响应，并且当前不可配置。
使用较小的签名，默认为ecdsap256sha256。
C.3、PowerDNS权威服务器、PowerDNS Recursor和PowerDNS dnsdist
* 使用IP_PMTUDISC_OMIT并回退到IP_PMTUDISC_DONT。
* 默认EDNS缓冲区大小1232；无需探测较小尺寸。
* 不处理EMSGSIZE。
* 递归：UDP超时不会导致切换到TCP，但“欺骗未遂事件”可能会导致切换。
C.4、PowerDNS权威服务器
* 默认DNSSEC算法为13。
* 回应很少；这是不可配置的。
C.5、未绑定
Unbound将IP_MTU_DISCOVER设置为IP_PMTUDISC_OMIT，并回退到IP_PMTUDISC_DONT。它还会在具有IP_DONTFRAG的系统上禁用IP_DONTFRAG，但在Apple系统上则不会。在支持它的系统上，Unbound设置IPV6_USE_MIN_MTU，并回退到1280的IPV6_MTU，并回退到IPV6_USER_MTU。它还将IPV6_MTU_DISCOVER设置为IPV6_PMTUDISC_OMIT，并回退到IPV6_PMTUDISC_DONT。
默认情况下，Unbound从对等方请求UDP大小为1232。请求者的大小最大限制为1232。
超时后，Unbound会以较小的大小（如果适用）重试，或者以大小1232（对于IPv6）和1472（对于IPv4）重试。由于“标志日”[DNSFlagDay2020]更改为1232，这不会造成任何负面影响。
Unbound具有“最少响应”配置选项；设置默认开启。
致谢
作者要特别感谢Paul Wouters、Mukund Sivaraman、Tony Finch、Hugo Salgado、Peter van Dijk、Brian Dickson、Puneet Sood、Jim Reid、Petr Spacek、Andrew McConachie、Joe Abley、Daisuke Higashi、Joe Touch、Wouter Wijngaards、Vladimir Cunat、Benno Overeinder和 Štěpán Němec的广泛审阅和评论。
***推荐阅读***
我们的WireGuard管理系统支持手机电脑了！全平台终端配置，支持扫码连接，一键搞定
保姆级教程：一条命令部署OpenVPN管理系统V4版，支持Win/Mac/安卓/iOS全平台接入
成本省下99.7%！用40元的腾讯云服务器自建IPsecVPN，成功对接企业级飞塔防火墙
别再乱选VPN了！实测数据告诉你：为什么L2TP是个“坑”
密码复杂度满分却被秒破？腾讯云“白名单”闹剧与AI泄密的血泪复盘
彻底告别密码登录！Ubuntu最强安全加固与效率提升指南
告别OSPF！EVE-NG专业版+BGP Unnumbered打通Underlay的完整实战
从180秒到0.01秒：智算中心Underlay路由优化的速度与激情
嵌套虚拟化的极限时延：在2000 Mbps的风暴中，我找到了性能的真谛
单边写入为何秒杀双边传输？从UDP 4791到BTH头，看懂RDMA的灵魂构造！
手机也能跑DeepSeek-R1/Qwen3了：零成本搭建AI推理平台
2048卡昇腾910C集群算力集群交付工程手册
2048卡H100算力中心100G无阻塞存储网建设方案
Ollama连夜跳版本，只为迎接Google扮猪吃老虎的Gemma 4？
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：铁军哥 衡水石头哥 衡水石头哥《UDP上的DNS中的IP分片避免》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论