web-dev-qa-db-ja.com

OpenNICDNSサーバーの信頼性

グーグルの8.8.8.8 DNSサーバーはISPが提供するものに代わる人気のあるDNSサーバーであり、プライバシーへの影響は私にはあまりにも面倒です。代替DNSサーバーに関するプライバシーを調べていると、OpenNICプールがかなり人気があることがわかりました。

ただし、これらのサーバーの信頼性についてどのように感じているかはわかりません。彼らは、IANAの権限外のルートゾーンに独自の拡張機能を実装しました。 IANAが定義するルートゾーンの一部を(公の精査以外で)再定義することを妨げるものは何ですか?

DNSクエリを大規模にDNSルートネームサーバーに直接転送することは有害であると考えられていることを理解していますが、正しい結果とプライベートな結果の両方を確保する唯一の方法は、ローカルネットワークにキャッシュの再帰的リゾルバーを設定することです。単一のホームネットワークの場合、これはルートサーバーに負担をかけることはありませんが、すべての家庭に確実に拡張できるわけではありません。

では、OpenNICを使用するか、ルートサーバーに転送する必要がありますか?私自身のISPは、定期的にDNSハイジャックを行っているため、問題外です。

* DNSSECが広く採用されていないため、正しさの側面は解決されますが、プライバシーの側面は解決されません。

4
Huckle

真実の問題は本質的に技術的な問題ではないため、「Xを信頼すべきか」などの質問に完全に答えることはできません。特に「... Zの遠い将来にアクションYを実行しない」を追加した場合はそうです。

特にあなたの質問では、プロバイダー自体と、プロバイダーとあなたの間のパスで何が起こっているのかについて確信が持てないようです。

解決プロセスをより細かく制御したい場合は、主に、ホスト上で直接、または信頼できる他のホスト上で、独自の再帰キャッシュネームサーバーを実行する以外に選択肢はありません。特に、DNSSECが提供する機能を使用することを完全に確認したい場合:遠隔検証ネームサーバーを使用する場合は、すべてのDNSSEC計算を正しく実行することを信頼します。

したがって、1.1.1.1(CloudFlare)、8.8.8.8(Google)、9.9.9.9(IBM + PCH + GlobalCyber​​Alliance)、OpenNIC、またはその他の https ://en.wikipedia.org/wiki/Public_recursive_name_server または、elsewereは信頼できるか、他のものより信頼できます。それは非常に個人的な意見でもあり(あなたは誰に信頼を与えますか)、それは時間とともに変化します。

あなたの主張は「しかし、それは間違いなくすべての世帯に拡大するわけではない」。それほど明確ではありません。人々が自分のDNS解決を社内で処理する(または以前のパブリックな解決の1つに転送する)動きはますます増えており、ルートサーバーには十分な容量があります。このゾーンファイルはゆっくりと移動し、小さく、どこにでもキャッシュされるため、問題は実際にはそこにない可能性があることに注意してください。問題は、.COMなどの一部のTLDネームサーバーではるかに大きくなる可能性があります。この場合、ゾーンファイルには数百万のエントリと、小さくない可能性のある定期的な変更の両方が含まれます。

テーブルにはさまざまなオプションがあり、それらを組み合わせて組み合わせることができます。

  1. 使用しているネームサーバーで QNAME最小化 (上記の公共サービスの一部でサポートされています)を使用します。これにより、DNSプロトコルを以前とまったく同じように機能させながら、各ネームサーバーに提供する情報が少なくなります。
  2. 現在の標準 DNS over TLS を使用して、DNS over HTTPSを提供しているネームサーバー(これも一部のパブリックサーバーが実行している、または実行する予定です)または「間もなく」DNS overHTTPSを照会できます。もちろん、そうすることで、問題を解決するだけです。パス内のハイジャック犯に対しては安全ですが、交換するエンドポイントの認証を確立する必要があります。繰り返しますが、自分で管理すれば簡単です。
  3. 「複数の」パブリックDNSサーバーをランダムに(すべてのトラフィックを取得しないように)使用し、結果を比較することを勧める人もいます。
  4. Stubby (getdns APIを使用)のような、プライバシーの観点から最高の機能を提供しようとする微妙なツールもありますが、可用性を優先する場合は、以前の安全でないメカニズムにフォールバックするように構成することもできます。セキュリティを超えて。 dnssec-trigger のようなソフトウェアも、デフォルトのネームサーバーを使用し、それらが実際に正しく機能することを確認し、必要に応じてリクエスト自体を処理することで、最初にDNSSECの利点を提供しようとします。
  5. 網羅的にするために、なりすましを防ぐことを目的とした DNSCrypt (オープンですが標準化されていません)をリストする必要があります。ただし、このプロトコルを使用して通信するには、特定のクライアントとサーバーが必要です。

あなたの知識を広げるために、このウィキは良いスタートかもしれません: https://dnsprivacy.org/wiki/

7
Patrick Mevzek