<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>UDP Vulnerability on 飞鸽跳转</title><link>https://feige301.com/zh-cn/tags/udp-vulnerability/</link><description>Recent content in UDP Vulnerability on 飞鸽跳转</description><generator>Hugo</generator><language>zh-CN</language><lastBuildDate>Wed, 03 Dec 2025 14:30:00 +0800</lastBuildDate><atom:link href="https://feige301.com/zh-cn/tags/udp-vulnerability/index.xml" rel="self" type="application/rss+xml"/><item><title>DNS污染解密：为什么你被导向了虚假的彼岸？</title><link>https://feige301.com/zh-cn/posts/2025/dns-pollution-decryption-why-you-were-redirected-to-the-false-shore.html</link><pubDate>Wed, 03 Dec 2025 14:30:00 +0800</pubDate><guid>https://feige301.com/zh-cn/posts/2025/dns-pollution-decryption-why-you-were-redirected-to-the-false-shore.html</guid><description>&lt;p>在互联网高速狂奔，经历了无数次网络攻防的演变的今天。我想和大家聊一个看似遥远，实则与我们每个网站管理员、运维工程师、开发者息息相关的核心问题：DNS污染。为什么有时用户会发现，他们本想访问的网站，却被引向了一个完全不相干的页面，仿佛被导向了虚假的彼岸？这背后，隐藏着怎样的技术机制和挑战？&lt;/p>
&lt;h3 id="问题的背景互联网的电话簿与它的脆弱性">
 问题的背景：互联网的“电话簿”与它的脆弱性
 &lt;a class="anchor" href="#%e9%97%ae%e9%a2%98%e7%9a%84%e8%83%8c%e6%99%af%e4%ba%92%e8%81%94%e7%bd%91%e7%9a%84%e7%94%b5%e8%af%9d%e7%b0%bf%e4%b8%8e%e5%ae%83%e7%9a%84%e8%84%86%e5%bc%b1%e6%80%a7">#&lt;/a>
&lt;/h3>
&lt;p>想象一下，互联网是一个巨大的城市，每个网站都有一个独特的门牌号（IP地址）。而我们人类更习惯记住街道名称（域名），比如 &lt;code>feige301.com&lt;/code>。这时候，就需要一个“电话簿”服务，也就是DNS（Domain Name System），来将这些易记的街道名称翻译成机器能理解的门牌号。当你在浏览器中输入一个域名时，你的电脑会向DNS服务器查询这个域名对应的IP地址，然后才能建立连接，访问网站。&lt;/p>
&lt;p>这个过程在绝大多数情况下都高效且透明。然而，当这个“电话簿”被篡改，或者查询过程中有人恶意插手时，问题就出现了。用户可能被误导到错误的地址，这不仅会导致网站流量的无故流失，更可能带来数据泄露、品牌声誉受损，甚至是更严重的安全风险。对于那些依赖网络连通性提供服务的“高并发商业站点”和“数字娱乐平台”而言，这无疑是致命的打击。用户无法访问，业务便无法开展，损失难以估量。&lt;/p>
&lt;p>我们面临的困境是：DNS作为互联网的基础设施，其设计之初并未充分考虑到如今复杂的网络环境和潜在的恶意干扰。特别是在一些“局部局域网环境”或“特定网络区域”中，由于“中间设备”的介入或“某地区运营商”策略的影响，DNS解析过程的纯净性常常受到挑战。用户痛点显而易见：如何确保域名解析的准确性和服务的可达性，成为网站运营者亟需解决的核心难题。&lt;/p>
&lt;p>接下来，我将从技术层面深入剖析DNS污染和劫持的原理，结合一个真实的案例，揭示其背后的技术细节和UDP协议的脆弱性，并最终探讨如何通过先进的多级DNS解析策略来应对这些挑战。&lt;/p>
&lt;hr>
&lt;h3 id="一-dns工作原理回顾构建连接的基石">
 一、 DNS工作原理回顾：构建连接的基石
 &lt;a class="anchor" href="#%e4%b8%80-dns%e5%b7%a5%e4%bd%9c%e5%8e%9f%e7%90%86%e5%9b%9e%e9%a1%be%e6%9e%84%e5%bb%ba%e8%bf%9e%e6%8e%a5%e7%9a%84%e5%9f%ba%e7%9f%b3">#&lt;/a>
&lt;/h3>
&lt;p>要理解DNS污染，我们首先需要快速回顾一下DNS的基本工作原理。这个过程可以概括为以下几步：&lt;/p>
&lt;ol>
&lt;li>&lt;strong>用户发起查询：&lt;/strong> 当你在浏览器中输入 &lt;code>example.com&lt;/code> 后，操作系统会首先检查本地DNS缓存。如果找到，直接返回IP地址。&lt;/li>
&lt;li>&lt;strong>递归解析器：&lt;/strong> 如果本地没有缓存，操作系统会将查询请求发送给配置的DNS递归解析器（通常是你的“某地区运营商”提供的DNS服务器，或是公共DNS服务如Google DNS、Cloudflare DNS）。&lt;/li>
&lt;li>&lt;strong>根服务器查询：&lt;/strong> 递归解析器会向全球13组根DNS服务器（Root Servers）之一发起查询，询问 &lt;code>.com&lt;/code> 域名的顶级域名服务器（TLD Server）的地址。&lt;/li>
&lt;li>&lt;strong>TLD服务器查询：&lt;/strong> 根服务器返回 &lt;code>.com&lt;/code> TLD服务器的地址。递归解析器再向 &lt;code>.com&lt;/code> TLD服务器查询 &lt;code>example.com&lt;/code> 的权威DNS服务器地址。&lt;/li>
&lt;li>&lt;strong>权威DNS服务器查询：&lt;/strong> &lt;code>.com&lt;/code> TLD服务器返回 &lt;code>example.com&lt;/code> 的权威DNS服务器地址。递归解析器最后向 &lt;code>example.com&lt;/code> 的权威DNS服务器查询 &lt;code>example.com&lt;/code> 对应的IP地址。&lt;/li>
&lt;li>&lt;strong>返回IP地址：&lt;/strong> 权威DNS服务器返回 &lt;code>example.com&lt;/code> 对应的IP地址。递归解析器将此IP地址缓存起来，并最终返回给用户的操作系统。&lt;/li>
&lt;li>&lt;strong>建立连接：&lt;/strong> 用户的浏览器获得IP地址后，便可与目标网站建立TCP连接，加载网页内容。&lt;/li>
&lt;/ol>
&lt;p>整个过程就像一个层层递进的查询，确保最终能找到正确的“门牌号”。而这个过程中，大部分的查询（尤其是客户端到递归解析器）都基于UDP协议进行，这正是其脆弱性的根源之一。&lt;/p>
&lt;h3 id="二-什么是dns污染与劫持">
 二、 什么是DNS污染与劫持？
 &lt;a class="anchor" href="#%e4%ba%8c-%e4%bb%80%e4%b9%88%e6%98%afdns%e6%b1%a1%e6%9f%93%e4%b8%8e%e5%8a%ab%e6%8c%81">#&lt;/a>
&lt;/h3>
&lt;p>尽管它们常常被混为一谈，但DNS污染和DNS劫持在技术实现上略有差异，但其核心目标都是篡改DNS解析结果，将用户导向错误的IP地址。&lt;/p>
&lt;h4 id="1-dns污染-dns-pollution">
 1. DNS污染 (DNS Pollution)
 &lt;a class="anchor" href="#1-dns%e6%b1%a1%e6%9f%93-dns-pollution">#&lt;/a>
&lt;/h4>
&lt;p>DNS污染，更准确地说，是DNS缓存投毒（DNS Cache Poisoning）的一种表现形式。它的核心原理是：攻击者或“中间设备”在用户向其DNS递归解析器发起查询后，抢在真正的权威DNS服务器响应之前，向用户的递归解析器发送一个伪造的、带有错误IP地址的DNS响应包。&lt;/p>
&lt;p>&lt;strong>工作机制：&lt;/strong>
由于DNS查询通常使用UDP协议，这是一种无连接协议，没有像TCP那样的三次握手来建立会话和验证通信双方的身份。攻击者可以轻易伪造源IP地址（通常伪装成权威DNS服务器的IP），并预测DNS查询的ID（一个16位的随机数）。当递归解析器收到一个查询请求后，它会等待来自权威服务器的响应。如果攻击者能够在此期间，快速地向递归解析器发送一个伪造的响应，且响应的查询ID、源IP和端口都匹配，那么递归解析器很可能就会接受这个伪造的响应，并将其缓存起来。之后所有查询该域名的用户都会被导向这个错误的IP地址，直到缓存过期。&lt;/p></description></item></channel></rss>