土耳其 2014 年公共 DNS 拦截：解析器路由成为问责试金石

摘要

2014 年 3 月 29 日至 4 月 7 日，Google 和 RIPE Atlas 的证据显示，发往公共 DNS 递归解析器的流量可能到达土耳其网络内部的应答系统，而非预期的外部服务。这些观察结果确立了测量视角点上的拦截，而不是全国范围内完全相同的配置。
问责取决于决定运行路径和应答的控制环节：路由宣告与安装、转发、解析器身份、DNS 响应完整性、独立测量以及经核实的恢复。注册局记录、DNSSEC、RPKI 和加密 DNS 各自只覆盖这一链条的一部分。

熟悉的地址，不熟悉的服务

将计算机或路由器改为使用公共递归 DNS 解析器，感觉像是一种直接的选择。用户输入诸如 8.8.8.8 的地址，向该地址发送 DNS 查询，并期望 Google 的公共解析器接收它。在正常运行中，这种期望是有用的。然而，它并不能证明网络对数据包做了什么。地址表达的是预期目的地。路由和转发状态决定实际接收流量的系统，而该系统上的软件决定返回的答案。

2014 年 3 月 29 日至 4 月 7 日期间，这种区别在土耳其网络内部变得切实可见。测量显示，发往公共解析器 IP 地址的流量到达的是土耳其基础设施内部的应答系统，而非预期的外部服务。Google 表示，已确认其公共 DNS 服务正被大多数土耳其互联网服务提供商拦截的可信报告。RIPE Atlas 测量提供了独立的观察：土耳其的一些探针经历了突然的延迟变化，并收到了与土耳其基础设施相关的应答。其他探针则未表现出相同行为。

该事件之所以是一个网络基础设施问责案例，是因为客户端配置可以保持不变，而实际服务身份却发生了变化。仅仅检查设置面板中显示的解析器地址是不够的。充分的说明必须追问：宣告了哪条路由，安装了哪条路由，数据包被转发到了哪里，哪个递归解析器作出了应答，它返回了什么 DNS 数据，是否进行了完整性验证，以及预期服务何时恢复。这些都是相关的问题，但不可相互替代。

公开记录并不支持单一、简单的机制叙述。BGPMon 和 Internet Society 的叙述描述了高度具体的 BGP 宣告，包括针对一个 Google 解析器地址的 /32 宣告。RIPE 68 上展示的材料也将路由作为拦截手段进行了讨论。Stéphane Bortzmeyer 的重建补充了一个重要限定：Turk Telekom 的 Looking Glass 并未将重定向呈现为具有预期可见路径的普通 BGP 路由，这表明至少部分效果可能是由本地静态或内部路由产生的。因此，公开观察支持的是在测量视角点上发生拦截，而不是证明存在一种全球传播的 BGP 劫持、一种路由配置或一种全国范围内统一的应答策略。

这种不确定性不是需要隐藏的弱点。它定义了问责问题的边界。即使决定性路由在公开全球路由源中不可见，路由事件也可能影响数据平面。即使 IP 注册局正确识别了预期资源持有者，DNS 应答也可能是虚假的。路由源控制可以拒绝一类未经授权的宣告，却可能漏掉本地安装的路由。已签名的 DNS 响应可以为已签名区域提供数据完整性，却不能认证通往递归解析器的路径。加密 DNS 可以认证之后的传输通道，却不能保证该通道始终可达。有用的回应是分层证据模型，而不是声称某项安全技术本可以使事件不可能发生。

有界事件：3 月 29 日至 4 月 7 日

相关时间线始于土耳其接入网络的测量显示，发往公共递归解析器的流量处理方式发生了变化。当用户选择外部解析器而非接入提供商提供的解析器时，传统的 DNS 封锁可以被绕过。这里所讨论的 2014 年升级不同于接入提供商仅从其自有的广告 DNS 服务返回被操纵的应答。用户可以明确选择公共解析器地址，但数据包仍可能被传递到接入网络内部的另一个应答系统。

Google 当时的声明确认了该公司表示能够就其自身服务确定的事实：可信报告表明 Google 的公共 DNS 地址正被拦截，Google 将这一行为归因于大多数土耳其 ISP。这一措辞既应被重视，也应被克制看待。这是服务运营商确认发往其解析器的流量未能可靠到达它。它并不是所有参与自治系统、每项路由器变更、每个伪造应答或每位受影响用户的公开清单。该声明也没有提供土耳其运营商的完整内部日志，或指明批准每项配置的人员。

RIPE Atlas 提供了第二个基于测量而非公司断言的时钟。土耳其的探针此前以某种延迟模式到达 Google 的任播解析器。事件期间，一些探针记录到延迟突然降至不到十毫秒。从这些接入网络如此之快地抵达的解析器，与此前到达预期 Google 实例的路径不一致，但与一个近得多的应答系统是一致的。对某些探针的 DNS 测试还返回了与 Turk Telekom 基础设施相关的地址。两个探针未表现出相同效果，这一观察防止了把测量集合视为完全一致。

事件的结束也有不止一个时钟。RIPE 的叙述观察到，虚假解析器先在 Twitter 相关查询上停止重定向，随后虚假的 8.8.8.8 服务本身才消失。4 月 7 日傍晚，延迟恢复到此前的模式。这些观察至少区分了三种状态：流量仍到达非预期解析器；该解析器对某个被查询名称的策略发生了变化；以及向预期公共服务的转发已恢复。把三者统称为“封锁结束”会丢弃基础设施证据。

因此，有界记录从 3 月 29 日首次测量到拦截，一直延伸到 4 月 7 日预期延迟行为恢复。更早的限制解释用户为何可能选择公共 DNS，但不是本分析的主题。之后的 DNS 干扰事件、更广泛的政治争端及无关的路由事件均在此边界之外。保持边界收窄，使我们能够评估控制解析器可达性的系统和证据，而不把技术重建变成对土耳其互联网政策的泛泛论述。

Google 确认了什么——以及什么仍在其视野之外

Google 运营预期服务，宣告其任播地址，并能观察到达其解析器站点的流量。它还可以将用户报告和网络测量与预期服务行为进行比较。因此，其声明是强有力的证据，证明该公司并不认为在土耳其观察到的应答系统是合法的 Google Public DNS 实例。这也是将“大多数土耳其 ISP 参与其中”这一主张归因于 Google 的恰当依据。

然而，外部解析器运营商对安装在接入网络内部的路由视野有限。如果有运营商为 8.8.8.8 引入本地路由，数据包可能根本不会离开该运营商的网络，也永远不会到达 Google 可见的观察点。从 Google 一侧看，症状可能是流量缺失、地理需求变化、意外应答的报告或第三方测量。这些症状可以确立服务身份失败，却无法揭示导致失败的具体命令、路由器、策略对象或审批链。

这种可见性的划分对责任归属很重要。Google 控制预期公共解析器、其合法宣告、围绕该服务的监测以及公开事件沟通。它并不控制土耳其接入运营商的转发表。反过来，接入运营商可以控制本地和学习的路由、转发策略、DNS 拦截设备、用户通知以及其网络内部的恢复。它可能不控制 Google 的任播工程，也不控制通过该解析器查询的每个域名的签名状态。负责任的还原必须把每个参与者实际能够保存和披露的证据分配给它。

RIPE Atlas 测量了什么

RIPE Atlas 将分布式探针转变为观察点。对于这一事件，其重要性与其说在于探针数量，不如说在于它能够区分的事实类型。探针可以向配置的解析器地址发送流量，测量往返时间，发出受控 DNS 查询，并比较返回的数据。事件前、中、后的测量可以暴露变化，即使接入网络并未公开其配置。

延迟是一个信号。从此前路径的延迟突然降至十毫秒以下，这本身并不能说出是哪台路由器发生了变化，也不能证明存在 BGP 宣告。它确实表明数据包-响应交换在网络意义上变得近得多。在任播服务中，路径可以合法改变，附近的合法实例也可以降低延迟。因此，仅凭延迟无法认证拦截者。但在本案中，延迟变化与解析器响应证据以及 Google 对新观察到的服务并非其自身的否认相结合。这种组合比任何单一观察都明显更强。

返回的 DNS 数据是另一个信号。RIPE 的叙述报告称，某些测试的应答指向 Turk Telekom 基础设施。该证据涉及应答解析器发出的数据。它本身并不能揭示查询是如何到达那里的。本地策略路由、静态主机路由、内部路由协议、更具体的 BGP 宣告或某种数据包重定向系统都可以改变接收服务，同时在控制平面记录中留下不同的痕迹。应答有助于确定发生了服务替换；它不是完整的路由追踪。

探针之间的差异同样有价值。两个探针没有看到相同效果。它们可能连接在不同的网络、受到不同的路由策略、位于特定拦截点之外，或在不同的时间受到影响。现有证据无法确定哪种解释适用。但它确实确立了一条分析规则：来自一组探针的测量结果不能被推广到每个土耳其 ISP、每个解析器地址或每个用户。负面观察不是应被丢弃的噪声；它们是对主张的边界。

时间序列增加了第三种证据形式。如果延迟突然下降、保持在新状态，之后又回到此前的区间，这一序列可能标记转发状态的变化。如果某个选定名称的应答先于延迟恢复正常，则可能标记解析器策略的变化，而非预期解析器仍保持在路径上。不同的恢复时间说明运营商为何应同时保存路由状态和应用响应。某一时刻干净的 DNS 应答并不能证明数据包再次到达预期解析器。

RIPE Atlas 也说明了外部测量的局限。探针从其自身的接入点观察，可以记录延迟、可用路径证据和 DNS 结果。它无法揭示静默路由器的配置、私有变更记录或审批者身份。这些测量确立了在已观察的土耳其视角点上路径和响应发生了阶段性变化，且此前的延迟模式于 4 月 7 日恢复。它们并不重建每条内部路由。

七个不能一概归为“DNS 劫持”的事实

“DNS 劫持”这个说法很方便，但它可能掩盖控制链条。把 2014 年的证据分为七个独立事实会更清晰。

第一是路由宣告。在 BGP 中，网络使用源和路径属性宣告某个 IP 前缀的可达性。BGPMon 和 Internet Society 的叙述描述了针对公共 DNS 地址的高度具体宣告，包括针对一个 Google 解析器地址的 /32。这是关于那些观察者所报告的控制平面消息的证据。它并不自动证明每个网络都接受了该宣告，也不证明同一宣告在全球可见。

第二是已安装路由。路由器评估学习到的路由和本地策略，然后为路由和转发状态选择条目。路由可能因 BGP、内部路由协议、策略路由、静态条目或其他本地机制而被安装。Bortzmeyer 的 Looking Glass 证据在这一层很重要：在所检查的视图中不存在预期的普通 BGP 表示，这支持至少部分流量可能存在本地或静态重定向。已安装路由可以在不显现为新全球源事件的情况下控制数据包。

第三是转发目的地。已安装的转发状态决定下一跳，但操作问题是数据包实际去了哪里。设备行为、隧道、过滤、等价路径和拓扑可能产生高层路由记录无法完全表达的结果。数据平面探针有助于测试这一层。发往 8.8.8.8 的数据包可以保留该目的地址，却仍被传递到接入网络内部的系统。

第四是解析器身份。在 UDP 或 TCP 端口 53 上接收流量的系统可能将自己表现为递归解析器并应答请求，但持有发往某地址的流量并不能证明它就是用户所期望的服务。传统 DNS 并未提供明文查询到 IP 地址与 Google 运营身份之间的加密通道绑定。任播为该服务增加了合法的多重性，但未经授权的本地接收者并不会仅仅因为地址是任播而变得合法。

第五是DNS 应答。替代解析器可以返回正确答案、被操纵的答案、错误、无应答，或对不同名称返回不同答案。RIPE 观察到，Twitter 相关查询的策略在非预期解析器消失之前就已改变，这证明了应答和解析器身份必须分开测试。来自错误服务的正确响应并不能证明预期路径已恢复。虚假响应证明该查询存在数据问题，而非所有查询都被篡改。

第六是完整性验证。DNSSEC 可以让验证器通过有效信任链认证已签名的 DNS 数据。它不识别路由，不认证到 8.8.8.8 的明文连接，不为每个区域签名，也不强制拦截者提供可用性。验证状态是一项必须为每次测试记录的独立观察。

第七是用户影响。用户可能得到不同的目的地、错误、超时或没有可见变化，具体取决于被查询的名称、缓存状态、验证行为、网络和时间。公开证据没有枚举所有用户，也没有量化普遍损失。测量到的替换确立了严重的控制失败，因为所选择的网络服务可能被无形替换，但它不允许给出单一损害数字，也不允许断言每个用户都经历了相同结果。

这个七部分模型防止某项证据承担其无法承担的工作。路由收集器可能记录到宣告，却看不到本地转发覆盖。Looking Glass 可能显示已安装的控制平面路由，却不是每个数据包的确切路径。DNS 响应可能暴露操纵，却不指出路由来源。DNSSEC 失败可能检测到无效的签名数据，却不指明重定向流量的运营商。当各层的记录按时间和视角点关联而不是被压缩成口号时，问责才会改善。

/32 报告与本地路由证据

一个 /32 IPv4 前缀标识一个地址。宣告如此具体的路由，在网络接受它的情况下，可以成为吸引流量的有效方式，因为最长前缀匹配通常偏好最具体的已安装路由。因此，BGPMon 和 Internet Society 的描述为定向拦截某个解析器地址而不转移更大的周边前缀提供了一种合理机制。它们的报告应保留在还原中，不应被稀释成“涉及路由”的模糊说法。

它们也不应被扩展到记录不支持的范围。监测系统观察到的宣告有一个由导出、导入和过滤策略决定的传播范围。一些网络会拒绝超过常见操作限制的前缀；其他网络可能在有限上下文中接受或保留它们。报告的 /32 存在并不能证明它到达了每个土耳其接入路由器、每个路由器都选择了它，或它造成了每个 RIPE Atlas 结果。

Bortzmeyer 的证据指向了一条不同且可能互补的路径。在他检查的 Turk Telekom Looking Glass 视图中，重定向并未表现为具有普通 AS 路径的常规 BGP 路由。他的重建表明，本地静态路由或运营商内部的另一条路由可以解释至少部分观察到的行为。这样的路由可以将用户流量导向附近的解析器，同时对外部收集器保持不可见。它也可以与其他地方看到的 BGP 宣告共存。

除非坚持单一全国配置，这两组证据并不互相排斥。特定宣告可能影响一个提供商或路由域，而另一个提供商使用了本地机制。公共 BGP 信号可能在某一时间存在，而内部路由持续更久。不同的公共解析器地址可能被区别对待。这里的记录无法解决这些可能性，因此准确的文章必须把它们留作开放问题。

这种区别改变了控制评估。如果原因是未经授权的外部源宣告，那么源授权、导入策略、前缀过滤和路由监测直接相关。如果原因是本地配置的静态路由，路由源验证器可能永远不会评估它。配置治理、特权变更记录、转发表检查和独立数据平面探针则成为决定性因素。如果两者都存在，只依赖其中一类控制会留下盲区。

它也改变了恢复时预期的证据。移除 BGP 宣告并不能证明本地路由已被删除。在一个边缘删除本地路由并不能证明每个接入区域都已收敛。在路由收集器中看到预期的 Google 源并不能证明用户的数据包到达了 Google。恢复需要来自经历拦截的网络的匹配的控制平面和数据平面观察集。

因此，“BGP 劫持”应被视为对所报告路由活动的归因描述，而不是已证实的通用机制。“公共 DNS 拦截”是更稳妥的总称。它陈述了观察到的服务替换，同时留出了逐运营商确定是 BGP、内部路由、静态路由还是其他转发控制导致的空间。

任播：地址稳定，合法实例众多

Google Public DNS 使用任播，允许同一服务地址从多个合法位置宣告。路由策略将用户引导至一个可达实例。这种设计可以改善延迟和弹性，但也意味着一个 IP 地址并不对应一台固定的物理服务器或一个不可变的地理目的地。

合法的任播不会抹去服务身份。多个实例作为同一预期服务的一部分，在经授权的路由和运营控制下运行。一个位于不相关接入网络内的系统，不会仅仅因为收到发往 8.8.8.8 的数据包就成为 Google 解析器。区别在于经授权的运营、路由证据、服务行为，以及可获得的认证传输——而非地址的视觉熟悉度。

任播也使简单的延迟测试不再充分。更低的延迟可能来自合法的新的站点、路由策略变化或未经授权的附近接收者。在土耳其事件中，延迟下降之所以有意义，是因为它与意外的 DNS 响应和 Google 对拦截的确认同时发生。孤立地看，“比昨天更快”既不能证明不当行为，甚至不能证明故障。

因此，针对任播解析器的适当问责记录应包括前缀和预期源、相关网络应可达的站点或服务区域、随时间的路由变化、主动测量以及响应特征。现代认证解析器传输可以增加一个加密的服务身份信号。它们仍然不能替代转发证据，因为认证端点可能被封锁，而连接失败即使阻止了冒充，也可能对用户产生重大后果。

DNS 应答与 DNSSEC 的有限作用

DNSSEC 常在涉及虚假 DNS 数据的事件后被提起。它的贡献重要，但比路由保护更窄。DNSSEC 在区域层面对 DNS 数据签名，让验证器从已建立的信任锚构建信任链。对于拥有完整链的已签名名称，验证客户端或验证递归解析器可以检测到未经有效签名而被篡改的应答。

这一特性可能使某些伪造应答无法通过验证。它不能阻止路由器选择更具体的路由，不能阻止网络安装静态主机路由，也不能阻止数据包到达非预期的递归解析器。DNSSEC 认证数据，而非通往 8.8.8.8 的路径。它也不意味着每个域名都已签名、每个客户端都独立验证，或每次失败都被安全地呈现给用户。

验证的位置很重要。典型的存根解析器可能要求递归服务执行验证，然后信任该服务的结果。如果发往该递归服务的流量通过未认证的 DNS 传输被透明地传递到另一个解析器，用户就失去了假定的服务边界。独立验证的客户端可以自行测试签名，但它仍可能被拒绝服务、为未签名区域获得未签名数据，或被阻止获取验证所需的材料。

可用性是单独的属性。拦截者可以丢弃数据包、返回错误、阻止大响应或使验证失败。在这些情况下，DNSSEC 可能把未被发现的替换变成可见的解析失败，这很有价值，但它并不能保持预期服务可达。用户影响可能从被发往错误地址转变为无法解析名称。这在完整性意义上是安全改进，却不是网络事件已被阻止的证明。

因此，负责任的 DNS 评估会提出四个独立问题：预期解析器是否收到了查询？应答解析器是否返回了预期数据？签名数据是否被正确验证？服务是否可用？DNSSEC 影响第三个问题，并可能影响第二个。它不能单独回答第一个，也不能保证第四个。

加密 DNS 是后来的背景，不是回溯性要求

DNS over TLS 和 DNS over HTTPS 是在 2014 年事件之后标准化的。它们应被用来解释当前可用于解析器身份和机密性的控制，而不是改写历史基线，或暗示土耳其网络未能部署当时尚不存在后来形态的标准。

这两种方法都能在经认证的加密通道内保护查询。如果客户端被配置为认证预期解析器端点并正确验证证书，那么缺乏所需凭据的替代系统就不应能够成功冒充该端点。这增加了一个普通明文 DNS 到 IP 地址所不具备的服务身份属性。

这种保护仍然是有条件的。引导解析、证书验证、端点配置、回退行为、企业策略和客户端实现都会影响结果。网络可以封锁加密传输、对其进行限流、重置连接或使端点不可达。静默回退到未认证 DNS 的客户端可能重新引入原始的信任问题。故障关闭的客户端保持了身份，但可能失去名称解析。

加密 DNS 也不认证 BGP，不证明路由合法。当认证通道失败时，它可以揭示错误路由的实际后果；在预期身份下，它可以防止路径上的系统读取或替换成功的应用层消息。仍需要路由监测和数据平面测量来确定端点为何变得不可达以及数据包去了哪里。

路由源验证与本地路由盲区

资源注册局和路由授权系统提供了关于谁有权发起地址空间的重要证据。它们是问责记录：允许运营商和观察者将 BGP 宣告与经授权的源进行比较。它们不会把配置推送到每台路由器，不会强制每个导入决策，也不会阻止本地转发覆盖。

如 IETF 模型所述，路由源验证（Route Origin Validation）通过将收到的 BGP 路由的源和前缀长度与路由源授权（Route Origin Authorizations）进行比较来对其分类。在存在适当授权数据且可用的地方，针对受保护 Google 前缀的伪造源可以被分类为无效。应用拒绝策略的运营商随后可以拒绝该路由。这些条件很重要。授权覆盖范围、最大长度设置、验证器可用性、路由器策略和运营处理决定结果。

源验证不是完整的路径验证。一条保留授权源但经过非预期路径的路由不在其核心决策范围之内。对土耳其证据而言更重要的是，接入网络内部插入的静态路由可能根本不是收到的 BGP 路由。它可以在不制造供验证器分类的源事件的情况下重定向用户流量。内部路由或策略转发规则可能造成类似的可见性缺口。

这就是 /32 报告和 Bortzmeyer 的保留意见要求分层控制的原因。在域间边缘，运营商可以维护明确的导入策略，过滤不合理的更具体前缀，监测源和路径变化，并将观察到的宣告与注册局和授权数据进行比较。在网络内部，他们可以控制特权路由变更，记录静态和策略路由，审查转发条目，并从面向用户的位置测试已知外部目的地。当两种控制环境都失效或记录不完整时，独立测量可以检测到不匹配。

NIST 关于弹性域间流量交换的指南同样支持由路由安全、监测、响应和连续性构成的防御，而非单一开关。监测应包括对意外的更具体宣告以及影响关键公共基础设施地址变化的告警。然而，仅靠公共收集器无法看到每一个内部决策。运营商需要本地遥测，外部各方需要不假定控制平面能说明一切的数据平面测试。

过滤也需要精确。关于 /32 的一刀切规则不是充分的事件教训。相关要求是运营商记录其接受的内容、例外存在的原因，以及如何验证通往关键目的地的实际转发。过滤可以在降低风险的同时，让本地配置和服务替换仍未得到测试。

注册局准确性仍然是必要的，尽管它不是强制执行。调查人员需要可靠的前缀、ASN、联系方式和授权记录，以识别预期资源持有者、比较源、通知负责团队并重建路由事件。不准确的记录会延缓响应并模糊责任。然而，准确的记录不能迫使数据包服从它们。必须观察运行中的路由和转发状态。

因此，恰当的主张是适度且操作性的。在适当的授权和策略条件下，基于 RPKI 的源验证可以解决某些未经授权的 BGP 源场景。它不一定能检测或防止本地/静态拦截、授权源路径问题、DNS 应答操纵或传输封锁。其价值是证据链中一个有边界的控制环节。

责任随实际控制而定

当问责跟随每个参与者能够运营、检查和恢复的系统时，它会变得更清晰。

接入运营商控制面向用户的路由和转发策略。他们能够知道公共解析器地址的路由是从外部学习的、内部注入的、静态配置的，还是由其他设备重定向的。他们可以保存路由器配置历史、路由选择日志、转发条目、设备时钟、变更工单以及替代解析器的位置。他们还控制客户沟通和移除本地拦截的行为。如果运营商接受了外部宣告，即使它并未发起路由，它也控制自己的导入决策。

转接和互联运营商控制跨其会话的传播，并能观察跨越其边界的宣告。他们的相关证据包括收到和宣告的路由、过滤决策、会话变化和通知。他们可以限制未经授权域间宣告的传播范围。他们不一定能检测到停留在下游接入网络内部的静态路由，因此他们干净的记录不能否定本地拦截。

预期解析器运营商（核心示例中是 Google）控制合法任播宣告、解析器实例、服务遥测、外部监测和事件披露。Google 可以声明新观察到的应答系统是否属于其服务，并可从可用视角点测试可达性。它不能直接移除安装在另一个运营商内部的路由，也不能提供它不拥有的私有配置记录。

测量组织和网络研究者控制独立探针、收集方法、时间戳、分析以及局限性披露。RIPE Atlas 可以显示特定视角点的路径和应答行为发生了变化。BGP 监测可以记录对其收集器可见的宣告。Looking Glass 分析可以测试运营商从其选定路由器暴露了什么。每个系统都有可见性边界，负责任的报告要求把这一边界附在发现之上。

域名运营商控制其区域是否签名以及 DNSSEC 材料是否得到正确维护。他们的决定影响针对其名称的伪造数据是否能被正常工作的验证器以密码学方式拒绝。他们不控制通往用户递归解析器的路由。为区域签名不能恢复解析器可达性，也不能阻止接入网络丢弃查询。

软件和设备供应商控制客户端验证、传输认证、回退行为、错误呈现和可观测性。在 2014 年，常见的明文解析器行为几乎不能直接证明配置的公共服务作出了应答。用户和网络管理员可以选择解析器地址，有时可以运行测试，但他们通常无法检查隐藏路由或强迫提供商遵循预期目的地。配置选择不是对基础设施的控制。

公共机构或其他指导机构只有在有归因证据确立了指示、法律依据或运营角色的情况下才具有相关性。本文限定范围内的材料并不提供完整的私有法律记录或决策链。技术证据可以识别路由和解析器控制点，而不把这些观察转化为关于未观察到的命令或个人意图的结论。

这一映射避免了两个对称错误。它不使注册局或解析器运营商成为另一个网络内部路由的主宰。它也不允许接入运营商把熟悉的目地地址当作其已将流量转发到预期服务的证明。每个参与者对其实际可达范围内的证据和控制负责，跨边界事件要求将这些记录连接起来。

保留证据的恢复与复发测试

恢复应当被证明，而不是从一个看似正常的应答推断出来。土耳其测量暗示了一个未来事件流程可以明确化的序列。

第一步是冻结时间线。运营商和独立观察者应同步时间戳，并保存 BGP 更新、本地路由信息、转发条目、配置更改、解析器日志、在合法且适度范围内的数据包捕获、探针结果和事件通信。记录应区分宣告何时出现、路由何时被选中、用户流量何时改变目的地、应答何时改变，以及预期服务何时再次可达。

第二步是确定路由范围。公共路由收集器可以测试是否存在外部可见的非预期源或更具体宣告。邻居记录可以显示哪些会话收到或导出了它。运营商本地视图可以揭示公共源遗漏的内部和静态路由。在面向用户设备上检查转发表可以确定哪个下一跳实际控制数据包。任何单一视图都不应被接受为其他视图的替代。

第三步是从多个相关网络测试数据平面。探针应测量到事件中涉及的每个解析器地址的延迟、路径、丢包和可达性。结果需要探针的网络和位置背景，因为 2014 年两个土耳其探针与受影响模式不相符。多样化的视角点可以揭示恢复是全国性的、特定提供商的、区域性的还是部分的。它仍不应被描述为超出测量集合的普遍情况。

第四步是识别应答服务。受控 DNS 查询可以比较响应码、记录、生存时间值、递归行为、DNSSEC 处理和其他稳定的服务特征。在配置了现代认证解析器端点的情况下，可以提供更强的身份证据。调查人员应谨慎对待指纹：相似的软件行为不是最终的所有权，正确答案也不能确立预期解析器。

第五步是区分应答恢复与路径恢复。测试应包括此前受影响的名称、已签名名称、未签名名称、故意无效的 DNSSEC 测试用例以及中性对照。如果选定应答恢复正常，而延迟和服务身份仍保持异常，拦截状态就没有完全关闭。2014 年的序列——应答策略在虚假解析器消失之前改变——说明了这一条件为何重要。

第六步是根据发现的机制验证路由防护。对于外部源事件，可以包括授权数据、源验证状态、导入决策、更具体策略、监测告警和传播撤销。对于本地或静态路由，可以包括配置移除、特权变更审查、内部路由检查、逐设备转发检查，以及确认其他地方没有等效策略。如果机制仍然未知，两个分支都需要测试。

第七步是测试失败情况下的连续性。应观察 DNSSEC 验证，而不是假定它。在当今使用认证加密 DNS 的地方，应测试正确的端点验证和端点不可达时的明确行为。运营商应验证回退不会违反策略，将认证解析器静默替换为未认证解析器。这些检查不保证可用性；它们使失败模式可见且有界。

第八步是独立确认。运营商仪表板、外部探针、预期解析器运营商和路由监测器应共同确认路由、端点身份、应答和受影响范围。关闭记录应确定所测试的解析器地址和网络、路由来源、任何外部宣告或本地路由、应答系统、验证和传输结果、每一层的恢复时间以及剩余的未知事项。结果应保留足够长的时间以测试复发，而不是在一个通过样本之后就宣布完成。

未知事项、法律限制与归因纪律

有几个重要事实仍在本公开记录范围之外。每个 ISP 的确切配置未知。完整的 BGP 路径、内部路由、静态条目、转发设备和受影响的解析器地址集合不可得。BGP 观察者报告的机制与 Bortzmeyer 指出的本地路由可能性之间的比例，无法从这些材料中量化。

记录也没有列举每个受影响用户、每个被更改的域名应答或经济损失。它不包含所有私有日志、内部指示、变更审批、法律文件或补救测试。它无法确定谁做出了每个决定，也无法确定每个网络是否在同一指示下行动。这些空白应保留为空白，而不是用推断填补。

本文中的“拦截”描述的是测量到的网络行为：发往预期公共解析器的数据包到达了另一个应答系统。它不是对犯罪意图、过失、监视、责任或特定违法行为的认定。技术记录可以支撑运营商和政策制定者的问题，但法律结论需要本重建之外的证据与法律。

归因对正面主张同样重要。Google 的“大多数土耳其 ISP”声明属于 Google。/32 的描述属于 BGPMon 和 Internet Society 的报道。延迟、应答、探针差异和恢复观察属于 RIPE Atlas。本地/静态路由的限定属于 Bortzmeyer 的重建。保持这些标签的附着，可以防止二手叙述获得比其底层证据更高的确定性。

解析器路由作为问责测试

土耳其 2014 年的公共 DNS 拦截暴露了配置身份与运行现实之间的差距。用户可以在设置面板中保留 8.8.8.8，而接入网络将数据包传递给另一个递归解析器。没有任何单一记录能弥合这一差距。/32 的报告不能证明通用机制；Looking Glass 可能漏掉转发状态；RIPE Atlas 可以显示替换，却不能显示内部审批者；DNSSEC 不认证路由；源验证可能漏掉本地静态路由；认证加密 DNS 不能保证可达性。

实用标准是分层的、以证据为主导的。资源和授权记录确定预期控制。路由遥测显示宣告和选定的路径。转发探针显示数据包去了哪里。解析器测试显示哪个服务应答以及它返回了什么。验证和认证传输在其边界内测试完整性和身份。带时间戳的独立测量显示恢复和复发。

这一标准不要求声称每个土耳其网络都使用了相同方法或每个用户遭受了相同损害。它要求的是某种更持久的东西：每个具有实际控制的参与者都应能够说明其基础设施做了什么、何时变化、选定的公共服务如何被取代，以及预期路径和服务如何恢复。在路由网络中，用户选择的地址是一个请求。问责始于证据：运行中的网络如何尊重——或替换——这个请求。

土耳其 2014 年公共 DNS 拦截让解析器路由成为问责试金石

摘要