Cloudflareおよびその他のDNSサービスから1.1.1.1を構成するには、依然としてコマンドラインのスキルが必要です

デバイスとDNSサービス間のトラフィックを暗号化すると、権限のない人がトラフィックを監視したり、アドレスを変更したりできなくなります



ネットワークの中立性の消滅と、インターネットサービスプロバイダーがネットワークトラフィックを処理するためのルールの弱体化により、プライバシーに関する多くの懸念が生じています。 プロバイダー（および通過するトラフィックを監視する他の無許可の人）には、インターネット上の人々の行動を簡単に追跡できるツールが長い間ありました。これらはドメインネームサーバー（DNS）です。 このデータをまだ収益化していない（またはトラフィックを置き換えていない）としても、おそらくすぐに開始されます。



DNSは、サイトおよびその他のインターネットサービスのホスティングおよびドメイン名に関連付けられた実際のネットワークIPアドレスを提供するネットワーク電話帳です。 たとえば、arstechnica.comを50.31.169.131に変換します。 ISPはサービスパッケージでDNSを提供しますが、DNSトラフィックをログに記録することもできます。実際、インターネットでのアクションの履歴を記録します。



「オープン」DNSサービスを使用すると、機密性とセキュリティのためにプロバイダーのサービスをバイパスできます。一部の国では、コンテンツのフィルタリング、監視、検閲を回避できます。 4月1日（冗談ではありません）Cloudflareは、インターネット上のユーザープライバシーを高めるために設計された、新しい無料の高性能DNSサービスを開始しました。 また、暗号化を使用して、DNS索好きな目からDNSトラフィックを完全に隠すことを約束します。



IPアドレスにちなんで名付けられたサービス1.1.1.1は、5つの地域インターネットレジストラの1つであるAPNIC研究グループであるアジア太平洋ネットワーク情報センターとのパートナーシップの結果です。 Cloudflareは、「オープンな」通常のDNSリゾルバーとしても使用できます（非常に高速）が、2つのDNS暗号化プロトコルもサポートしています。



Cloudflareのユニークな「グッズ」を使用して開発されましたが、1.1.1.1は決して暗号化を備えた最初のDNSサービスではありません。 Quad9 、CiscoのOpenDNS、Googleの8.8.8.8サービス、およびDNSクエリを完全に暗号化するためのさまざまなスキームをサポートする多くの小規模サービスは正常に機能します。 ただし、暗号化は必ずしもトラフィックが見えないことを意味するわけではありません。暗号化されたDNSサービスの中には、さまざまな目的でリクエストをログに記録するものがあります。



Cloudflareは、DNSトラフィックをログに記録しないことを約束し、サードパーティの監査会社を雇いました。 APNICのジェフヒューストンは、APNICは研究目的でデータを使用するつもりであると述べました。範囲1.0.0.0/24および1.1.1.0/24は、最初はブラックトラフィックのアドレスとして設定されていました。 ただし、APNICは暗号化されたDNSトラフィックにアクセスできません。



ユーザーにとって、DNS暗号化の接続は、ネットワーク設定でアドレスを変更するほど簡単ではありません。 現在、OSは追加ソフトウェアなしでDNS暗号化を直接サポートしていません。 また、ソフトウェアとパフォーマンスの点ですべてのサービスが同じというわけではありません。



しかし、質問の重要性を考えると、最近、すべてのニュースがユーザーデータを製品に変えることについて話しているので、CloudflareのDNS暗号化がどのように機能するかを確認することにしました。 その結果、社内の研究所のラットが勝ちました-そして、DNSCrypt、DNS over TLS、DNS over HTTPSの3つのDNS暗号化プロトコルを使用して、いくつかのDNSプロバイダーのクライアントをテストおよび分解していることがわかりました。 それらはすべて機能しますが、警告します：手順は簡単になりますが、電話で親にDNS暗号化を説明できる可能性は低いです（Linuxコマンドラインユーザーの経験がない場合）。





DNSの仕組み

なぜこれを行うのですか？

DNSトラフィックの保護を強化する多くの理由があります。 Webトラフィックおよびその他の通信は、トランスポートレイヤーセキュリティ（TLS）などの暗号化プロトコルで保護できますが、ほとんどすべてのDNSトラフィックは暗号化されずに送信されます。 これは、サードパーティのDNSを介して作業している場合でも、プロバイダー（またはユーザーとインターネットの間の誰か）が訪問するサイトを登録できることを意味します。





デバイスとDNSリゾルバー間の典型的なデータ交換はどのようなものですか？



情報セキュリティ会社であるInfobloxのチーフDNSアーキテクトであるCricket Liuは、次のように述べています。「DNSには「ラストマイル」の問題があります。 -ほとんどのセキュリティメカニズムは、サーバー間の通信の問題に対処します。 しかし、さまざまなオペレーティングシステム上のリゾルバの代理に問題があります。 実際には、それらを保護することはできません。」 この問題は、当局がインターネットに対してより敵対的である国で特に顕著です。



ある程度、ログを保持しないDNSの使用が役立ちます。 ただし、これでも攻撃者がコンテンツでリクエストをフィルタリングしたり、パケットインターセプトやディープパケットインスペクションを使用してアドレスをインターセプトしたりすることを防ぐことはできません。 パッシブな盗聴に加えて、DNSトラフィックに対するより積極的な攻撃の脅威があります。プロバイダーによるDNSサーバーのなりすまし、またはトラフィックを監視またはブロックするための独自のサーバーへのリダイレクトを伴う特別なサービスです。 DSLReportsフォーラムのメッセージから判断して、 AT＆Tネットワークからアドレス1.1.1.1へのトラフィックのランダムなリダイレクトでは 、同様の（悪意があるようには見えませんが）発生しているようです。



スヌーピングを回避する最も明白な方法は、VPNを使用することです。 ただし、VPNはトラフィックのコンテンツを隠しますが、VPNに接続するにはDNSクエリが必要になる場合があります。 また、VPNセッション中に、DNSクエリは、WebブラウザーまたはVPNトンネル外の他のソフトウェアによってルーティングされることもあり、訪問したサイトを明らかにする「DNSリーク」を引き起こします。



これがDNS暗号化プロトコルの出番です：DNSCrypt（とりわけ、CiscoのOpenDNSでサポートされています ）、 TLS DNS （Cloudflare、Google、Quad9、OpenDNSでサポートされています ）およびHTTPS DNS （Cloudflare、Googleおよび「アダルト」ブロッキングサービスでサポートされています ） CleanBrowsingコンテンツ）。 暗号化により、トラフィックがスキャンされたり変更されたりせず、偽のDNSサーバーが要求を受信または処理しないことが保証されます。 これにより、MiTM攻撃およびスパイから保護されます。 これらのサービスの1つからのDNSプロキシ（デバイス上またはローカルネットワーク内の「サーバー」上）は、プロキシサーバーが常に最速のDNSサーバーであるため、VPNを介したDNSリークの防止に役立ちます。



ただし、このセキュリティオプションは、大衆ユーザーは利用できません。 これらのプロトコルはいずれも、OSにバンドルされているDNSリゾルバーによってネイティブにサポートされていません。 これらはすべて、ローカルDNS「サーバー」として機能するクライアントアプリケーションのインストール（およびおそらくコンパイル）を必要とし、ブラウザやその他のアプリケーションからの要求を、選択した安全なDNSプロバイダーに中継します。 そして、これらの技術のうち3つのうち2つが標準の役割のために提案されていますが、私たちがテストしたオプションはいずれも最終的な形で提示されていません。



したがって、DNS暗号化に没頭したい場合は、ホームネットワークのDNSサーバー用にRaspberry Piまたは他の別のデバイスを使用することをお勧めします。 おそらく、これらのクライアントの1つをセットアップするだけで、プロセスを再度繰り返したくないほど十分にハッキングすることがわかるでしょう。 ローカルネットワーク上でDHCP設定を要求する方が簡単です。また、すべてのコンピューターがDNSサーバーの1つの正常なインストールを指すようにします。 テスト中にこれを何度も繰り返し、Windowsでクライアントが1つずつ落下し、MacOSでクライアントが休止状態になることを観察しました。





DNSCryptコミュニティは、iOS向けのDNSCloak（左側）とWindows向けのSimple DNSCrypt（右側）をリリースすることにより、コマンドラインスキルのない人向けに手頃な価格のツールを提供しようとしました。

暗号化

完全を期すために、歴史的な観点から、最初のDNS暗号化技術であるDNSCryptからレビューを開始します。 2008年にBSD Unixで初めて導入されたDNSCryptツールは、当初、盗聴からではなくDNSスプーフィングから保護するために設計されました。 ただし、特にログフリーDNSサーバーと組み合わせた場合、機密性システムの一部として使用できます。 DNSCrypt開発者のFrank Denisによると、他のどの種類のDNS暗号化よりも多くのサーバーがDNSCryptをサポートしています 。



「DNSCryptは単なるプロトコルではありません」とフランクデニスは言います。 「現在、コミュニティと活発なプロジェクトは、週末に開発された私のオリジナルのプロトコルよりもはるかに優れた特徴を持っています。」 DNSCryptコミュニティは、Windows用のシンプルなDNSCryptや、 DNS Cloakと呼ばれるApple iOS用のクライアントなど、使いやすいクライアントを作成しました。 他の活動家は、ユーザーが企業のDNSシステムの使用を回避するのに役立つプロトコルに基づいて、プライベートDNSサーバーの独立したネットワークを作成しました。



「DNSCryptは特定の会社のサーバーへの接続ではありません」とデニスは言いました。 -私たちは誰もが自分のサーバーを上げることをお勧めします。 これを行うには、非常に安価で簡単です。 安全なリゾルバができたので、機密性に基づいてコンテンツをフィルタリングする問題を解決しようとしています。」



ネットワーク全体でDNSCryptをサポートするDNSサーバーを実行する場合、 DNSCrypt Proxy 2が最適なクライアントです。 DNSCrypt Proxyの古いバージョンは、ほとんどの主要なLinuxディストリビューションのパッケージとして引き続き利用できますが、GitHubの公式リポジトリから直接新しいバージョンのバイナリをダウンロードすることをお勧めします。 Windows、MacOS、BSD、Androidのバージョンがあります。



DNSCryptコミュニティのプライバシーエクスペリエンスは、DNSCryptプロキシに組み込まれています。 このプログラムは設定が簡単で、アクセス時間制限、ドメインテンプレート、IPアドレスのブラックリスト、クエリログ、およびかなり強力なローカルDNSサーバーの他の機能をサポートしています。 ただし、開始するには、最も基本的な構成で十分です。 TOML形式の設定ファイルの例があります（GitHubの共同設立者Tom Preston-Wernerが作成したTom's Obvious Minimal Language ）。 DNSCrypt Proxyを開始する前に名前を変更するだけで、構成ファイルが機能するようになります。



デフォルトでは、プロキシサーバーはQuad9オープンDNSリゾルバーを使用して、 GitHubからオープンDNSサービスの精選されたリストを検索および取得します 。 次に、最速の応答でサーバーに接続します。 必要に応じて、構成を変更し、特定のサービスを選択できます。 リスト内のサーバーに関する情報は、 「サーバースタンプ」としてエンコードされます 。 プロバイダーのIPアドレス、公開キー、DNSSECサーバーがサポートするかどうか、プロバイダーがログを保存してドメ​​インをブロックするかどうかに関する情報が含まれます。 （インストール中にリモートファイルに依存したくない場合は、JavaScriptで「スタンプ計算機」を実行し、 この形式でサーバーの独自のローカル静的リストを生成できます ）。



DNSCryptテストでは、CiscoのOpenDNSをリモートDNSサービスとして使用しました。 最初のクエリでは、DNSCryptのパフォーマンスは通常のDNSのパフォーマンスよりわずかに劣っていましたが、DNSCryptプロキシは結果をキャッシュします。 最も遅い要求は200ミリ秒の領域で処理されましたが、平均的な要求は約30ミリ秒かかりました。 （結果は、プロバイダー、ドメイン検索時の再帰、およびその他の要因によって異なる場合があります）。 一般的に、Webの閲覧速度の低下に気付きませんでした。



DNSCryptの主な利点は、「通常の」DNSのように見えることです。 良くも悪くも、ポート443でUDPトラフィックを送信します。同じポートが安全なWeb接続に使用されます。 これにより、比較的迅速なアドレス解決が可能になり、プロバイダーのファイアウォールでブロックされる可能性が低くなります。 ブロックの可能性をさらに減らすために、クライアント構成を変更し、TCP / IPを介して要求を送信できます（テストが示しているように、これは応答時間に最小限の影響しか与えません）。 したがって、ほとんどのネットワークフィルターの暗号化されたDNSトラフィックは、少なくとも外観上はHTTPSトラフィックに似ています。





DNSCryptトラフィックとローカルDNSCrypt Proxyトラフィックが表示されます。 Sniffer Wiresharkは、TCPの使用を強制したためHTTPSトラフィックだと言っています。 UDPを介して許可すると、WiresharkはChrome QUICトラフィックを表示します



一方、DNSCryptは暗号化について信頼できる認証局に依存していません。クライアントはプロバイダーが発行した公開署名キーを信頼する必要があります。 この署名キーは、通常の（暗号化されていない）DNSクエリを使用して抽出され、X25519キー交換アルゴリズムを使用したキー交換に使用される証明書を検証するために使用されます。 一部の（古い）DNSCrypt実装では、アクセス制御スキームとして使用できるクライアント側の証明書の条件があります。 これにより、送信元のIPアドレスに関係なくトラフィックをログに記録し、アカウントに関連付けることができます。 このスキームは、DNSCrypt 2では使用されません。



開発者の観点から見ると、DNSCryptを使用するのは少し難しいです。 「DNSCryptのドキュメントは特に詳しくありませんし、実装もそれほど多くありません」とInfoblox Cricket Liu氏は言います。 実際、開発中のクライアントはDNSCrypt Proxyのみでした。OpenDNSは開発のサポートを停止しました。



DNSCryptでの暗号化の興味深い選択は、一部の開発者を怖がらせるかもしれません。 プロトコルは、Curve25519（RFC 8032）、X25519（RFC 8031）、およびChacha20Poly1305（RFC 7539）を使用します。 Pyca Python暗号化ライブラリでのX24419アルゴリズムの実装の1つは 、設定を間違えるのが非常に簡単であるため、「暗号的に危険」 とラベル付けされています。 しかし、Curve25519で使用される主要な暗号化アルゴリズムは、「安全な使用のための最も単純な楕円曲線の1つ」です、とデニスは言いました。



開発者は、DNSCryptは企業の「屋根」のないボランティアによって作成されたため、IETF標準とは見なされなかったと言います。 それを標準として提示することは、「IETF会議での保護と同様に時間がかかるだろう」と彼は言った。 「暇なときに開発に取り組む他のデベロッパーのように、それを買う余裕はありません。 承認されたDNS関連仕様のほぼすべては、実際には毎年同じ会社の人々によって書かれています。 ビジネスがDNSに接続されていない場合、投票するのは非常に困難です。」



いくつかのDNSサービスはDNSCryptを使用していますが （たとえば、CleanBrowsingはアダルトコンテンツをブロックし、Cisco OpenDNSは悪意のあるドメインをブロックします）、新しいプライバシー指向のDNSプロバイダー（Google、Cloudflare、Quad9を含む）はDNSCryptを放棄し、 IETFの技術グループによって承認されたその他：DNS over TLSおよびDNS over HTTPS。 DNSCrypt ProxyはDNS over HTTPSをサポートし、デフォルト設定でCloudflare、Google、Quad9を示します。





TLS は、スヌーピングから保護するためにWebトラフィックの暗号化を強化する必要が生じたときにCloudFlareの優先事項になりました

TLSとの交配

DNS over TLS（Transport Layer Security）には、DNSCryptに比べていくつかの利点があります。 最初は提案されたIETF標準です。 また、その性質上非常に簡単に機能します。標準のDNS形式で要求を受け入れ、暗号化されたTCPトラフィックにカプセル化します。 TLSベースの暗号化に加えて、これはUDPではなくTCP / IPを介してDNSを送信することと本質的に同じです。



DNS over TLSには、いくつかの有効なクライアントがあります。 私が見つけた最良のオプションはStubbyと呼ばれ、 DNS Privacy Projectの一部として開発されました。 StubbyはLinuxパッケージの一部として配布されますが、MacOS用のバージョン（Homebrewを使用してインストール）とWindows用のバージョンもありますが、後者の作業はまだ完了していません。



いくつかの依存関係と戦った後、Debianで一貫してStubbyを実行できましたが、このクライアントはWindows 10で定期的にクラッシュし、MacOSでハングする傾向があります。 LinuxにStubbyをインストールするための優れたガイドを探している場合、私が見つけた最高のドキュメントはFrank SantosoのRedditに関する投稿です。 また、Raspberry Piにインストールするシェルスクリプトを作成しました。



幸いなことに、Stubbyでは、TLSを介した複数のDNSベースのサービスを使用した構成が可能です。 YAMLの構成ファイルを使用すると、いくつかのIPv4およびIPv6サービスを構成でき、SURFNet、Quad9、およびその他のサービスの設定が含まれます。 ただし、Stubbyで使用されるYAML実装はスペースに依存するため、新しいサービス（Cloudflareなど）を追加するときは注意してください。 最初はタブを使用して、すべてを壊しました。



DNSサーバーに接続する場合、TLSを介したDNSクライアントは、 Simple Public Key Infrastructure（SPKI）を使用して認証します。 SPKIは、プロバイダーの証明書のローカル暗号化ハッシュ（通常はSHA256アルゴリズム）を使用します 。 Stubbyでは、以下に示すように、このハッシュはYAML構成ファイルのサーバー記述の一部として保存されます。

upstream_recursive_servers: #IPv4 #Cloudflare DNS over TLS server - address_data: 1.1.1.1 tls_auth_name: "cloudflare-dns.com" tls_pubkey_pinset: - digest: "sha256" value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc= - address_data: 1.0.0.1 tls_auth_name: "cloudflare-dns.com" tls_pubkey_pinset: - digest: "sha256" value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ポート853を介してクライアントとサーバーの間にTCP接続を確立した後、サーバーはその証明書を提示し、クライアントはそれをハッシュと照合します。 すべてが正常な場合、クライアントとサーバーはTLSをハンドシェイクし、キーを交換し、暗号化された通信セッションを開始します。 この時点から、暗号化されたセッションのデータは、DNS over TCPと同じルールに従います。



Stubbyを正常に起動した後、リクエストを127.0.0.1（localhost）に転送するようにDNSネットワーク設定を変更しました。 DNSトラフィックが見えなくなると、Wiresharkスニファーはこのスイッチポイントを適切に表示します。





通常のDNSトラフィックからTLS暗号化への切り替え



DNS over TLSはDNS over TCPと同様に機能しますが、TLS暗号化はパフォーマンスにわずかな影響を及ぼします。 Stubbyを介したCloudflareへのクエリの調査には平均で約50ミリ秒かかりました（結果は異なる場合があります）が、Cloudflareへの単純なDNSクエリは20ミリ秒以内に応答します。



TCPの過剰使用により、サーバー側で部分的なスローダウンが発生します。 通常、DNSは、高速UDPプロトコルを使用して機能します。送信および忘却されますが、TCPメッセージには、接続のネゴシエーションとパケットの受信の検証が必要です。 DNS over Datagram Transport Layer Security（DTLS）と呼ばれるTLS DNSの UDPベースのバージョンは、現在実験中です-プロトコルのパフォーマンスを向上させることができます。



ここで証明書の管理にも問題があります。 プロバイダーが証明書を削除し、新しい証明書の使用を開始する場合、現在、クライアント上のSPKIデータをクリーンな方法で更新する方法はありません。ただし、古い証明書を切り取り、構成ファイルに新しい証明書を挿入することはできません。 理解する前に、何らかの種類のキー管理スキームを使用すると便利です。 また、このサービスはまれなポート853で実行されるため、TLS DNSがファイアウォールでブロックされる可能性が高くなります。



しかし、これはチャートのリーダーであるDNS over HTTPSにとって問題ではありません。 存在しないかのように、ほとんどのファイアウォールを通過します。





GoogleとCloudflareは暗号化されたDNSの未来を等しく見ているようです

HTTPS DNS：DoH！

GoogleとCloudflareの両方は、DNS暗号化の最も有望なオプションとして、DoHとしても知られるHTTPS経由のDNSプロトコルを見ているようです。 IETF標準のドラフトとして公開されたDoHプロトコルは、DNSクエリをHTTPSパケットにカプセル化し、通常の暗号化されたWebトラフィックに変換します。



要求は、HTTP メッセージまたは通常のDNSクエリからのデータグラム形式の本文を含むGETとして送信されるか、JSON形式のHTTP GET要求として送信されます （小さなオーバーヘッドを気にしない場合）。 そして、証明書の管理に問題はありません。 通常のHTTPS Webトラフィックと同様に、DoH経由で接続するために認証は必要なく、証明書は証明機関によって検証されます。





DoHを介したDNSトランザクションの修正。 HTTPS、TLSのみが表示されます。



HTTPSは、特にJSON形式のDNSクエリ用のやや面倒なプロトコルであるため、パフォーマンスの低下に耐える必要があります。 サーバー側で必要なリソースは、ほぼ確実に通常のDNSサーバーの管理者を泣かせます。 しかし、十分に理解されているWebプロトコルでの作業の単純さにより、DoHのクライアントコードとサーバーコードの両方の開発は、Webアプリケーションで犬を食べる開発者にとってよりアクセスしやすくなります（ほんの数週間前、FacebookエンジニアはPythonでDoHサーバーとクライアントのコンセプトをリリースしました）。



その結果、DoHのRFC仕様ではインクが乾燥していませんが、多くのHTTPS DNSクライアントがすぐに使用できます。 確かに、それらのいくつかは特定のDNSプロバイダー向けに調整されています。 パフォーマンスの低下は、サーバーと特定のクライアントの品質に依存します。



たとえば、Cloudflare（別名cloudflared ）からArgoトンネリングクライアントを使用します 。 これは、WebサーバーをCloudflare CDNネットワークに接続するための安全なチャネルを確立するために主に設計された多機能トンネリングツールです。 HTTPS DNSは、CDNが現在サポートしているもう1つのサービスです。



デフォルトでは、コマンドラインからArgoを起動した場合（LinuxおよびMacOSでは、このためにスーパーユーザー権限が必要であり、Windowsでは管理者としてPowerShellからクライアントを実行する必要があります）、DNSクエリをhttps://cloudflare-dns.com/dns-query



送信しhttps://cloudflare-dns.com/dns-query



。 通常のDNSが設定されていない場合、このアドレスは1.1.1.1で解決する必要があるため、小さな問題が発生する可能性があります。そうしないと、Argoは起動しません。



これは3つの方法のいずれかで修正できます。 最初のオプションは、ネットワーク構成のプライマリDNSサーバーとしてローカルホスト（IPv4の場合は127.0.0.1



、IPv6の場合は::1



）を持つデバイスをインストールし、追加のリゾルバーとして1.1.1.1を追加することです。 これは有効なオプションですが、プライバシーとパフォーマンスの点では理想的ではありません。 起動時にコマンドラインからサーバーURLを追加することをお勧めします。

 $ sudo cloudflared proxy-dns --upstream https://1.0.0.1/dns-query
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

自動更新の利点を提供するCloudflareのDNSサーバーに切り替えたい場合は、CloudflareのIPv4およびIPv6 DNSアドレスを含むYAML構成ファイルを使用して、Linux上でサービスとして構成できます。

 proxy-dns: true proxy-dns-upstream: - https://1.1.1.1/dns-query - https://1.0.0.1/dns-query
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

正しいアップストリームアドレッシングで構成すると、Argoを介したdig-requestsのパフォーマンスは大きく異なります：人気のあるドメインの12ミリ秒から131ミリ秒まで。 クロスサイトコンテンツの読み込みが多いページ...通常より少し長くなります。 繰り返しますが、結果は異なる場合があります-それはおそらくあなたの場所とつながりに依存します。 しかし、それは私が厳しいDoHプロトコルに期待したことです。





Cloudflareのように 、トンネルはベン・アフレックよりもアルゴ作戦をよく示していると思います



問題がCloudflareプログラマーではなくDoHプロトコルにあることを確認するために、他の2つのツールを試しました。 まず、GoogleのDingoというプロキシサーバー。 ポーランド科学アカデミーの理論と応用情報学研究所のインターネット研究者であるPavel Foreszkiによって書かれました。 DingoはGoogleのDoH実装でのみ機能しますが、最も近いGoogle DNSサービスに設定できます。 この最適化がなければ、DingoはすべてのDNSパフォーマンスを食い尽くしたので、これは良いことです。 発掘クエリの平均は100ミリ秒でした。



dns.google.com



で標準リクエストの処理を確認しているときに、Googleのデフォルトアドレス8.8.8.8（ご存じの場合は172.217.8.14）に代わるものが見つかりました。 コマンドラインからDingoに追加しました。

 $ sudo ./dingo-linux-amd64 -port=53 -gdns:server=172.216.8.14
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これにより、応答時間が約20％短縮されました。つまり、Argoとほぼ同じ指標になりました。



また、DNSCrypt Proxy 2は予想外に最適なDoHパフォーマンスを示しました。最近公開されたDNSサービスのキュレーションリストにDoH Cloudflareを追加した後、DNSCrypt Proxyはこのサーバーの遅延が少ないため、デフォルトでほとんど常にCloudflareに接続します。 確認するために、dig-requestのバッテリーを開始する前に、DoHのCloudflareリゾルバー用に手動で構成しました。



すべてのリクエストは45ミリ秒未満で処理されました-これはCloudflare自身のクライアントよりも高速で、大幅なマージンがあります。 GoogleのDoHサービスでは、パフォーマンスが低下しました。リクエストは平均約80ミリ秒で処理されました。 これは、Googleから最も近いDNSサーバーを最適化しないインジケーターです。



一般に、DoHのDNSCrypt Proxyのパフォーマンスは、以前に確認したTLSのDNSリゾルバーとほとんど区別できません。 実際、さらに高速です。 これが何らかの特別なDoH実装によるものなのか、おそらくJSON形式ではなくHTTPSでカプセル化された標準DNSメッセージ形式の使用によるものなのか、Cloudflareが2つの異なるプロトコルを処理するためなのかはわかりません。





私はバットマンではありませんが、私の脅威モデルはまだほとんどの人よりも少し複雑です

なぜそんなに苦しむのですか？

私はプロの妄想です。 私の脅威モデルはあなたの脅威モデルとは異なります。オンラインの活動はできる限り安全に保ちたいと思います。 しかし、DNSトラフィックの操作によるプライバシーとセキュリティに対する現在の脅威の数を考えると、多くの人々は何らかの形のDNS暗号化を使用する正当な理由を持っています。 3つすべてのプロトコルの実装によっては、トラフィックの伝送速度にあまり悪影響を及ぼさないことがわかり、嬉しく思います。



ただし、DNS暗号化だけではオンライン活動が隠されないことに注意することが重要です。 複数のサイトがサーバーでホストされている場合、HTTPS接続で使用されるサーバー名インジケーター（SNI）と呼ばれるTLS拡張機能は、訪問したサイトの名前をプレーンテキストで表示できます。 完全な機密性を確保するには、VPN（またはTor）を使用してトラフィックをカプセル化し、プロバイダーまたは他のスヌーピングパーティがパケットからメタデータをプルできないようにする必要があります。 しかし、これらのサービスはどれもTorで動作しません。 政府機関があなたに反対する場合、あなたは何も確信できません。



もう1つの問題は、DNSCryptコミュニティの偉人たちがすばらしい仕事をしたにもかかわらず、このプライバシーは一般の人々にとっては依然として複雑すぎることです。 暗号化のためのこれらのDNSクライアントの一部は、構成が比較的簡単であることが判明しましたが、それらのどれも通常のユーザーにとって保証されたシンプルとは言えません。 これらのサービスを本当に便利なものにするには、人々が購入するハードウェアとソフトウェア（ホームルーター、パーソナルコンピューターのオペレーティングシステム、モバイルデバイス）により緊密に統合する必要があります。



インターネットプロバイダーは、通常のDNSトラフィックをより積極的に収益化しようとするでしょう。政府機関やそれを使用してユーザーに損害を与えようとする犯罪者は消えません。 しかし、主要なOS開発者は、インターネットサービスプロバイダーと同様に、多くの場合、収益化に関心があるため、ほとんどの人がアクセスできる方法でDNSを確実に保護しようとは考えられません。 さらに、これらの開発者は、DNS監視機能を維持したい一部の政府からの変更に抵抗する可能性があります。



そのため、近い将来、これらのプロトコルは、データの機密性を本当に気にし、このために少し動作する準備ができている少数の人々のためのツールであり続けるでしょう。 DNSCryptを取り巻くコミュニティが活動を継続し、状況を前進させることを願っています。