原文地址：https://blog.cloudflare.com/fixing-reachability-to-1-1-1-1-globally/
原文标题：Fixing reachability to 1.1.1.1, GLOBALLY!
原文作者：Marty Strong
写于 2018/4/11 GMT+8 上午12:00:00
译者：驱蚊器喵#ΦωΦ
翻译水平有限，有不通顺的语句，请见谅。
最近我们推出了 我们的快速、隐私中心化(privacy-centric)的DNS解析服务1.1.1.1, 由我们的全球网络支持. 正如你所见，1.1.1.1 很容易记住, 同时也是一把双刃剑(a blessing and a curse). 在宣布该DNS服务器之前，我们开始测试到1.1.1.1服务器的连通性，测试主要是使用RIPE Atlas 的探测器. RIPE Atlas 项目是一个可拓展的在全球存放的小型监控设备集合. 目前里面有超过1万台活跃的探测器，分布在超过3千个网络中，为测试提供很好的优势. 我们发现，大量的探测器无法向1.1.1.1发送请求, 但是大多数探测器能够成功的请求到1.0.0.1 . 1.0.0.1 是我们分配给解析器的备用地址, 以供不能正常连接到1.1.1.1的客户端使用.
本文侧重于IPv4. 我们提供了4个IP (IPv4和IPv6各两个)，以便提供独立于IPv4或IPv6可达性的DNS解析器路由.
1.0.0.0/8 于2010年被分配给APNIC, 在此之前，它属于未分配的空间.
1 | % IANA WHOIS server |
未分配, 但不等同于私有保留使用!
我们发现
简单来说, 1.1.1.1 是不能使用了(BROKEN)! 好消息是, 对于大多数用户而言，1.1.1.1 现在是可达的. 我们努力确保问题可以解决，并继续联系运营商快速解决问题. 我们有信息可以搞定所有的事情, 但是这个是一个明确的提示，你不应该劫持未分配的IP地址. 我们发现超过10,000个中的超过1,000个探测器无法成功地对1.1.1.1发起DNS查询。一部分是因为所处的单个大型网络存在连通性问题, 比如，德国的一家大型运营商有近350个探测器连接上了，但是所有的探测器都失败了。测试方法非常简单:
- 对1.1.1.1运行DNS查找测试
- 找到查找失败的探测器的位置
- 运行
traceroute到受影响的探测器 - 分析结果
分析的结果非常复杂, 主要有以下三个原因:
- 内置了 1.1.1.1 ISP的路由器中使用 1.1.1.1 作为一个内部地址, 阻止了到达真正 1.1.1.1 的请求
- 黑洞了 1.1.1.1 ISP们在其网络内静态配置了到1.1.1.1的路由，防止流量通过内部路由或通过将数据包发送到null0而离开他们的网络
- 过滤了 1.1.1.1 ISP们在其网络中丢弃包含1.1.1.1的数据包
在这三个主要原因中，大多数案例是第一种或是第二种或是两者兼并存在！ 几个ISP的内部甚至有死循环的路由，他们在网络中广播了1.1.1.1，但实际上没有到达1.1.1.1的路由，所以数据包会绕过。
修复的时间到了
一旦我们缩小了针对每组探测器缩小范围，我们就开始联系ISP，说明发生的情况，几个网络运营商反应迅速，通告我们他们已经移除了到1.1.1.1的内部路由，大多数案例就是这样开始和结束的。有很多网络花了些时间才响应，但最终事件也同样完成了，移除了因为测试遗留的内部路由.
大多数的修复很好做，但是也很枯燥, 其中稍微有趣的事是，从CPE (客户端设备) 即家庭路由器、网关和无线接入点查找原因. 在Sonic员工的帮助下，我们很快发现 Pace 5268 是主要部署在美国(包括AT&T的广泛使用)的一种常见xDSL 调制解调器(modem)，使用1.1.1.0/29 作为内部通信. 我们请求 AT&T 的 NOC(译者注：Network Operations Center，即网络运营中心), 但是没有收到任何回复. 不过我们还是从社交媒体上收到了他们的响应:
(图：嗨 Dane！感谢你提供有关Cloudflare/APNIC的新DNS服务器信息。我们已经明确意识到PACE 5268AC设备屏蔽了1.1.1.1的地址，并且我们正在和他们协同尽可能快的推出新的固件更新来修复这个问题。此时，我们得到了好消息，Cloudflare推出了使用1.0.0.1的备用方案。请关注有关Pace设备的任何固件更新，如果有疑问，请随时联系AT&T的社交账号！祝好！^WillK)
另外的调查证实了事情的结果:
在D-Link DMG-6661的设备出现了同样的发现, 这是巴西的一位用户报告给Vivo FTTH的.
另一位阿根廷的用户在连接到Telefónica时，发现这个问题在Mitrastar GPT-2541GNAC设备上.
看起来这个 CPE 已经在国际上的很多 Telefónica 网络中部署.
我们注意到类似行为出现在大量的连接到Orange France(译者注：法国电信运营商)的探测器上 , 我们联系了他们，然后收到了迅速的响应，他们的CPE团队正在调查此问题。在提供了更多的细节后，他们回复了我们的声明.
我们已经在ORANGE France内部升级了你的告警.
我们的CPE团队已经分析了问题，现在这个问题很好理解. 这个问题仅影响了一部分我们的CPE. 修复功能正在进行，我们的CPE团队会随之部署.
如果我们的客户在此期间通知投诉，我们已准备好通知，告知他们我们目前正在解决此问题.
有问题的CPE是Livebox, 虽然不清楚哪些版本受到影响，但是应该由Orange在所有受影响的设备上解决。 波兰的用户报告了与法国用户相同的问题，可能是由于Orange在多个网络中部署了相同的模型。
我收到了目前我最爱的回复，来自友好的Telenor员工:
我已经纠正了我们网络中的所有路由器，这些路由器现在已经过时了。感谢Cloudflare帮助完成它！
设备的过时是不可避免的，但是发自内心的想要迫切修复问题，这点难能可贵(Obsolescence is inevitable, but the desire to speedily fix such occurrences is great to see).
这些并不是所有有问题的设备，而是一些部署广泛的设备。我们当前知道的受影响设备列表如下：
- Pace (Arris) 5268
- D-Link DMG-6661
- Technicolor C2100 Series
- Mitrastar GPT-2541GNAC
- Askey RTF3507VW-N1
- Calix GigaCenter
- Nomadix (model(s) unknown)
- Xerox Phaser multi-function printer
- See below :)
如果您的设备受到影响，请在评论中告知我们。证明受到影响的一个很好的例子是延迟超级低，并只有1跳到1.1.1.1:
1 | Traceroute to 1.1.1.1 (1.1.1.1), 48 byte packets |
还有谁在错误使用1.1.1.1?
使用RIPE Atlas探测器，在住宅和商业使用的网络连接测试中有很强的优势，但是他们是通过网线连接的, 所以忽略了另一个使用场景，WiFi接入点. 在少量研究后，我们很快发现 Cisco在错误使用 1.1.1.1, 快速搜索 “cisco 1.1.1.1” 发现了大量的文章，其中Cisco正把1.1.1.1作为他们的无线局域网的控制器(Wireless LAN Controllers,WLC). 目前不清楚Cisco官方是否是把 1.0.0.0/8 作为 bogon(未分配) 空间, 但是在他们的社区网站上，可以找到许多包含/8列表的示例. 似乎大多数被用于认证到无线接入点的强制认证网站, 这些接入点通常是在宾馆、咖啡厅和其他公共WiFi热点地区.
一些统计数据
以下是一些有趣的数据，来自我们开始联系运营商之前，及我们修复众多问题之后. 在欧洲和北美，修复一些重要网络后，1.1.1.1的可用性增加了近20％，令人惊讶!
在3月23日，我们开始测试1.1.1.1的可用性，在欧洲和北美只有91％左右.
3月23日，1.1.1.1 在欧洲和北美的可用性
到4月3日，我们的清理工作将可用性提高了97％.
4月3日，1.1.1.1 在欧洲和北美的可用性
对于世界的其他地区，不包括欧洲和北美，3月23日时，1.1.1.1的可用率仅为73％.
3月23日，1.1.1.1 在世界其他地区(不包括欧洲和北美)的可用性
到4月3日，我们取得了很大进展，并设法清理了足够可用的路由，使可用性提高至85％。
4月3日，1.1.1.1 在世界其他地区(不包括欧洲和北美)的可用性
我们将继续与ISP和CPE制造商合作，以清理全球的错误路由。我们的目标是为1.1.1.1被正确路由并为100％的互联网用户提供服务。.
以上图片来自Catchpoint分析
恶意流量
最近一次公开分析是在2010年由 RIPE 和 APNIC 完成的. 当时, 1.1.1.0/24 的流量为 100 到 200Mb/s 之间, 其中大部分是音频流量. 到了3月, 当 Cloudflare 公布 1.0.0.0/24 和 1.1.1.0/24 时, 我们的后台接口上出现了大约 10Gbps 的未经允许的流量.
最有针对性的IP是 1.1.1.1、 1.1.1.8、 1.1.1.10、 1.0.0.19. 当搜索这些IP后, 我们发现这通常是错误配置或硬编码的IP.
目标端口通常是80/443, 但也有使用UDP和TCP的其他HTTP端口变种(比如8000, 8080等等), 似乎尝试建立代理连接. 也有一些流量是DHCP/BOOTP, iperf 和syslog.
一些IP也是DDoS攻击的目标（甚至在我们公布新服务之前）. 通过来源端口分析，我们发现是NTP和memcached，通常几分钟内达到5Gbps。攻击持续时间短，可能是僵尸网络中的硬编码IP，然后才开始向特定目标发送流量。
我们还注意到，每天其中4个IP接收相同数量的流量（50Mbps左右）
所有的这些恶意流量都与DNS，简单，未经请求的后台流量无关。
总结
从一开始就很明显，我们的工作已经完成，尤其是CPE供应商，需要进行固件更新。运营商愿意与我们合作，以清理遗留的错误配置，这令人印象深刻。很明显，1.1.1.1需要大量清洁才能在全球范围内使用。我们在4月1日发布日期的六个月之前就下决心，将网络和支持资源致力给该项任务。现在1.1.1.1已经发布，我们非常感谢协助我们完成这项工作的所有网络运营商和硬件公司。没有你们，我们没法完成。
在从尽可能多的遍布全球的网络中，RIPE Atlas 项目的测试可达性可能非常有用. 如果你愿意帮助该项目, 请考虑 搭建一个探测器. 一些网络甚至还没有被一个探测器覆盖, 您可以看到您的ISP是否在此处有探测器,按国家/地区排序.
特别感谢以下快速响应并帮助解决问题的运营商.
- Airtel
- Beirut-IX
- BHTelecom
- Comcast
- ITC
- Fastweb
- Kazakhtelecom
- Level(3)
- LG Telecom
- Liquid Telecom
- MTN
- Omantel
- Rostelecom
- SKBB
- SFR
- STC
- Tata
- Telecom Italia
- Telenor
- Telus
- Turk Telekom
- Turkcell
- Voo
- XS4ALL
- Ziggo
我们还有要做的是, 联系存在问题的运营商, 同时，你应该能使用我们的备用IP地址1.0.0.1, 它的问题会比较少. 别忘了, 我们的两个 IPv6 地址: 2606:4700:4700::1001 和 2606:4700:4700::1111.
你是否和1.1.1.1还有连接问题? 你可以在我们的社区论坛找到更多的信息. 我们还建议您向您的ISP报告此类问题，他们可能已经意识到问题，或者他们可能需要您向他们报告以开始调查。无论是哪种情况，让他们意识到问题总归是没错的，运营商并不总是愿意接受来自外部第三方的报告。