1.1.1.1使用DNS访问http://archive.is/时，它不起作用。为什么？% dig +nocmd +nocomments @one.one.one.one archive.is
;archive.is. IN A
archive.is. 49050 IN A 127.0.0.3
;; Query time: 139 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Oct 3 17:12:50 2019
;; MSG SIZE rcvd: 44
%
#1 楼
官方声明archive.today在此问题上有以下说法：
https://twitter.com/archiveis/status/1017902875949793285
2018-07-13T1545：是的，与其他公共DNS服务不同，1.1.1.1不支持EDNS客户端子网
https://twitter.com/archiveis/status / 1018691421182791680
2018-07-15T1958：“必须要做的”在这里不是那么直接。 EDNS的缺乏和DNS和相关HTTP请求来源的大量不匹配（不仅在AS /国家/地区，甚至在大陆级别）也造成了许多麻烦，因此我认为来自Cloudflare的缺少EDNS的请求是无效的。
技术验证
从技术角度来看，可以通过运行以下命令轻松地验证索赔；可以注意到，除1.1.1.1之外，绝大多数公共解析器确实提供了
"edns0-client-subnet XX.XX.XX.0/24"答案，这对于使各种CDN功能发挥最佳作用是必不可少的。% dig +nocmd @dns.google. -t txt o-o.myaddr.l.google.com +nocomments +noall +answer +stats
o-o.myaddr.l.google.com. 59 IN TXT "172.217.34.2"
o-o.myaddr.l.google.com. 59 IN TXT "edns0-client-subnet XX.XX.XX.0/24"
;; Query time: 28 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Thu Oct 3 17:41:29 2019
;; MSG SIZE rcvd: 113
% dig +nocmd @resolver1.opendns.com. -t txt o-o.myaddr.l.google.com +nocomments +noall +answer +stats
o-o.myaddr.l.google.com. 60 IN TXT "2620:0:cc7::68"
o-o.myaddr.l.google.com. 60 IN TXT "edns0-client-subnet XX.XX.XX.0/24"
;; Query time: 20 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Thu Oct 3 17:41:32 2019
;; MSG SIZE rcvd: 115
% dig +nocmd @one.one.one.one. -t txt o-o.myaddr.l.google.com +nocomments +noall +answer +stats
o-o.myaddr.l.google.com. 60 IN TXT "162.158.82.18"
;; Query time: 23 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Thu Oct 3 17:41:42 2019
;; MSG SIZE rcvd: 67
% host 162.158.82.18
Host 18.82.158.162.in-addr.arpa not found: 2(SERVFAIL)
%
即使是不提供ECS的较不受欢迎的公共解析器，也仍然有资格获得存档。今天的例外是，解析器的地理位置很难通过编程方式确定：
% dig +nocmd @a.resolvers.level3.net -t txt o-o.myaddr.l.google.com +nocomments +noall +answer +stats
o-o.myaddr.l.google.com. 60 IN TXT "8.0.18.0"
;; Query time: 14 msec
;; SERVER: 4.2.2.1#53(4.2.2.1)
;; WHEN: Thu Oct 3 19:24:44 2019
;; MSG SIZE rcvd: 62
% host 8.0.18.0
0.18.0.8.in-addr.arpa domain name pointer cns1.Frankfurt1.Level3.net.
%
% dig +nocmd @ordns.he.net -t txt o-o.myaddr.l.google.com +nocomments +noall +answer +stats
o-o.myaddr.l.google.com. 60 IN TXT "216.66.80.30"
;; Query time: 16 msec
;; SERVER: 74.82.42.42#53(74.82.42.42)
;; WHEN: Thu Oct 3 19:26:56 2019
;; MSG SIZE rcvd: 66
% host 216.66.80.30
30.80.66.216.in-addr.arpa domain name pointer tserv1.fra1.he.net.
%
利益冲突
如果您是一个精明的互联网运营商，很快就可以看到利益冲突。 br />
Cloudflare的主营业务是作为内容交付网络以及相关服务，例如DDoS保护和僵尸网络防护。
为了最有效，他们要求客户（网站所有者）完全放弃对网站技术设置的控制。例如，这包括将您的域名
example.org委派给一组唯一的cloudflare.com.名称服务器的强制性要求— Cloudflare根本不允许其客户对任何服务的任何IP地址进行任何假设—无需IP地址硬编码。这不仅适用于HTTP / HTTPS服务器，而且还适用于权威DNS。基本上，与Linode和HE.net不同，它们在Cloudflare甚至都不允许您为其NS服务器添加白标签。免费（即，使用Cloudflare的IP地址和您自己的域名，如
ns1.example.org.的所有者，例如example.org）；这样做是为了让Cloudflare对所有可用的DoS补救技术具有最大程度的完全控制，以便能够在任何给定时间更改任何客户端看到的任何服务的任何IP地址，并促进对以下内容的请求跟踪数据收集，机器学习和流量异常分析。因此，凭借其新的1.1.1.1服务，对最终用户免费，补贴其庞大的CDN业务，Cloudflare决定拒绝竞争对手和非客户无法获得与Cloudflare本身一直有权访问的决策相同级别的信息-Archive.Today在此处运行自己的CDN网络-看起来并不完全像一个公平竞争的领域。
这有效地迫使像archive.today这样的运营商屈服于DoS攻击，因为他们没有可以使用的所有工具来保护自己免受此类攻击（通过为行为不端的客户端或子网赋予一个明显的名称res解决方案，以及进行异常检测），或成为Cloudflare CDN客户-Cloudflare多么方便！
Cloudflare宣告他们将EDNS客户端子网省略为一项隐私权举措的决定（这是一个相当虚伪的主张，因为ECS仅特定于
/24（带有IPv6的/56），并且在DNS解析完成后，您仍然必须发出您仍然可以通过自己的IP地址发送HTTP / HTTPS请求），但我认为很容易理解，从1.1.1.1版本开始，唯一已知的获利方法就是跟踪，机器学习和Cloudflare CDN产品的销售。由于未能提供EDNS客户端子网，使得Archive.Today这样的人如今很难在自己的CDN中完成Cloudflare本身在其广受好评的商业产品中所享受的相同操作。
archive.s是否也有CoI？也许。诸如Cloudflare之类的阻碍机器人的CDN对网站所有者产生了净正效应，其代价是对某些不常见的互联网用户产生了显着的净负效应，而现在可能需要一些不幸的用户每天全天解决验证码长。显然，很容易看出Cloudflare的遗忘验证码也可能对网站存档产生重大负面影响。
没有什么是完全黑白的，所以，我将让读者自己组建自己结论。
评论
这是否仅限于Cloudflare和Google之类的全球公共DNS解析器，或者该站点是否基本上需要所有内容的EDNS客户端子网？ （BIND 9最近似乎已完全删除了此功能。）
–user1686
19-10-6在14:16
#2 楼
这是CloudFlare首席执行官兼联合创始人于2019年5月在Hacker News上就此问题发表的声明：我们不会通过1.1阻止archive.is或任何其他域。 1.1。我们认为，这样做会违反DNS的完整性以及我们在启动服务时向用户做出的隐私和安全性承诺。
Archive.is的权威DNS服务器在查询它们时会将错误结果返回到1.1.1.1。 。我提议我们只是将其修复，但我们的团队非常正确地表示，这也将违反DNS的完整性以及我们在启动服务时向用户做出的隐私和安全性承诺。
archive.is所有者解释说，他向我们返回了不好的结果，因为我们没有传递EDNS子网信息。此信息会泄漏有关请求者IP的信息，从而牺牲用户的隐私。由于从解析器到权威DNS的请求通常未加密，因此在我们要加密更多DNS流量时，这尤其成问题。我们知道现实世界中的示例，其中国家行为者监视EDNS子网信息以跟踪个人，这是1.1.1.1隐私和安全策略动机的一部分。
EDNS IP子集可以是用于更好地定位使用基于DNS的负载平衡的服务的响应。但是，1.1.1.1是通过Cloudflare遍布整个180个城市的整个网络提供的。我们发布要查询的IP的地理位置信息。这样一来，任何密度比我们需要正确返回DNS定位结果的网络都要少的网络。对于像archive.is这样的相对较小的运营商，依靠Cloudflare PoP的位置来代替EDNS IP子网，不会造成地理负载平衡保真度的损失。
我们正在与网络/ ISP密度比Cloudflare更高的少数网络（例如Netflix，Facebook，Google / YouTube）合作，提出一种EDNS IP子网替代方案，从而为他们提供所需的地理位置定位信息，而不会冒着风险用户隐私和安全性。这些对话一直富有成效，而且正在进行中。如果archive.is在这方面有建议，我们将很乐意考虑。
编辑：2019年10月的新Hacker新闻主题
评论
一些读者声称，其他CDN不需要ECS-Cloudflare首席执行官的最后一段证明了所有这些人都是错误的。基本上，Cloudflare试图通过人为地限制其他CDN提供商的性能潜力以匹配其自身水平来缩小性能差距。关于国家使用ECS的说法也没有多大意义。我的回答也已经解决了geoloc问题-Cloudflare似乎既未在rDNS中也不在Whois中或在rwhois中发布任何GeoIP。
–cnst
19-10-4在23:51
#3 楼
这是一个非常有趣的问题，我已经考虑了很多。一句话的答案是“因为archive.is阻止了Cloudflare数据中心的DNS请求”。当然，这引出了一个核心问题：“为什么？”。
archive.is的这种行为令我特别感兴趣，因为archive.is似乎强调反审查和具有韧性。 ，但阻止1.1.1.1用户似乎与此相反。 cnst的答案肯定很有趣而且很合理，但是我想出了我自己的宠物假说，该假说有点类似。网站，并且必须审查非法内容。您可能会想出3条规则：
如果内容在国家
X中是非法的，则该内容不得提供给国家X中的用户。 X，该内容绝对不能触摸国家X中的服务器。因此，不得将其存储在这些服务器上，也不得通过这些服务器进行代理。 > 简单示例
让我们举一个简单的示例：您拥有一个内容
X，在世界上每个国家/地区（国家/地区X除外）都是非法的。我们如何在规定的规则内运营我们的网站？这非常简单，将我们所有的服务器放在A中，如果对X的请求来自国家X，则可以为其提供服务。如果对A的请求来自国家X，请输入404。复杂的示例
现在让我们举一个更复杂的例子：您拥有一个内容
A，该内容在世界上每个国家/地区（国家Y除外）都是非法的。您有一个内容A在世界上每个国家/地区都非法，但国家/地区除外。现在不再有一个简单的解决方案。但是，这是一个复杂的解决方案：X中具有B但没有Y的可运行服务器。如果X中的服务器收到来自A的B请求，则将其送达。如果X中的服务器从外部A接收到对X的请求，请给出404。同样，对X和A也是如此。如果有任何服务器收到对内容的请求，则不会提供404。为您的站点运行自定义的权威DNS服务器。如果在
X中收到以EDNS作为IP的DNS请求，请在Y中以服务器的IP地址进行响应。如果在B中收到以EDNS作为IP的DNS请求，请在X中以服务器的IP地址进行响应。如果它在某些非X和非Y国家/地区收到以EDNS作为IP的DNS请求，请任意选择一个服务器IP地址进行响应。Cloudflare输入
如果您尝试实际实施该解决方案，则会遇到问题：某些DNS解析器（例如1.1.1.1）没有为您提供EDNS，因此这是不可能的。因此，archive.is可能会这样做，然后意识到某些DNS解析器无法运行，因此他们决定阻止使用这些解析器的用户，而不是拥有一个半破碎的站点。关于为什么为什么只阻止一些缺少EDNS的解析器（例如1.1.1.1），而不阻止其他没有EDNS的转存，仍然存在一个悬而未决的问题。
证据
I'我们发现一些证据支持这种解释archive.is的行为。
Archive.is在Linode和DigitalOcean上运行一些特殊的DNS服务器。当Linode抱怨这些DNS服务器以某种方式用于帮助分发有争议的内容时，archive.com通过说这些服务器只是DNS服务器来为自己辩护，内容永远不会触及这些服务器。此防御使用与上面的规则2相同的推理，即重要的是内容是否触及特定服务器。在用户IP上。 Archive.is回答是，他们会根据用户所在的国家/地区进行审查。这与我在复杂解决方案中提出的行为非常相似。作为一个有趣的旁注，archive.com通过确保用户看不到被禁止的内容来将这种检查制度视为合法性，而Linode则通过混淆行为，隐藏证据并使其难以为继而将这种行为完全等同于合法性。 Linode进行调查。
Archive.is表示，他们正在使用现代化的部署工具和竞争激烈的云市场来防止错误的下架，这可能表明在许多国家/地区的服务器和某种编排系统的安装都很复杂管理它们。
结论
我们不知道某些档案。这是它们行为的原因，因为他们还没有完全解释自己。如果他们的推理是基于法律的，也许他们担心解释其法律设置会暴露其设置中的法律漏洞。
archive.is留下的解释空白为一些有趣的技术和实践提供了机会。哲学上的推测。
评论
DNS问题实际上与Web应用程序没有任何关系（除非它使它们难以访问）。在我看来，这只是一个种子职位，允许在答案中发布熨平板。SE政策无可厚非，并鼓励自我回答。
@ BlueRaja-DannyPflughoeft archive.today今天是一个网络应用程序，可以说是1.1.1.1。我看不到该Web应用程序的质量检查是如何偏离主题的，或者与该SE上没有主题的关于Slack，Gmail，Reddit或GitHub的怪癖的其他问题有什么不同。
不，它之所以获得这些票，是因为它的争议程度使其在热网络问题列表中。 （还有Hackernews，Reddit等）...
@cnst之所以得到了所有这些，是因为有一个叫做“热网络问题”列表的东西。没有什么可以阻止脱题的问题变得炙手可热，直到将其关闭或将其从列表中删除。