1.1.1.1がarchive.isを解決しないのはなぜですか？
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
%
公式声明
archive.todayはこの問題についてこれを述べていました：
https://Twitter.com/archiveis/status/1017902875949793285
2018-07-13T1545：はい、他のパブリックDNSサービスとは異なり、1.1.1.1はEDNSクライアントサブネットをサポートしていません
https://Twitter.com/archiveis/status/101869142118279168
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を提供しない、あまり一般的ではないパブリックリゾルバーでさえ、resolverの地理位置情報がプログラム的な方法で決定するのは簡単な場合、archive.todayの例外の下で依然として適格です。
_% 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.
%
_利益相反
あなたがインターネットに精通している人なら、同様に、遊びで利益相反を見るのにそれほど時間はかかりません。
Cloudflareの主な事業は、コンテンツ配信ネットワークと、DDoS保護やボット妨害などの関連サービスです。
最も効果的にするために、彼らは彼らの顧客（ウェブサイトの所有者）が彼らのウェブサイトの技術的なセットアップの完全な制御を放棄することを要求します。たとえば、これには、ドメイン名_
example.org_を_cloudflare.com._ネームサーバーの一意のセットに委任するという必須要件が含まれます— Cloudflareは、顧客が次のサービスのIPアドレスについて想定することを許可していませんall — IPアドレスのハードコーディングはありません。これは、HTTP/HTTPSサーバーだけでなく、信頼できるDNSにも適用されます。基本的に、LinodeやHE.netとは異なり、Cloudflareのサーバーでは、NSサーバーに無料でホワイトラベルを付けることもできません（つまり、CloudflareのIPアドレスを、_
ns1.example.org._あなたが_example.org_）;の所有者である場合、これはCloudflareが利用可能なすべてのDoS修復手法を最大限に完全に制御できるようにするために行われ、任意の時点で任意のクライアントから見た任意のサービスの任意のIPアドレスを変更します、およびデータ収集、マシンのリクエスト追跡を容易にします学習とトラフィックの異常分析。このように、エンドユーザーに無料で提供され、大規模なCDNビジネスからの助成を受けた新しい1.1.1.1サービスにより、Cloudflareは、競合他社と非顧客が同じレベルの情報にアクセスできないようにするという意思決定を行うことを拒否しました。 Cloudflare自体は常にアクセスしてきました— archive.todayはここで独自のCDNネットワークを実行します—レベルプレイフィールドのようには見えません。
これは事実上、archive.todayのような事業者に、そのような攻撃から身を守るために利用可能なすべてのツールを用意しないことにより、DoS攻撃に屈することを強制します（誤動作するクライアントまたはサブネットに明確な名前解決を提供し、異常検出を行うことによって）、または、Cloudflare CDNの顧客になるために— Cloudflareにとってどれほど便利か！
CloudflareはEDNSクライアントサブネットをプライバシーイニシアチブとして除外する決定を推奨しています（ECSは_
/24_（_/56_ with IPv6）にのみ固有であり、 後にDNS解決は完了しましたが、とにかく自分のIPアドレスからHTTP/HTTPSリクエストを発行する必要があります ）ですが、1.1.1.1からの唯一の既知の収益化が追跡している行の間を読むのは簡単だと思います、CloudflareのCDNオファリングの機械学習とアップセル。EDNSクライアントサブネットの提供に失敗すると、archive.todayのような誰かが、称賛されている商用サービスでCloudflare自体が楽しんでいるのと同じことを、独自のCDNで実行することが著しく困難になります。
Archive.isにもCoIがありますか？たぶん。 Cloudflareのようなボット妨害CDNは、一部の 不運なもの が必要になる可能性がある特定のあまり一般的ではないインターネットユーザーに大きなマイナスの影響をもたらす代わりに、ウェブサイトの所有者にプラスの効果をもたらしました- 終日、毎日キャプチャを解決する 。明らかに、Cloudflareの忘却のキャプチャがWebサイトのアーカイブに重大な悪影響を与える可能性があることも簡単にわかります。
正確に白黒のものは何もないので、読者にあなた自身の結論を出させます。
これは、この問題に関する2019年5月の Hacker News でのCloudFlareのCEO兼共同創設者の声明です。
1.1.1.1では、archive.isまたはその他のドメインはブロックされません。これを行うと、DNSの整合性と、サービスの開始時にユーザーに対して行ったプライバシーとセキュリティの約束に違反することになります。 Archive.isの信頼できるDNSサーバーは、クエリを実行すると1.1.1.1に悪い結果を返します。私はそれを自分で修正することを提案しましたが、私たちのチームも、当然のことながら、サービスの開始時にDNSの整合性とユーザーに対して行ったプライバシーとセキュリティの約束に違反することになると述べています。
Archive.isの所有者は、EDNSサブネット情報を渡さないため、悪い結果が返されると説明しています。この情報は、リクエスターのIPに関する情報を漏らし、ユーザーのプライバシーを犠牲にします。 ResolverからAuthoritative DNSへのリクエストは通常暗号化されていないため、これはより多くのDNSトラフィックを暗号化しようとするときに特に問題になります。私たちは、1.1.1.1のプライバシーおよびセキュリティポリシーの動機の一部であった、国民国家のアクターが個人を追跡するためにEDNSサブネット情報を監視した実際の例を認識しています。
EDNS IPサブセットを使用すると、DNSベースのロードバランシングを使用するサービスの応答をより適切に地理的に特定できます。ただし、1.1.1.1はCloudflareの現在の180都市にまたがるネットワーク全体に配信されます。問い合わせ元のIPの位置情報を公開します。これにより、DNSターゲットの結果を適切に返すために必要な密度よりも低いネットワークが可能になります。 archive.isのような比較的小規模なオペレーターの場合、EDNS IPサブネットの代わりにCloudflare PoPの場所に依存するジオロードバランシングの忠実度は失われません。
Cloudflareよりもネットワーク/ ISP密度が高い少数のネットワーク（Netflix、Facebook、Google/YouTubeなど）と協力して、地理位置情報ターゲティングに必要な情報を危険にさらさずに取得できるEDNS IPサブネットの代替案を考え出しますユーザーのプライバシーとセキュリティ。それらの会話は生産的であり、進行中です。 archive.isがこれらの方針に沿って提案を行っている場合は、それらを検討させていただきます。
これは非常に興味深い質問であり、多くのことを考えました。
1つの文の答えは、「 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からのものである場合は、それを処理します。 Aのリクエストが国Yからのものである場合は、404を指定してください。
複雑な例
次に、より複雑な例を見てみましょう。コンテンツAがあり、国Xを除く世界のすべての国で違法です。国Bを除く世界のすべての国で違法なコンテンツYがあります。現在、単純な解決策はありません。しかし、ここに複雑な解決策があります：
XはあるがAはないサーバーをBで運用します。 XのサーバーがAからXのリクエストを受け取った場合は、それを提供します。 XのサーバーがAの外部からXのリクエストを受け取った場合は、404を指定します。同様に、YとBの場合も同様です。サーバーがコンテンツのリクエストを受信した場合、サーバーは404を提供しません。
サイトのカスタムの権威DNSサーバーを運用します。 EDNSがXのIPとしてDNSリクエストを受信した場合は、XのサーバーのIPアドレスで応答します。 EDNSがYのIPとしてDNSリクエストを受信した場合は、YのサーバーのIPアドレスで応答します。 XとY以外の国でIPとしてEDNSを使用してDNSリクエストを受信した場合、応答するサーバーIPアドレスを任意に選択します。
Cloudflareが入る
実際にそのソリューションを実装しようとすると、問題が発生します。一部のDNSリゾルバー（1.1.1.1など）がEDNSを提供しないため、不可能です。したがって、archive.isはこれを行った可能性があり、一部のDNSリゾルバーでは失敗することに気づき、半壊サイトではなく、それらのリゾルバーを使用するユーザーをブロックすることにしました。 some EDNS-less resolvers（1.1.1.1など）と not other EDNS-less resovers のみをブロックする理由については未解決の問題があります。 =。
証拠
このarchive.isの動作の説明を支持する証拠がいくつか見つかりました。
Archive.isは LinodeおよびDigitalOcean でいくつかの特別なDNSサーバーを実行します。 Linode 不平 これらのDNSサーバーが問題のあるコンテンツの配布を助けるために何らかの方法で使用された場合、archive.isは、それらのサーバーが単なるDNSサーバーであり、コンテンツがこれらのサーバーに接触することはないと言って自己防衛します。この防御は、上記のルール2と同じ推論を使用します。つまり、重要なのは、コンテンツが特定のサーバーに接触するかどうかです。
さらに、同じ会話でLinodeは、archive.isがユーザーIPに基づいてブロックを実行していると不平を言いました。 Archive.isは、そうだと答えました。ユーザーがいる国に基づいて検閲を行います。これは、私が複雑なソリューションで提案したものと非常によく似た動作です。興味深い副注として、archive。はこのタイプの検閲をimprovingユーザーが禁止されたコンテンツを表示しないことを保証することによる合法性と見なしましたが、Linodeはhurtingとまったく同じ動作を示しました。合法性、動作を難読化し、証拠を隠蔽し、Linodeが調査することを困難にします。
Archive.isは、不正な削除を防ぐために 最新の展開ツール と非常に競争の激しいクラウド市場を使用していると述べています。これは、多くの国のサーバーとそれらを管理するある種のオーケストレーションシステムの複雑なセットアップを示している可能性があります。
結論
彼らが自分自身を完全に説明していないので、私たちは特定のarchive.isについて彼らの行動の理由を知りません。彼らの推論が法的根拠に基づいている場合、おそらく彼らは彼らの法的設定を説明することが彼らの設定に法的穴をあけることを恐れているでしょう。
Archive.isが残っているという説明のギャップは、興味深い技術的および哲学的推測の機会を提供します。