最近，我们发布了由全球网络支持的快速、以隐私为中心的DNS解析程序1.1.1.1。如你所见，1.1.1.1很容易记住，这既是福也是祸。在宣布解析器服务之前，我们开始测试1.1.1.1的可访问性，主要使用成熟的Atlas探针。成熟的Atlas项目是由全世界公众主持的小型监测设备的广泛收集。目前，在3000多个网络中有超过10000个活动探针，为测试提供了很大的优势。我们发现大量探测器无法查询1.1.1.1，但在几乎所有情况下都能成功地查询1.0.0.1。1.0.0.1是我们为解析程序分配的辅助地址，允许无法访问1.1.1.1的客户端进行DNS查询。本博客关注IPv4。我们提供四个IP（每个IP地址族有两个），以便提供通向DNS解析程序的路径，独立于IPv4或IPv6的可达性。1.0.0.0/8在2010年分配给APNIC，在此之前它是未分配的空间。%IANA WHOIS服务器%有关IANA的更多信息，请访问%此查询返回1个对象inetnum:1.0.0.0-1.255.255.255组织：APNIC状态：已分配whois公司：whois.apnic.net网站变更：2010-01来源：IANAhttps://www.iana.org/whois？q=1.0.0.0%2F8但是，未分配与保留供私人使用不同！我们发现了什么简单地说，1.1.1.1被破坏了！好消息是，对于大多数用户来说，1.1.1.1现在可以访问了。我们努力确保问题得到解决，并继续联系运营商快速解决问题。我们有信心我们可以清理一切，但这是一个明确的提醒，你不应该劫持IP地址没有分配给你。我们发现10000多个探测器中有1000多个无法成功地对1.1.1.1进行DNS查询。其中一部分原因是单个大型网络存在可达性问题，例如德国的一家大型运营商连接了近350个探头，所有探头都出现故障。测试方法非常简单：对1.1.1.1运行DNS查找度量查找查找失败的探测用受影响的探测器运行追踪路线分析结果结果好坏参半，但主要有三个原因：内置1.1.1.1 ISP路由器，使用1.1.1.1作为内部IP地址，防止查询到达真正的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，要么是2，要么两者兼而有之！一些ISP甚至在内部设置了路由环路，他们在自己的网络中发布了1.1.1.1的广告，但实际上并没有路径，所以数据包会循环。是时候修理了一旦我们缩小了每一组探测器的范围，我们就开始联系ISP，要求他们澄清发生了什么，几个网络反应非常迅速，报告说他们已经删除了一条到1.1.1.1的内部路由，在大多数情况下，这是问题的开始和结束。有很多网络都花了时间做出响应，但最终还是做了同样的事情，删除了遗留测试原因留下的内部路由。所有这些修复都是很好的，但大多数都是非常无趣的，更有趣的是从问题1，即CPEs（客户场所设备）即家庭路由器、网关和无线接入点中找到案例。在Sonic员工的帮助下，我们很快就能确定Pace5268是一款主要部署在美国的通用xDSL调制解调器（包括在at&T上广泛使用）使用1.1.1.0/29进行内部通信。我们要求AT&T的国家奥委会对此发表评论，但没有收到他们的任何消息。不过，我们确实通过社交媒体收到了他们的回复：独立调查证实了调查结果：在D-Link DMG-6661上也有同样的发现，这是一位连接Vivo FTTH的巴西用户向我们报告的。另一位阿根廷用户通过Telefónica在Mitrastar GPT-2541GNAC上发现了这个问题。看来这个CPE已经部署在Telefónica的许多国际网络中。我们注意到在与Orange France相连的大部分探测器上都有类似的行为，我们联系了他们，得到了一个迅速的答复，即CPE团队正在调查这个问题。在提供了更多细节后，他们又给我们发了一份声明。我们已经升级了你在奥兰治法国的警戒。我们的CPE团队已经分析了这个问题，现在这个问题已经得到了很好的理解。这个问题只影响到我们的cpe的一个子集。修复的承诺目前正在进行中，随后将在我们的CPE上部署。如果我们的客户在此期间收到投诉，我们准备了一份通知，告知他们我们目前正在解决问题。有问题的CPE是Livebox，尽管还不清楚哪些版本受到影响，但它应该通过Orange在所有受影响的设备上解决。波兰的用户报告了与法国用户相同的问题，可能是由于Orange在多个网络上部署了相同的型号。到目前为止，我最喜欢的回答来自Telenor的友好人士：我已经纠正了我们网络中的所有路由器，它们有一个可怕的旧解决方案，现在已经过时。感谢Cloudflare的帮助！过时是不可避免的，但希望迅速解决这些问题的愿望是很明显的。这些并不是所有存在问题的设备，而是一些更广泛部署的设备。受影响设备的当前列表是：速度（Arris）5268D-Link DMG-6661特彩C2100系列米特拉斯塔尔GPT-2541GNACAskey RTF3507VW-N1Calix GigaCenter公司Nomadix（型号未知）施乐移相器多功能打印机见下文：）如果您的设备受到影响，请在评论中告诉我们。这方面的一个很好的例子是只有1跳到1.1.1.1的超低延迟：Traceroute到1.1.1.1（1.1.1.1），48字节数据包1 1.1.1.1 1dot1dot1dot1.cloudflare-dns.com网站AS13335 8.301ms 1.879ms 1.836ms还有谁比其他人更滥用1.1.1.1？使用成熟的Atlas探测器可以很好地观察住宅和商业互联网连接，但是它们是通过电缆连接的，所以这就排除了另一个用例，WiFi接入点。在很少的研究之后，我们很快就发现了使用1.1.1.1的Cisco mis，快速搜索"Cisco 1.1.1.1"可以找到许多文章，其中Cisco正在为他们的无线LAN控制器（WLC）选择1.1.1.1。目前尚不清楚Cisco是否正式将1.0.0.0/8视为bogon空间，但在他们的社区网站上可以找到很多例子，给出了包含/8的bogon列表示例。在对无线接入点进行身份验证时，它似乎主要用于捕获门户，通常在酒店、咖啡馆和其他公共WiFi热点位置发现。一些统计数据以下是一些有趣的统计数据，这些数据是在我们开始联系运营商之前以及在我们解决了许多问题之后。在欧洲和北美，修复一些关键网络使可用性提高了近20%，这真是令人震惊！我们从3月23日开始测试1.1.1.1的可用性，在欧洲和北美只有91%左右。1.1.1.1欧洲和北美的可用性，3月23日到4月3日，我们清理空间的工作将可用性提高到97%。1.1.1.1欧洲和北美的可用性，4月3日除欧洲和北美以外的其他国家，3月23日1.1.1.1的可用性仅为73%。1.1.1.1全球可用性（欧洲和北美除外），3月23日到4月3日，我们已经取得了巨大的进展，并设法清理了足够多的坏路由，可用性高达85%。1.1.1.1全球可用性（欧洲和北美除外），4月3日我们将继续与ISP和CPE制造商合作，清理全球范围内的不良路由。我们的目标是让1.1.1.1能够被正确的路由，并为100%的互联网用户提供服务。上图来自Catchpoint analytics交通不畅上一次公开分析是在2010年由成熟和APNIC完成的。当时，1.1.1.0/24的流量是100到200Mb/s，其中大部分是音频流量。今年3月，当Cloudflare发布1.0.0.0/24和1.1.1.0/24时，我们的接口上出现了~10Gbps的未经请求的后台流量。最具针对性的IPs为1.1.1.1、1.1.1.8、1.1.1.10、1.0.0.19。当搜索这些IP时，我们注意到通常是配置错误或硬编码IP。目标端口通常是80/443，但也有其他HTTP端口（8000、8080等）的变体，使用UDP和TCP，似乎在尝试建立代理连接。一些流量也是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已经上线，我们要感谢所有的网络和硬件公司在这方面的帮助。我们还没做完，其他人也没做完。成熟的Atlas项目在测试中非常有用